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`). **Mutation ownership:** every `/sdd` sub-command executes in the root session. `/sdd init` and `/sdd clean` invoke enforcement skills inline and use the root's file and Git tools; they never spawn report-only PR-boundary reviewer agents to apply changes. Reviewer autonomy mode affects findings at review boundaries, not mutation ownership. 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