write-speclisted

# Write Spec Define-phase entry skill. Convert a vague request into a sharp spec the next phase can execute against. Discovery questions one at a time, 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 one focused question at a time during discovery unless the user explicitly asks for a full questionnaire. RECOMMEND a default answer per question — user confirms or overrides. 4. NEVER ship a spec that contains placeholders, contradictions, or untested assumptions about the user's intent. 5. WHEN the spec is saved as a file, require a second approval on the written file itself (Gate 2) — verbal agreement and 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 (using-rolepod, Commission vs conversation). ## When to use - User asks for a feature with vague boundaries - Multiple valid implementations exist and the choice changes the diff - The request touches a high-risk surface - The codebase has n