new-ddd
Initialize a new project using Documentation-Driven Development. Research, then write user-facing docs (SPEC.md) as the spec, then user validates docs, then phases derive from doc sections. Best for C
SKILL.mdskills/new-ddd/SKILL.md
GitHub<runtime_note>
**Copilot (VS Code):** Use `vscode_askquestions` wherever this workflow calls `AskUserQuestion`. They are equivalent, `vscode_askquestions` is the VS Code Copilot implementation of the same interactive question API.
</runtime_note>
<context>
**Documentation-Driven Development (DDD) mode for project initialization.** Differs from `/gsd:new-project`:
- Users validate
SPEC.md(user-facing docs: README, USAGE, CONCEPTS, API surface) rather thanREQUIREMENTS.md(REQ-IDs + acceptance criteria). - Phases derive from
SPEC.mdsections / chapters rather than REQ-ID clusters. - Each phase's success criterion is "implementation matches the corresponding SPEC.md section" rather than "tests pass and UAT satisfied."
When to use DDD vs. standard new-project:
- CLIs (the help text IS the spec)
- Libraries / SDKs (README + API reference is the contract)
- APIs (OpenAPI-style docs-as-spec)
- Plugin / extension systems (extension API surface = docs)
- Any project where the user-facing surface is the deliverable
When to skip DDD and use standard new-project:
- Exploratory research where the system shape is unknown
- Pure refactors or performance optimization
- Backend services with no human-readable interface
Flags:
--auto, Automatic mode. After config questions, runs research → docs → roadmap without further interaction. Expects idea document via @ reference.</context>
- Questioning (deep context gathering, same as new-project)
- Research (parallel, same as new-project)
- SPEC.md drafting (NEW, writes user-facing documentation as the spec)
- User validation of SPEC.md (NEW, read-through and approve before any phase work)
- Roadmap generation (phases derived from SPEC.md sections)
- STATE.md initialization
Creates:
.planning/PROJECT.md, project context.planning/config.json, workflow preferences (mode: dddset).planning/research/, domain research (optional)docs/SPEC.md, user-facing documentation as the spec.planning/REQUIREMENTS.md, thin traceability shell, each entry pointing at a SPEC.md section.planning/ROADMAP.md, phase structure derived from SPEC.md sections.planning/STATE.md, project memory (withmode: dddmarker)
After this command: Run /gsd:plan-phase 1 to start execution. Per-phase work proceeds as standard GSD; SPEC.md is the spec each phase implements against. Manual doc updates during execution are expected; per-phase doc-sync automation is held for a future release.
</objective>