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.
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…
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.
Simplify working code without changing behavior — reduce complexity, remove dead abstractions, favor clarity over cleverness. Use when code works but is harder to read or maintain than it should be, or the user asks to "simplify", "clean up", "reduce complexity", or "make this clearer". Don't use to add features or…
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.
Group unstaged changes into atomic commits by concern, following repository style. Use when user asks to "commit", "create a commit", "commit changes", or "/commit". Don't use for pushing (that belongs to /ship) or creating pull requests.
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 /spec) or general repo conventions (use…
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". Don't use for benchmarking or optimizing a skill's triggering with evals (use skill-creator), or for one-off prose edits to an existing…
Check dependencies for known vulnerabilities and staleness. Use when user asks to "audit dependencies", "/deps-audit", "check for vulnerabilities", or wants to check dependency health. Don't use for reviewing code quality.
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.
Actively build and sharpen a project's domain model — challenge terms, pin down a ubiquitous language, and write the glossary and decisions down as they crystallize. Use when the user wants to define domain terminology, resolve ambiguous terms, or when another skill needs the shared vocabulary. Don't use for recording…
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.
Explains code with visual diagrams and analogies. Use when explaining how code works, walking through a codebase area, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, generating new implementations, or multi-session concept learning (use /teach).
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…
Front-load UI construction decisions — component boundary and prop API, where state lives, data/async, the required UI states (loading/empty/error), responsive behavior, and accessibility by construction. Use when creating or refactoring a component, page, or design-system primitive. Don't use for pure logic (tdd)…
A relentless interview to sharpen a plan or design. 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 /spec).
Compact the current conversation into a handoff document for another agent to pick up. Use when the user wants to hand off, transfer context to a fresh session, or says "write a handoff". Don't use to summarize for the current session (just answer) or to brief on plan progress (use /test).
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…
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.
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 or type-checking only.
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.
Turn a spec into a multi-phase implementation plan using tracer-bullet vertical slices. Use after /spec when a spec exists at .specs/specs/ .md, or when the user asks to break work into phases or slices. Don't use without a spec, or for single-file changes with obvious scope.
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.