spec-driven-developmentlisted

# Spec-Driven Development ## Overview SDD makes **specifications the source of truth** — code serves specs, not the other way around. Instead of prompting an AI with vague descriptions and hoping for the right output, you define precise specifications first, then let AI generate code strictly constrained by those specs. Core principle: *"When specifications drive implementation, pivots become systematic regenerations rather than manual rewrites."* Why it works: without a spec, AI makes thousands of micro-decisions silently. With a spec, those decisions are made by you — explicitly, before any code is written. ### Spec Levels | Level | What it means | Best for | |-------|--------------|---------| | **Spec-first** | Write spec upfront, implement immediately | Most features | | **Spec-anchored** | Maintain spec alongside code as it evolves | Long-lived features | | **Spec-as-source** | Spec is primary; code is generated, never hand-edited | Experimental, high-compliance | Start with spec-first. Move to spec-anchored when the feature stabilizes. ## Quick Start New to SDD? Four steps to your first spec-driven feature: 1. **Create your constitution** (once per project): `/sdd:init` — run this first, before any feature specs 2. **Surface AI assumptions** (before specifying): Ask the AI to list its implicit assumptions about roles, permissions, error behavior, and scope — then correct them before any AC is written 3. **Specify your first feature:** `/sdd:speci