skills

Use when the user says "/drive-change", "drive the change", "make this change happen", "implement and review", "ship this fix", or wants Claude to drive a change end-to-end (implement if needed + audit + fix) without going through formal planning. For quick or clear changes where the implementation can be derived from conversation intent. For substantial changes warranting an ADR + Gherkin spec, use /drive-plan instead. drive-change runs the audit pipeline (slice → fan-out to /review-* specialists in parallel → merge with apply-validation → cross-slice verify → dispatch fix-applier agents under sensitivity gating). Sensitive paths (auth, crypto, IPC) route to Opus fix-appliers; everything else goes to Sonnet. Adds /review-ux automatically if UI files are touched (.tsx/.jsx/.vue/.svelte/.astro/.html/.css/.scss/.less). Produces a single unified report grouped by severity.

Use when the user says "/drive-plan", "drive a plan", "drive this feature end-to-end with planning", "let's build feature X properly", "kick off this change with planning rigour", or asks Claude to drive a substantial change all the way through planning, implementation, and review in one composed workflow. Calls /plan-change interactively to produce ADR + Gherkin spec, then /implement-change to translate spec into code, then /review-change to audit and dispatch fixes via the agent pipeline; recommends /open-pr at the end. Use /drive-plan for substantial changes warranting planning rigour; use /drive-change for quick changes that don't need formal planning; use /drive-pr to iterate an already-open PR. Confirms with the user at each phase boundary because this skill writes a lot of state.

Use when the user says "drive this PR", "/drive-pr", asks to resolve all PR comments, get a PR green, address review feedback, or otherwise wants Claude to iterate on an open pull request until every trusted comment is resolved, CI is passing, and the PR description matches the code. Runs /review-pr upfront for a baseline audit (informational by default; pass --audit-blocks to make P0s gate the exit). Code-change comments are batched into synthetic findings and dispatched via the agent pipeline (orchestrate-merge + fix-applier under sensitivity gating) so edits across files apply in parallel. Reply-only comments stay on the existing inline path. GH-specific ops (post replies, resolve threads, monitor CI) remain in the skill. Operates only on the current branch's PR or an explicitly passed PR number/URL.

Use when the user says "implement this", "/implement-change", "translate the spec into code", "the ADR and spec are done, build it", "code this up", or asks Claude to turn a planned change (ADR + Gherkin spec, usually produced by /plan-change) into actual code in the touched paths. Reads the ADR for architectural decisions, the spec for the behavioural contract, the existing code in the touched paths for conventions and seams, then writes the implementation and runs the spec's scenarios as smoke tests. Stops at "spec scenarios pass"; does not run the full audit suite — that's /drive-change's job. Use /plan-change first to produce the ADR + spec, /implement-change to write the code, then /drive-change to audit and polish.

Use when the user says "open a PR", "/open-pr", "make the PR", "ship this", "draft a PR", "create the PR", or wants Claude to turn the current branch's work into an open pull request. Runs final sanity checks (lint, format, type-check, tslsp diagnostics if installed), drafts a title and body that actually describe what's in the diff and commits + any linked ADR / spec / ticket, confirms with the user, then pushes and opens via `gh pr create`. Closes by asking whether to drive the PR now (`/drive-pr`) or wait for review. Bookend to `/drive-pr` - open-pr opens, drive-pr iterates.

Use when the user says "plan a change", "/plan-change", "plan a feature", "let's design X", "let's discuss this change", "kick off feature/refactor/initiative Y", or wants Claude to drive a discussion that produces both an ADR (architecture decision record) and a Gherkin spec (.feature file) for a piece of work about to start - new feature, refactor, behaviour change, or significant bug fix. Discovers the repo's ADR and specs conventions, holds an interactive discussion to extract scope + architecture + scenarios + edge cases, then writes both files cross-linked together. Composes /write-adr and /write-spec into the natural "I'm starting something" workhorse. Usually arrived at via /start-feature; can be called directly when intent is clear.

