csp-spec-contractlisted

| Criterion | Rule | |-----------|------| | Completeness | All sections present; boundaries non-empty | | Testability | Every FR has ≥1 AC; no "should/might/could" in requirements | | Consistency | No contradictions between FR and boundaries | | Traceability | Each requirement maps to a source | | Feasibility | Constraints achievable with stated stack | ## Templates `csp-workflow/templates/change-artifacts/`: `proposal.md`, `spec.md`, `design.md`, `tasks.md` ## Integration - **Router triggers:** `spec`, `specification`, `contract`, `formalize` - **Downstream:** `/csp-spec-phase` → `/csp-discuss-phase` → `/csp-plan-phase` - **Review:** `csp-party-mode`, `csp-review-adversarial`, `csp-review-edge-case` ## Red Flags - Specs without explicit boundaries - Acceptance criteria requiring human judgment ("nice UX") - Copying input verbatim without falsification pass - SPEC files outside `.planning/` with no phase linkage ## Process 1. **Extract requirements:** Parse the input (idea, discussion, doc) into discrete functional requirements (FRs). Each FR must be a single, testable statement — no compound "and/or" requirements. 2. **Define boundaries:** For each FR, state explicitly what is in scope and what is out of scope. Boundaries prevent scope creep and rationalization ("we'll handle that later"). 3. **Write acceptance criteria:** Attach 1+ falsifiable AC to each FR. Use Given/When/Then or assertion format. If you can't write a test for it, the requirement is too vague — ref