draw-mermaid-diagram
Create and validate Mermaid flowcharts, sequence, class, ER, state, gantt, journey, timeline, mindmap, and pie diagrams. Use for "draw a Mermaid diagram", "draw a sequence/state/ER/class diagram", "make a flowchart", or a non-infrastructure flow. Use draw-infra-diagram for AWS/cloud architecture with specialized shapes and debugging composition.
eli5
Explain a topic, module, decision, or incident as if the reader knows nothing about it, then publish the explanation as a big-picture, few-words HTML Artifact. This is the default way to answer a request for a plain-language explanation. Use for "/eli5", "eli5 this", "explain like I'm 5/five", "explain this simply", "give/provide me a simple explanation", "explain how this works", "explain why we did this", "what caused this", or any other request to explain a module, decision, tradeoff, or incident in plain terms. Not for a request that explicitly wants technical depth ("deep dive", "explain in detail", "walk me through the implementation") or a task that isn't an explanation request at all (review, fix, write code).
fix-issue
Implement a fix for a bug, issue, or failing behavior from scratch, reproduce-first. Use when asked to "fix this bug", "fix this issue", "resolve #123", "this is broken — make it work", "implement a fix for", or when handed an error/stack trace and expected to make a code change. Reproduce → fix → verify → edge cases → hand off. Distinct from `debug` (diagnoses the root cause without implementing — hand off to this skill to write the fix), `iterate-pr` (fixes CI/feedback on an existing PR), `optimize-perf` (perf only, benchmark-gated), `auto-review-code` (applies findings from a review), and `plan-implementation` (plans NEW multi-phase features without writing code). For a large multi-phase feature, run `plan-implementation` first, then this per phase.
frontend-design
Design and implement distinctive, production-ready frontend interfaces with strong aesthetic direction. Use when the user asks to "design a landing page", "redesign this UI", "improve the visual design", "make this look better", "build a marketing page", "design a dashboard", "restyle this component", or wants a greenfield FE design with character — not a generic AI-default UI. Pushes Claude to commit to a single bold aesthetic (brutalist / editorial / luxury / retro-futuristic / etc.) instead of producing the same gradient-and-Inter UI every time.
handoff
Write a structured handoff document so a fresh Claude Code session can continue the current work without re-reading the entire transcript. Use when asked to "hand off", "handoff", run "/handoff", prepare for a "/clear", start a fresh session without losing context, or save the current conversation's state for a future session. Produces a local `HANDOFF_<slug>.md` (or `/tmp/HANDOFF_<slug>.md` outside a repo) that the user pastes or opens in the new session.
improve-architecture
Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.
iterate-pr
Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.
librarian
Cache and refresh remote git repositories under `~/.cache/checkouts/<host>/<org>/<repo>` so future references reuse a local copy instead of re-cloning. Use when the user references a remote git repository — full URL (`https://github.com/foo/bar`, `git@github.com:foo/bar.git`), `owner/repo` shorthand, or asks Claude to "look at", "read", "search", or "find something in" an external repo by name. Returns a stable local path that downstream skills (review-code, grep, Read) can use directly.
optimize-perf
Apply performance improvements with before/after benchmarks. Use when asked to "optimize this", "make it faster", "speed this up", "profile and fix", or when the user wants perf fixes applied (not just reviewed). Runs `review-perf` to find candidates, then for each fix writes a benchmark, applies the change, re-measures, and reverts on regression. Companion to `review-perf` (which only finds issues); distinct from `auto-review-code` (which applies generic fixes without wall-clock measurement).
plan-implementation
Create a local IMPLEMENTATION_PLAN_<feature>.md for NEW features, complex additions, or multi-phase work, with reconnaissance, binary ideal-state criteria, premortem, phases, and quality gates. Use for "create an implementation plan". Use plan-refactor for behavior-preserving restructuring, and review-plan for an existing plan-mode draft.
plan-refactor
Create a local REFACTOR_PLAN_<name>.md through a user interview, decomposing behavior-preserving restructuring into tiny commits. Use for "plan a refactor", "restructure this code", "extract a module", or tiny-commit refactor planning. Use plan-implementation for NEW features or phased additions, and review-plan for an existing plan-mode draft.
review-code
>-
review-design
Review EXISTING code at module/package scope for coupling, abstraction depth, seams, testability, and scalability; return a verdict and prioritized concerns. Use for "design review this module", "is this too coupled?", or "will this scale?". Use review-code for diff defects, review-plan for plan documents, and improve-architecture for codebase-wide redesign ideas.
review-django-access
Django access control and IDOR security review. Use when reviewing Django views, DRF viewsets, ORM queries, or any Python/Django code handling user authorization. Trigger keywords: "IDOR", "access control", "authorization", "Django permissions", "object permissions", "tenant isolation", "broken access".
review-django-perf
Django performance code review. Use when asked to "review Django performance", "find N+1 queries", "optimize Django", "check queryset performance", "database performance", "Django ORM issues", or audit Django code for performance problems.
review-gha-security
GitHub Actions security review for workflow exploitation vulnerabilities. Use when asked to "review GitHub Actions", "audit workflows", "check CI security", "GHA security", "workflow security review", or review .github/workflows/ for pwn requests, expression injection, credential theft, and supply chain attacks. Exploitation-focused with concrete PoC scenarios.
review-perf
General application performance review for non-Django code (Flask, FastAPI, Go, Node, generic Python). Use when asked to "review performance", "audit performance", "find slow code", "perf review", or audit app-tier code for blocking I/O on async paths, algorithmic blow-ups, per-item network loops, unbounded memory accumulation, or missing application caching. Find-only — use `optimize-perf` to apply fixes with benchmarks. Covers the application surface that `review-django-perf` (Django ORM) and `sql-reviewer` (raw SQL / migrations) do not. Validation-first — no flag without traced evidence.
review-plan
Review a plan for architectural, DRY, scope, and UX concerns before implementation starts. Covers IMPLEMENTATION_PLAN_*.md / REFACTOR_PLAN_*.md files AND in-conversation plans drafted in Claude Code plan mode (ExitPlanMode) or inline messages. Use when user asks to "review the plan", "analyze the plan", "critique the plan", "is this plan good", or wants a senior engineer / product manager pass over a planning document. For creating a plan from scratch use plan-implementation or plan-refactor. For reviewing code or a PR use review-code.
review-pr
>-
review-security
Security code review for vulnerabilities. Use when asked to "review security", "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.
review-skill
Audit existing skills (SKILL.md files) against the write-skill authoring rubric — frontmatter validity, description trigger coverage, structural size, detection-rule over-fit, reference resolution, intra-skill cross-references. Use when reviewing a newly written skill, checking skill quality before merge, evaluating refactored or consolidated skills, or running a compliance pass over the skill plugin. Outputs findings classified as real gaps, observations, or pre-existing issues, each with a concrete recommended fix.
review-tone
Write, rewrite, or review project prose so it is clear, controlled, human, and free of AI-style filler. Use for docs, READMEs, PR text, review comments, commit messages, errors, release notes, "make this not sound like AI", tone review, de-slopping, or STE checks. Not for persuasive marketing, essays, chat, or sales copy.
review-with-hunk
>-
sales-email-draft
>-
sales-email-followup
>-
sales-email-prospect
>-
sales-email-reply
>-
sentry
Fetch and analyze Sentry data — issues (grouped errors), events (individual occurrences with stack traces and breadcrumbs), transactions, and logs. Use when the user asks to "look at Sentry", "fetch this Sentry issue", "find errors in Sentry", "search Sentry events", "what happened in Sentry around <time>", "get the latest event for issue X", or wants Claude to investigate a production error using Sentry data. Authenticates via `~/.sentryclirc`. Composes with review-code / iterate-pr (e.g., debug a Sentry issue, then produce a fix PR).
simplify-code
Review changed code for AI-generated slop and apply fixes. Use when the user says "simplify", "clean this up", "deslop", "tidy up", or after AI-generated code lands. Fans out to focused code-quality lane detectives (comments, structure, typing, complexity, defensive), coalesces their findings, and applies the safe ones.
update-changelog
Update `CHANGELOG.md` (or `CHANGELOG`) with notable user-facing changes since the last release tag. Use when the user asks to "update the changelog", "update CHANGELOG.md", "write release notes", "prepare release notes", or "add unreleased entries". Adds entries to the `## Unreleased` section, preserves existing format, and filters out trivial commits (typo fixes, internal refactors, dependency bumps without security impact).
uv
Use `uv` instead of `pip` / `python` / `venv` for Python work in repos that have adopted uv. Use when running Python scripts (`uv run`), adding dependencies (`uv add`), creating standalone scripts with inline dependency metadata (`uv init --script`), or managing the Python build backend (`uv_build`). Triggered by mentions of `uv`, inline script metadata blocks (`# /// script ... ///`), `uv.lock`, `pyproject.toml` with `[tool.uv]`, or any Python script Claude is about to run in a uv project.
write-agents-md
Use this skill when the user asks to "write AGENTS.md", "create AGENTS.md", "update AGENTS.md", "maintain agent docs", "set up CLAUDE.md", or needs to keep agent instructions concise. Enforces research-backed best practices for minimal, high-signal agent documentation.
write-skill
Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill. Also covers when to ship a capability as an agent instead of a skill.
Page 2 of 2 · 83 results