cdd: Command for Claude Code

Scaffold a new greenfield project on the CDD workflow: /cdd-bootstrap (takes no argument).

Run this command from a CDD-repo session (it needs the CDD repo's template/ and bootstrap-cdd-project.sh). This command exists only in the CDD repo; it deliberately has no counterpart in template/.claude/commands/ (it operates on a new target project, so downstream projects have no use for it — see the process doc, Section 2.7). It is the greenfield sibling of /cdd-retrofit: /cdd-retrofit adapts an existing project, /cdd-bootstrap creates a new one.

This is a guided command, not a brief-to-files converter. The discovery conversation is part of the job: you walk the user through defining the project, then encode the result into the initial docs and roadmap, then scaffold the project in a single bootstrap invocation. The generated project starts with a real, filled-in overview, CLAUDE.md, and roadmap — not the template's pre-filled "survey the codebase" bootstrap phase, which is for files-only installs.

The command takes no argument: the project's name, directory, and location all emerge from the discovery conversation, so there is nothing meaningful to pass up front. The target path is proposed and confirmed in step 4, once the identifiers are settled.

Checkpoint discipline: confirm the project definition (step 1), then the draft roadmap (step 2), then the two identifiers and the target location (steps 3–4) — each before moving on. Nothing is rendered until all are approved. The scaffold commit is created only after the roadmap is approved. Outward-facing actions (creating a GitHub repo, editing ~/.bashrc) are confirmed separately and never done silently.

1. Guided discovery

Have a conversation to define the project. Do not dump a rigid questionnaire; ask in natural batches, probe vague or one-word answers, and reflect back what you heard. Cover, at minimum:

• What it is — one paragraph, plain terms.
• Goals — why it exists; the problem it solves or outcome it produces; what success looks like.
• What it does — the high-level capabilities, coarse-grained.
• What it explicitly does not do — the non-goals. Push for these; they are load-bearing and easy to skip.
• Constraints — language/platform, hard technical limits, regulatory/business constraints, compatibility, deadlines.
• Architecture intentions — intended high-level shape: major components, how they relate, external boundaries, structural principles the project commits to.
• Audience — who consumes it (end users, other services, a team, future-you).
• Engineering floor — what the project commits to for tested behaviour, continuous integration, lint & format, and dependency & toolchain hygiene (the negotiable rows of the template contract). Ask this as one batch: nothing exists yet to detect, so the answers are commitments, and most of them will honestly be expected.
• Where issues and code review live — the tracker (where issues live) and the code host (where pull requests are reviewed). Always ask; never assume. Offer GitHub (Issues + pull requests) as the default answer. The answer becomes the project's capability bindings in .cdd/ (process doc Section 2.16), written by the bootstrap script in step 6:
  • GitHub — bind both to the shipped GitHub adapters.
  • Jira for issues — ask for the Jira site (e.g. acme.atlassian.net) and the project key (e.g. ABC) only. Never ask for credentials: tell the user they set JIRA_EMAIL and JIRA_API_TOKEN in their own shell. The code host is asked separately.
  • GitLab — for either capability or both (gitlab.com or a self-managed instance). Ask for the GitLab URL (default gitlab.com) and the project path (e.g. group/project) only. Never ask for credentials: tell the user they set GITLAB_TOKEN (a token with the api scope) in their own shell.
  • Anything CDD ships no adapter for (Bitbucket, …) — say in one line that no binding is written for it and the issue and PR features skip until one is bound; a project adapter can be written later against doc/architecture/capability-adapters.md.