Catalog
Every x402, MPP, MCP, and skill listing we've indexed, normalized, and enriched.
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-intern
ship
Commit and push changes with a pre-launch gate (validate-code + safe-repo) by default. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
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 manua
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 co
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 con
review
Orchestrated REVIEW phase — analyze the diff, decide which audits apply, run them in order, consolidate findings. Use before merging a PR, before shipping a significant change, or when user asks to "review", "/hb:review", "do a full review". Don't use for single-file fixes (use `
refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
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.
prd
Create a PRD through user interview, codebase exploration, and module design. Use when starting a new feature or change.
pr-reply
Draft friendly, concise replies to pull request review comments. Use when user pastes a PR comment, asks to "reply to a PR comment", "/pr-reply", "answer this reviewer", or wants help responding to review feedback. Don't use for posting comments to GitHub, creating new PRs, or re
plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices. Use after /hb: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 bu
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.
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
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 bound
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
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
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.
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.
doubt-driven-development
Subject every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident
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 r
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.
deprecate
Manage deprecation and migration of old systems, APIs, or features. Use when removing legacy code, sunsetting features, consolidating duplicate implementations, or planning the lifecycle of a new system. Don't use for one-off refactors (use `refactor-plan`), in-flight code simpli
create-pull-request
Create GitHub pull requests. Use when user asks to "create a pull request", "open a pull request", "open a PR", "make a PR", "submit a PR", "push a PR", "/create-pull-request", or requests creating a pull request. Don't use for reviewing PRs, merging branches, or committing local