plan-featurelisted

# plan-feature - drive the discussion that produces the ADR + spec A new feature usually has two documents worth writing before code: - An **ADR** for the architectural choices the feature requires (new table, new service boundary, new dependency, new transport, new pattern). - A **Gherkin spec** for the *behaviour* - what the user does, what the system does back, what counts as success, what the edge cases are. `plan-feature` is the "I'm starting something" entry point. It drives an interactive discussion to fill out both documents at the same time, then writes them cross-linked. It composes the same logic as `/write-adr` and `/write-spec` - you can use either of those standalone if you only need one half. ## When to use which skill | Situation | Right skill | | --- | --- | | Pure architectural decision (DB choice, library swap, topology) - no new user-facing behaviour | `/write-adr` | | New user-visible feature, but no architectural decision (a new filter on an existing screen) | `/write-spec` | | New feature **with** architectural implications (new service, new data model, new external dependency) | `/plan-feature` (this one) | | Iterating on a feature already shipped - adding a scenario to an existing spec | `/write-spec`, against the existing file | If the user invokes `/plan-feature` but only one document is actually called for, write only that one and explain - don't pad an ADR with a trivial decision just because the skill name says "plan". ## Phase 0 - D