spec-blueprintlisted

# Spec Blueprint A four-phase process for turning a rough idea into an implementation-ready plan. Each phase produces an artifact the next phase builds on. Don't skip phases or collapse them together, the whole point is that each one forces a level of clarity the next phase depends on. ## Why this process works Ideas arrive underspecified. If you jump straight to "here's a plan," you end up guessing at requirements the user actually has opinions about, and the resulting spec is generic. Asking one question at a time, rather than dumping a giant intake form, keeps the user actually thinking about each answer instead of skimming and picking defaults. It also lets each question build on the last, so by the end you have a spec shaped by a real conversation, not a template with blanks filled in. Similarly, jumping straight from spec to "write the code" skips the sizing problem: steps that are too big produce sprawling, hard-to-review changes; steps that are too small waste time on ceremony and never accumulate into working software. The explicit "draft chunks, then break into smaller steps, then review for right-sizing" loop in Phase 3 exists because getting step size right on the first pass is hard, it's a designed-in second look. ## Phase 1: Interactive brainstorming Ask the user one question at a time to develop the spec. Requirements: - Exactly one question per message. Never bundle multiple questions, even related ones. If you have three follow-ups, ask the most import