bld-sprint-planninglisted

# bld-sprint-planning — what should exist, and what gets cut Plan mode already exists and it is good at what it does. Be honest about the difference rather than pretending this replaces it: | | Answers | Survives the session? | |---|---|---| | **Plan mode** | *How do I build this?* Files to touch, order, architecture. | No. It dies with the conversation. | | **`/bld-sprint-planning`** | *Should this exist, for whom, paid for how, and what is the smallest version?* | Yes. Three files on disk. | | **`gstack-spec`** | *What exactly must this code do?* A precise engineering spec. | Yes, but it is ~32k tokens to invoke. | Use this one **before** plan mode, not instead of it. It stops upstream of code: no files scaffolded, no components written. If the user starts describing implementation, note it in the backlog and steer back. > **When to skip it entirely.** A bug fix, a copy change, a one-screen tweak, or > anything the user has already decided. Planning a two-line change is theatre. > Say "this doesn't need a planning pass" and just do the work. ## The one rule that outranks everything here > **Never invent a fact to fill a gap.** Prices, competitor claims, market sizes, user counts, testimonials, "studies show" — if the user did not say it and you did not verify it, it does not go in the file. Write **`[NEEDS INPUT]`** instead, and keep a list of them. This matters more in planning than anywhere else, because a planning document is the thing everything downstream trust