new-ddd
SkillDocs & knowledgeInitialize 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 CLIs, libraries, SDKs, APIs, plugin systems, anything with a well-defined user-facing surface.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the new-ddd skill
What this skill tells your AI
The instructions your AI receives, as published by buildomator/buildomator in skills/new-ddd/SKILL.md and read by ahel’s review.
<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>
- 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.
- 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.
<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>
Signals
- GitHub stars
- 86
- Forks
- 12
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
new-ddd- Source
- github.com/buildomator/buildomator