drive-plan

The end-to-end "make this feature happen with planning rigour" workhorse. Composes three skills in order: /plan-change (produce ADR + spec), /implement-change (translate spec into code), /review-change (audit and dispatch fixes). Recommends /open-pr at the end without auto-opening.

This skill writes a lot of state — code, docs, commits — so it confirms with the user at every phase boundary. The cost of an unwanted commit or a half-written feature is higher than the cost of one extra "proceed?" question.

When to use this vs other drivers

• /drive-plan — substantial change warranting an ADR + Gherkin spec before writing code. Multi-step features, architecture changes, anything where "what is the right shape" needs discussion before implementation.
• /drive-change — clear or quick change where the implementation can be derived from conversation without formal planning. Bug fixes, small enhancements, "fix the typo" work.
• /drive-pr — iterate an already-open PR to merge-ready state.

Phase 0 — Intent and scope gate

Confirm the change warrants planning rigour. If the user describes a one-line bug fix, redirect to /drive-change rather than spinning up the full pipeline.