write-speclisted

# Write spec Shape acceptance criteria into a single reviewable spec document, then drive it to explicit sign-off. ## When to use Once `analyze-requirements` has produced acceptance criteria and edge cases for a feature or change, or whenever the workflow reaches the Spec step. ## Method Structure the document like GitHub `spec-kit`'s spec template and OpenSpec's requirement/scenario format — behavior contract, not implementation plan: 1. **Purpose.** 1-2 sentences: what this capability provides and to whom. No design detail. 2. **Requirements.** Numbered (`REQ-001`, `REQ-002`, …), each phrased with RFC 2119 strength — **MUST** (mandatory), **SHOULD** (recommended, exceptions allowed), **MAY** (optional). One requirement = one testable statement, not a paragraph of intent. 3. **Scenarios.** Under each requirement, one or more concrete scenarios in Given/When/Then, sourced directly from `analyze-requirements`' criteria and edge cases (happy path + boundaries + error paths). Mark any unresolved detail inline as `[NEEDS CLARIFICATION: …]` rather than guessing. 4. **Out-of-scope.** What this spec deliberately does not cover — prevents silent scope creep during implementation. 5. **Open questions.** Anything still unresolved, each tagged as a `need` per `policy.md` if it blocks a decision this role can't make alone. 6. **Review loop.** Show the draft to the requester/stakeholders. Revise on feedback. The spec is only "done" once it has explicit sign-off re