write-speclisted

# Write Spec Convert a vague request into a sharp spec the next phase executes against: discovery in frontier rounds → design alternatives → user approval → compact contract. ## Iron Rule <EXTREMELY-IMPORTANT> 1. NEVER skip the spec when the goal, scope, or success criteria are ambiguous, or when the request touches a high-risk surface (auth, billing, payments, credits, migration, data deletion, secrets, tokens, crypto, permissions, security). 2. NEVER start implementation before the user approves the design direction (Gate 1). 3. ASK discovery questions in FRONTIER ROUNDS: each round carries every question whose prerequisites are settled; a question depending on an open answer waits for the next round. RECOMMEND a default per question — the user confirms or overrides. Facts are never questions: anything the codebase or docs can answer is researched, not asked. 4. NEVER ship a spec that contains placeholders, contradictions, or untested assumptions about the user's intent. 5. A spec saved as a file needs a second approval on the written file itself (Gate 2) — verbal agreement and the written file drift apart. </EXTREMELY-IMPORTANT> Fires on a COMMISSION, never on musing: the user exploring an idea ("what if we…", "would X be worth it?" in any language) gets a discussion, not a spec interview; the router offers the spec once when the idea firms up. ## Skip when - A one-line fix with an obvious diff · the user supplied a written spec · the user said "skip spec" / "just wr