Explain Code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
A11y Audit
Audit accessibility compliance in frontend code. Use when user asks to "check accessibility", "/a11y-audit", "audit a11y", "check WCAG", or wants to find accessibility issues. Don't use for backend code, non-UI files, or projects without HTML/JSX output.
Create Pull Request
Create a GitHub pull request — fills the repo's PR template, conventional-commit title, ticket refs. Draft mode via `--draft`.
Prototype
Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to explore or compare design directions before committing, or says "prototype", "mock up", or "try a few approaches". Don't use for production implementation (use /build or /tdd).
Atomic Commits
Group unstaged changes into atomic commits by concern, then push. Use when user asks to "atomic commits", "commit by group", "group commits", or wants to split changes into related commits before pushing.
Harden
Harden code proactively against vulnerabilities at the boundary where untrusted input enters the system. Use when implementing auth, handling user input, storing or transmitting sensitive data, integrating external APIs, adding file uploads, or any code that crosses a trust boundary. Don't use for reactive secret scanning (use `safe-repo`) or dependency CVE checks (use `deps-audit`).
Source Driven
Implement features using official docs for exact dependency versions instead of training data. Use when user asks to "check the docs", "use official docs", "source-driven", or when implementing with unfamiliar APIs/libraries. Don't use for well-known stdlib APIs or project-internal code.
Prose Fix
Fix prose formatting, typos, and clarity issues in markdown or text files. Use when user asks to "fix dashes", "fix typos", "clean up text", "improve sentences", or "/prose-fix". Don't use for code style, linting, or full rewrites.
Safe Repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Use `--diff` mode to scope to staged + unstaged changes only (e.g., before commit). Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
Diagnose
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
Codebase Design
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Teach
Teach the user a new skill or concept within this workspace — stateful lessons, references, and learning records tied to a mission. Use when the user asks to learn, be taught, or understand a concept or technology in depth. Don't use to explain a specific code area (use /explain-code) or answer a one-off question.
Revise
Structurally edit and improve article drafts — reorder sections, tighten arguments, improve clarity. Use when user asks to "revise", "improve my article", "edit my draft", or "/revise". Don't use for typo fixes or formatting (use prose-fix), code documentation, or non-article content.
Fortify
Fortify existing code by splitting large functions, adding edge-case coverage, and backfilling unit tests. Use when user asks to "fortify", "harden", "bulletproof", "make robust", "make solid", "strengthen", "add missing tests", "split functions", or wants to improve reliability of existing code. Don't use for new features (use tdd), refactoring plans, or code review (use code-review).
Create 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, or asks "make a skill for X".
Code Review
Review a GitHub Pull Request for bugs, security, performance, and code quality. Use when user asks to review a PR or wants pull request feedback. Don't use for reviewing local uncommitted changes, creating new PRs, or merging branches.
Prd
Create a PRD through user interview, codebase exploration, and module design. Use when starting a new feature or change.
Build
Implement one phase of a plan. Reads plan, finds next incomplete phase, implements it, runs feedback loops, marks checkboxes, offers commit. One phase per invocation. Use when the user wants to implement, code, build, or work on the next phase of a plan.
Plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices. Use after /tk:prd.
Perf Audit
Audit frontend bundle size and performance. Use when user asks to "audit performance", "/perf-audit", "analyze bundle", "check bundle size", or wants to find performance bottlenecks. Don't use for backend performance, database query optimization, or projects without a frontend build step.
Prd
Create a PRD through user interview, codebase exploration, and module design. Use when starting a feature with unclear requirements, when the user asks to spec or define what to build, or says "write a PRD". Don't use when requirements are crisp and a plan already exists (use /plan or /build).
Plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices. Use after /prd when a PRD exists at `.specs/prds/<slug>.md`, or when the user asks to break work into phases or slices. Don't use without a PRD, or for single-file changes with obvious scope.
Architecture Audit
Explore a codebase to surface architectural friction and propose refactors toward deep modules (simple interface, large implementation) as GitHub issue RFCs. Use when the user asks to audit architecture, find structural friction, or identify refactor opportunities across a codebase. Don't use for single-module interface design (use /codebase-design) or code-level review of a diff (use /code-revie…
Create Adr
Record an Architecture Decision Record (ADR) — a 1–3 sentence note capturing what was decided and why. Use when user says "create an ADR", "record this decision", "/create-adr", or just decided something architecturally significant. Don't use for forward-looking specs (use hb:prd) or general repo conventions (use CLAUDE.md).
I18n
Audit internationalization coverage and find hardcoded strings. Use when user asks to "check i18n", "/i18n", "find hardcoded strings", "check translations", or wants to verify translation coverage. Don't use for backend string extraction, non-frontend code, or projects without an i18n library.
Deps Audit
Check dependencies for vulnerabilities. Use when user asks to "audit dependencies", "/deps-audit", "check for vulnerabilities", or wants to check dependency health. Don't use for yarn, pnpm, or bun projects (npm only), or for reviewing code quality.
Commit
Create git commits following repository style. Use when user asks to "create a commit", "commit changes", "/commit", or requests committing code to git. Don't use for pushing code, creating pull requests, or reviewing changes.
Review
Orchestrated REVIEW phase — analyze the diff, decide which audits apply, run them in order, consolidate findings. Use for a full pre-ship review or when the user asks to run all relevant audits on changes or a PR. Don't use to implement fixes (use /build or /tdd) or for a single focused audit (call it directly, e.g. /a11y-audit, /code-review).
Check
Verify implementation against plan. Shows progress and finds blockers. Use after implementing a plan.
Tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Setup Pre Commit
Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests. Use when user asks to \"add pre-commit hooks\", \"setup husky\", \"setup pre-commit\", \"configure lint-staged\", or wants commit-time formatting/typechecking/testing. Don't use for running linters manually or writing tests.
Coverage
Check test coverage for unstaged changes. Use when user asks to "check coverage", "/coverage", or wants to see which unstaged changes lack test coverage. Don't use for projects without lcov coverage output, running the full test suite without coverage, or checking coverage of already-committed changes.
Verify Plan
Verify implementation against a plan — shows progress and finds blockers. Use after /build, or when the user asks to check plan progress or what's left. Don't use to implement phases (use /build) or for general test runs (use /validate-code).
Brief
Session briefing — shows active features, progress, and suggested focus. Use at the start of a session, when asking what to work on, or when checking active features.
Lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
Validate Code
Validate code quality: auto-fix formatting/lint, verify types, run tests. Use when user asks to \"validate code\", \"/validate-code\", \"check code\", or wants to validate before committing. Don't use for committing, pushing, or writing new tests.
Build
Implement one phase of a plan — reads the plan, finds the next incomplete phase, implements it with feedback loops, marks checkboxes, offers a commit (one phase per invocation). Use after /plan when a plan exists at `.specs/plans/<slug>.md`, or when the user asks to build or implement the next phase. Don't use for ad-hoc changes with no plan (use /tdd) or to check progress (use /verify-plan).
Visual Validate
Validate UI changes in a real browser using Chrome DevTools or Playwright MCP. Takes screenshots, compares before/after, exercises interactions, captures console errors. Use when user asks to "visual validate", "/visual-validate", "check the UI", "screenshot before/after", or finishes a UI change. Don't use for unit tests (use `tdd`), E2E user flows (use `e2e`), or backend changes.
Ship
Commit and push changes with a pre-launch gate (validate-code + safe-repo) by default. `--fast` skips the gate.
E2e
Write end-to-end tests for user flows using Cypress. Use when user asks to "write e2e tests", "/e2e", "add Cypress tests", or wants to test a user flow end-to-end. Don't use for unit tests, component tests, or projects using Playwright, Puppeteer, or other non-Cypress frameworks.
Brief
Session briefing — shows active features, progress, and suggested focus. Use at the start of a session, when asking what to work on, or when checking active features.
Grill Me
A relentless interview to sharpen a plan or design (runs /grilling). Use when the user wants to stress-test a plan, pressure-test assumptions, or says "grill me" or "poke holes in this". Don't use for code review (use /code-review) or gathering initial requirements (use /prd).