Plan a Feature

Two failure modes: guessing at decisions that were the user's, and slicing by layer so nothing is visible until the last phase. Settle decisions first, then cut vertical slices.

Plan lives at plans/<feature-slug>.md — unless the repo keeps design docs elsewhere, or the user names a directory. Plan already covers this feature? Resume it.

Stage 1 before stage 2, always. A task list written around an open decision gets thrown away.

Stage 1 — Settle every decision

Frame the feature first. Four lines at the top of the plan, before any decision: The Job (what gets built), The Why (who needs it and what breaks or stalls without it), The Guardrail (what must not change or be touched — omit if none), Done means (the observable outcome that closes the feature). Can't write one from the request? It's the first question in the batch.

Read the code first. Files touched, patterns to match, libraries already there. Every option you offer must be one the codebase can take.

Answer what the code answers. Library support, existing schema, how a neighbouring feature did it — research, not decisions. Mark them `research`. Never ask what you could read.

Ask the rest, batches of 4, via AskUserQuestion. 2-4 concrete options each, recommended first, labelled (Recommended), real trade-off in the description. Decisions ("where do retries belong?"), not work ("add the retry handler").

Settle the demo. One per feature, at the end, after every phase merges; build-feature runs it verbatim and invents nothing. Ask whether the user wants one and what it is — steps they run themselves, a walkthrough the agent runs, an end-to-end check. none is valid and common. Record under ## Demo. none is unavailable only when a phase defers its Verify: the demo is that phase's only proof.