speclisted

# Spec Write a structured specification before any code. The spec is the shared source of truth — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing. ## When to use - Starting a new project, feature, or significant change. - Requirements are ambiguous or only exist as a vague idea. - The change touches multiple files or modules. - User says "write spec", "create prd", "spec out", "to spec", "写需求文档", "写规格", or "需求文档". **Not for:** single-line fixes, typos, or changes where requirements are unambiguous; changes needing design decisions only — use `architecture` for system design. ## Steps 1. **Surface assumptions.** Before writing any spec content, list what you're assuming (tech stack, auth model, database, target environment). Ask the user to correct before proceeding. Don't silently fill ambiguous requirements. 2. **Ask 3–5 clarifying questions** where the prompt is ambiguous — problem/goal, core functionality, scope, success criteria. Offer lettered options (A/B/C/D) so the user can respond "1A, 2C, 3B" for quick iteration. Only ask what's actually ambiguous. If the conversation already resolved the ambiguities, skip questions and synthesize directly. 3. **Write the spec** using the template below. Reframe vague requirements as testable success criteria ("make the dashboard faster" → "LCP < 2.5s on 4G; initial load < 500ms"). For PRD structure, user-story format, Given/When/Then acceptance criteria