debug
>-
review-code
>-
auto-review-code
Automatically iterate review-code and code-simplifier until no more safe fixes remain. Use when user wants to "auto-review-code", "auto-fix", run review-and-simplify on repeat, or clean up code without staying in the loop for each finding. Auto-applies local, low-risk fixes; batches risky changes for a single end-of-run approval pass.
auto-review-plan
Automatically iterate review-plan against a plan until no safe blocking edits remain. Use when user wants to "auto-review-plan", "auto-fix the plan", tighten a plan without staying in the loop for each finding, or harden an `IMPLEMENTATION_PLAN_*.md` / `REFACTOR_PLAN_*.md` / plan-mode draft before implementation. Auto-applies small, concrete blocking edits; batches structural recommendations for a single end-of-run approval pass.
clarify
Interview the user to resolve ambiguity in a request, plan, or design before committing to work — one targeted question at a time until intent, scope, and constraints are pinned down. Use when a request is underspecified, could have multiple valid interpretations, hides a false premise, or the user wants to stress-test a plan. Triggers on "clarify this", "grill me", "stress-test my plan", "get grilled on my design", "what am I missing", or any request vague enough that proceeding would mean guessing. Pairs with plan-implementation for pre-planning requirements clarification.
commit
ALWAYS use this skill when committing code changes — never commit directly without it. Creates commits following conventional commit format with proper issue references and clean, scoped messages. Trigger on any commit, git commit, save changes, or commit message task.
create-branch
Create git branches following naming conventions. Use when creating new feature branches, bug fix branches, or any branch for development work. Defines the branch naming standards used across commit and PR skills.
create-pr
ALWAYS use this skill when creating or updating pull requests — never create or edit a PR directly without it. Follows conventional PR title format, respects repo PR templates when present, and produces concise descriptions focused on what and why. Trigger on any create PR, open PR, submit PR, make PR, update PR title, update PR description, edit PR, push and create PR, or prepare changes for review task.
document-architecture
Generate a high-level architecture document for a module, service, or codebase using 4 parallel Explore sub-agents (data, API/interface, business logic, integrations). Composes with `draw-mermaid-diagram` and `draw-infra-diagram` to embed validated diagrams. Use when asked to "document this codebase", "write architecture docs", "create an arch doc", "generate onboarding docs", "document this service", "map this module". Output is a single Markdown file optimized for human onboarding, not LLM context.
draw-infra-diagram
Create and validate customer- or support-facing AWS/cloud infrastructure diagrams in Mermaid. Use for "draw an infra diagram", "AWS architecture diagram", cloud flows, or debugging maps. Adds AWS shapes, colors, region tinting, legends, DLQ styling, edge labels, resource checks, and PDF export. Use draw-mermaid-diagram for other diagrams.
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.
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-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.