spec-driven-developmentlisted

# Spec-Driven Development A product specification (`sdd/`) is the single source of truth for **what the product does and why**. It is not a record of what the code currently does. It is not a bug tracker. It is not a changelog of every commit. The full enforcement layer lives in the `spec-discipline` rule (loaded automatically). This skill describes the workflow on top of those rules. ## How it works at a glance The user runs `/sdd init` once to bootstrap. After that, they "vibe code" — write code, push, walk away. The `spec-reviewer` and `doc-updater` agents auto-detect the `sdd/` folder and enforce discipline on every PR-boundary event, in the mode set by `sdd/config.yml` (`interactive`, `auto`, or `unleashed`). The user only invokes `/sdd` directly to: - Bootstrap a new project (`/sdd init` → invokes the `sdd-init` skill) - Manually add or modify requirements (`/sdd edit`, `/sdd add` — body below) - Rescue a rotted spec (`/sdd clean` → invokes the `sdd-clean` skill) - Switch autonomy mode (`/sdd mode` — body below) ## Sub-commands | Command | Skill / body | |---|---| | `/sdd` | Help screen (the `/sdd` command file) | | `/sdd init [idea]` | Invoke the `sdd-init` skill (greenfield, import, resume) | | `/sdd edit {domain}` | This skill, § /sdd edit | | `/sdd add {domain}` | This skill, § /sdd add | | `/sdd clean` | Invoke the `sdd-clean` skill (mode-aware spec rescue) | | `/sdd mode {interactive\|auto\|unleashed}` | This skill, § /sdd mode | ## Spec structure (nested