Use when the user says "review the change", "/review-change", "audit my working tree", "what's wrong with what I've got staged", "review without fixing", or asks Claude to audit the working tree's diff read-only without modifying files, committing, or pushing. Read-only mirror of /drive-change — same slice/fan-out/merge/verify pipeline, same finding-format output, never edits or commits. Always runs /review-code + /review-test + /review-feature + /review-security; adds /review-ux when UI extensions are touched. Produces a single terminal report grouped by severity. Use /drive-change when you want Claude to apply the fixes; use /review-change when you want the verdict and intend to act on it yourself.

Use when the user wants Claude's judgment on the design and shape of code in touched files — single-responsibility, modularity, layering, naming, length, structural smells, dead code, stale comments — without running linters or formatters and without applying any fixes. Triggers on "/review-code", "review the code", "what's wrong with this code's design", "is this file too long", "code-quality findings on design", "structural review", "the design pass". Read-only audit specialist that emits findings in the finding-format.md schema. Does NOT run linters / formatters / LSP diagnostics — that's /review-hygiene's job; this skill focuses on judgment a tool can't make. Mechanical findings get concrete fix: lines; structural changes (extract, split, rename module) get decide: prefixes for the orchestrator to escalate. Use /review-code when you want the design verdict; use /review-hygiene for tool-driven lint/format findings; use /drive-change to have the orchestrator dispatch the fixes.

Use when the user says "review the feature", "/review-feature", "audit the feature logic", "is the feature complete", "check edge cases", or asks Claude to evaluate whether a feature (typically the one in the current PR) is well built end-to-end against its spec without modifying any code. Read-only audit specialist — reads any ADRs and specs that exist for the feature, traces the data flow from entry to exit, and emits findings for each gap, edge case, error-handling miss, or spec mismatch in finding-format.md schema. Does NOT pass judgment on code style (use /review-code) or click through the UX (use /review-ux). Use /review-feature when you want the feature-logic verdict in finding form; use /drive-change to have the orchestrator dispatch the fixes those findings describe.

Use when the user wants the project's linter / formatter / LSP diagnostics run as a check-only pass that emits findings the orchestrator can dispatch as auto-fixes. Triggers on "/review-hygiene", "run the linter", "check formatting", "what does eslint say", "what does prettier complain about", "lint findings only", or any ask for the deterministic-tool view of code quality. Detects ESLint / Biome / Oxlint / Prettier / gofmt / go vet / ruff / black / clippy / rustfmt and runs them in check-only mode. Emits ONE aggregate finding per tool (covering all auto-fixable violations across all touched files) plus individual findings for anything the tool flagged as not-auto-fixable. Keeps the orchestrator's context tiny — instead of N violations being read into context, the aggregate finding tells fix-applier "run `prettier --write src/`", which executes deterministically. Companion to /review-code (which handles subjective design judgment that linters can't catch). Use /review-hygiene when you want the mechanical-qual

Use this skill to produce a read-only audit of an open pull request — by PR number, GitHub URL, or the current branch's PR — without editing files, pushing commits, or modifying the PR. Triggers on requests to "review this PR", "/review-pr", "audit PR

Use when the user says "review security", "/review-security", "security review", "is this safe", "check for vulnerabilities", "security findings only", or asks Claude to do a security-focused audit of the files a PR (or working tree) touches without applying fixes. Read-only audit specialist — audits authn/authz on touched routes, scans for hardcoded secrets, checks input validation and output encoding at trust boundaries, runs dependency-vulnerability tools (npm audit / pip-audit / cargo audit / govulncheck) where available, and flags OWASP-top-10 smells. Emits findings in finding-format.md schema with severity ladder. Use /review-security when you want the security verdict in finding form; use /drive-change to have the orchestrator dispatch the safe mechanical fixes (under sensitivity gating that routes auth/crypto packets to Opus).

Use when the user says "review this spec", "/review-spec", "check for overlap", "is this spec consistent with our ADRs", or asks to validate a new Gherkin spec or ADR against the existing corpus before it lands. Searches all .feature files and ADRs in the repo, flags duplicate scenarios, conflicting decisions, overlapping feature areas, missing ADR cross-links, and contradictions with the base architecture. Read-only - produces a report, never modifies files.

Use when the user says "review the tests", "/review-test", "are the tests any good", "check test coverage", "test-quality findings only", or asks Claude to audit test quality across the files a PR (or working tree) touches without modifying any code or tests. Read-only audit specialist — evaluates each touched file's tests for level (unit vs integration vs e2e), assertion quality, mock health, coverage of new code paths, and the classic smells (mocking the unit under test, snapshot churn, tests-that-can't-fail), and emits findings in finding-format.md schema. Use /review-test when you want the test-quality verdict in finding form; use /drive-change to have the orchestrator dispatch the fixes those findings describe.

