new-ddd

SkillDocs & knowledge

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 CLIs, libraries, SDKs, APIs, plugin systems, anything with a well-defined user-facing surface.

Available today. Use it from your connected AI after setup.

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>

  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.
  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 /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