Metadata
sdd-spec2.0gentleman-programmingMITWhen It’s Triggered
The orchestrator launchessdd-spec when:
- User runs
/sdd-new <change-name>(after proposal) - User wants to write or update specifications
- Proposal is complete and ready for behavioral specification
What It Does
Step 1: Identify Affected Domains
From the proposal’s “Affected Areas”, determines which spec domains are touched. Groups changes by domain (e.g.,auth/, payments/, ui/).
Step 2: Read Existing Specs
Ifopenspec/specs/{domain}/spec.md exists, reads it to understand CURRENT behavior. Delta specs describe CHANGES to this behavior.
Step 3: Write Delta Specs
Creates specs inside the change folder:Delta Spec Format
For domains with existing specs:Full Spec Format
For NEW domains (no existing spec):RFC 2119 Keywords
Use these keywords to express requirement strength:| Keyword | Meaning |
|---|---|
| MUST / SHALL | Absolute requirement |
| MUST NOT / SHALL NOT | Absolute prohibition |
| SHOULD | Recommended, but exceptions may exist with justification |
| SHOULD NOT | Not recommended, but may be acceptable with justification |
| MAY | Optional |
Example: Delta Spec
Example: Full Spec (New Domain)
Result Envelope Example
Rules
- ALWAYS use Given/When/Then format for scenarios
- ALWAYS use RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) for requirement strength
- If existing specs exist, write DELTA specs (ADDED/MODIFIED/REMOVED sections)
- If NO existing specs exist for the domain, write a FULL spec
- Every requirement MUST have at least ONE scenario
- Include both happy path AND edge case scenarios
- Keep scenarios TESTABLE — someone should be able to write an automated test from each one
- DO NOT include implementation details in specs — specs describe WHAT, not HOW
- Apply any
rules.specsfromopenspec/config.yaml - Return a structured envelope with:
status,executive_summary,detailed_report,artifacts,next_recommended, andrisks
Scenario Writing Tips
Good Scenario
Bad Scenario (too vague)
Good Scenario (edge case)
Bad Scenario (includes HOW)
Related
- Proposer — Creates the proposal that informs specs
- Designer — Uses specs to create technical design
- Verifier — Validates implementation against specs
- OpenSpec Convention