Use when the user says "review the UX", "/review-ux", "walk through the feature", "browser-walk this feature without fixing", "check the UX", "test the flow in a browser", or asks Claude to launch the app and click around to verify a feature's UX. Read-only browser-driven audit specialist — drives the application in a real browser (via chrome-devtools MCP if available, otherwise Playwright), exercises the golden path and edge cases for the feature in the current PR, captures screenshots as evidence, and emits findings in finding-format.md schema. Never edits code; never commits. Does NOT do code-quality checks (use /review-code) or feature-logic audits (use /review-feature). Use /review-ux when you want the UX verdict in finding form; use /drive-change to have the orchestrator dispatch fixes for the UX findings that are mechanical.

Use when the user says "/start-feature", "start a feature", "I want to add X", "I need to fix bug Y", "I'm going to refactor Z", "let's build something", or otherwise signals they have a known piece of code work to do (feature add, bug fix, refactor, UI tweak). Routes to the right next skill: new feature -> /plan-change; existing feature with ADR -> read it, then /plan-change in update mode; existing feature without ADR -> /backfill-feature, then /plan-change; trivial change -> skip scaffolding and go straight to implementation. Companion to /start-discussion for exploratory work where the intent isn't yet clear.

Use when the user says "write a spec", "/write-spec", "add a feature file", "write a Gherkin spec", "specs for this feature", or asks to capture a feature's behaviour as a Gherkin .feature file (Cucumber/SpecFlow/Behave/pytest-bdd style). Discovers the repo's existing specs folder and conventions, discusses the feature interactively to extract scenarios (golden path, edges, errors), then writes the .feature file matching local style. Pulls context from a related ADR if one exists. Standalone counterpart to /plan-change, which writes ADR + spec together.

Use when the user says "/backfill-feature", "backfill the ADR", "this feature has no ADR", "I need to document what's already there before I change it", or wants to capture an existing feature's architectural rationale and behaviour *before* modifying it. Reads the relevant code, drafts a reverse-engineered ADR (what is, why it probably looks like this) + Gherkin spec (current behaviour) + characterization tests that lock the current behaviour green. Hands off to /plan-change so the actual change can be layered on top of a documented, tested baseline.

Use when the user says "/start-discussion", "let's discuss", "I have a problem", "I have an idea", "not sure what to do here", "want to think this through", or otherwise opens an exploratory conversation without yet knowing what shape the work will take. Drives an open discussion to extract context - what's the actual problem, what's the constraint, what would good look like. Once enough intent emerges, routes to /start-feature (or directly to /plan-change). No file outputs - this is talking, not writing. Companion to /start-feature for work where the intent is already clear.

Use when writing prose that goes out under Alex Forbes-Reed's name - blog posts, marketing copy, launch announcements, release notes, PR titles + bodies, commit messages Claude drafts, slack messages, customer emails, X/LinkedIn posts, conference abstracts, anything ghost-written. Triggers on "write a blog post", "draft this for me", "in my voice", "polish this", "make this sound like me", "rewrite as me", "/tone-of-voice", or any request to produce text Alex will publish. Once invoked, the same voice rules also govern Claude's own conversational replies in the session, so the assistant doesn't drift into LLM register. Does NOT apply to: reasoning / thinking tokens, code comments, neutral technical docs, or PR review-cycle comments Claude posts as itself (not the PR body).

Use when the user says "write an ADR", "/write-adr", "let's document this decision", "add an architecture decision record", or asks to capture a design/architecture decision in writing. Discovers the repo's existing ADR convention (location, numbering, format), discusses the decision interactively to draw out the context, alternatives, and consequences, then writes the ADR file matching the local style. Standalone counterpart to /plan-change, which writes an ADR + a Gherkin spec together.