new-ddd

Files (1)

• SKILL.md

SKILL.md (first lines)

<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 `/bm:new-project`:

1. Users validate `SPEC.md` (user-facing docs: README, USAGE, CONCEPTS, API surface) rather than `REQUIREMENTS.md` (REQ-IDs + acceptance criteria).
2. Phases derive from `SPEC.md` sections / chapters rather than REQ-ID clusters.
3. 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>

<objective>
Initialize a new project through Documentation-Driven Development:

1. Questioning (deep context gathering, same as new-project)
2. Research (parallel, same as new-project)
3. **SPEC.md drafting** (NEW, writes user-facing documentation as the spec)
4. **User validation of SPEC.md** (NEW, read-through and approve before any phase work)
5. Roadmap generation (phases derived from SPEC.md sections)
6. STATE.md initialization

**Creates:**
- `.planning/PROJECT.md`, project context
- `.planning/config.json`, workflow preferences (`mode: ddd` set)
- `.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 (with `mode: ddd` marker)

**After this command:** Run `/bm: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>

<execution_context>
@${CLAUDE_PLUGIN_ROOT}/workflows/new-ddd.md
@${CLAUDE_PLUGIN_ROOT}/workflows/new-project.md
@${CLAUDE_PLUGIN_ROOT}/references/questioning.md
@${CLAUDE_PLUGIN_ROOT}/references/ui-brand.md
@${CLAUDE_PLUGIN_ROOT}/templates/project.md
</execution_context>

<process>
Execute the new-ddd workflow from @${CLAUDE_PLUGIN_ROOT}/workflows/new-ddd.md end-to-end.
Where the workflow says "as in new-project step N", follow the matching step from @${CLAUDE_PLUGIN_ROOT}/workflows/new-project.md to avoid duplicated logic.
Preserve all workflow gates (validation, approvals, commits, routing).
</process>

From buildomator/buildomator, MIT.

More from buildomator/buildomator