Software Development Skills

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 simplification, or removing dead code with zero callers (just delete it).

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.

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 output would be cheaper to verify now than to debug later. Don't use for mechanical operations (renames, formatting), one-line changes with obvious correctness, or when the user has explicitly asked for speed over verification.

Systematic ablation study runner. After research:run finds improvements, fortify identifies component candidates from git diff + diary, creates isolated git worktrees per ablation (main repo never modified), runs metric+guard in each worktree, ranks component importance, and optionally generates reviewer Q&A calibrated to a target venue.

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 reviewing PRs.

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.

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. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.

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.

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.

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", "/hb: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.