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.