Prefix all CDD slash commands with cdd-

.claude/commands/bootstrap.md → .claude/commands/cdd-bootstrap.md

@@ -1,6 +1,6 @@
-Scaffold a new greenfield project on the CDD workflow: `/bootstrap` (takes no argument).
+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 `/retrofit`: `/retrofit` adapts an *existing* project, `/bootstrap` creates a *new* one.
+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.
 
@@ -22,7 +22,7 @@ Have a conversation to define the project. Do not dump a rigid questionnaire; as
 
 The user may not have firm answers for everything; capture intent and mark genuinely open areas rather than inventing detail. This material becomes the project overview (`doc/knowledge_base/project-overview.md`) and seeds `CLAUDE.md`.
 
-**Off-ramp:** if discovery reveals this isn't really a project — a single self-contained artifact, finished in essentially one sitting, used as-is by future-you — apply the shared scope-triage heuristic (process doc, Section 6) and **offer to drop to `/quick-create`** instead of scaffolding the full substrate. Surface the signals; the human decides.
+**Off-ramp:** if discovery reveals this isn't really a project — a single self-contained artifact, finished in essentially one sitting, used as-is by future-you — apply the shared scope-triage heuristic (process doc, Section 6) and **offer to drop to `/cdd-quick-create`** instead of scaffolding the full substrate. Surface the signals; the human decides.
 
 **Checkpoint:** present a structured summary of the captured definition (the seven headings above). Get explicit confirmation or corrections before writing anything.
 
@@ -56,7 +56,7 @@ The bootstrap script refuses a path that already exists and is non-empty, so che
 [[ -e "<target>" && -n "$(ls -A "<target>" 2>/dev/null)" ]] && echo "exists and non-empty"
 ```
 
-If it exists and is non-empty, stop and ask for a different location — `/bootstrap` is for greenfield. (Suggest `/retrofit` if the user actually meant to install CDD into an existing project.) An absent path or an empty directory is fine.
+If it exists and is non-empty, stop and ask for a different location — `/cdd-bootstrap` is for greenfield. (Suggest `/cdd-retrofit` if the user actually meant to install CDD into an existing project.) An absent path or an empty directory is fine.
 
 **Checkpoint:** confirm the target path before staging the overlay.
 
@@ -118,6 +118,6 @@ Report:
   [[ -f "<target>/tools/<PROJECT_SLUG>-worktree.sh" ]] && source "<target>/tools/<PROJECT_SLUG>-worktree.sh"
   ```
 
-- The next command: `cd <target>`, run `claude`, and `/next-step` — it picks up the real first phase of the roadmap. Unlike a files-only install, there is **no** codebase-survey bootstrap phase to clear first; the docs are already populated.
+- The next command: `cd <target>`, run `claude`, and `/cdd-next-step` — it picks up the real first phase of the roadmap. Unlike a files-only install, there is **no** codebase-survey bootstrap phase to clear first; the docs are already populated.
 
-(The bootstrap script prints its own generic "fill in CLAUDE.md / look at the pre-filled roadmap" block; your summary supersedes it for the `/bootstrap` path, where those are already done.)
+(The bootstrap script prints its own generic "fill in CLAUDE.md / look at the pre-filled roadmap" block; your summary supersedes it for the `/cdd-bootstrap` path, where those are already done.)

.claude/commands/merge-main.md → .claude/commands/cdd-merge-main.md

@@ -140,7 +140,7 @@ adopt: <one-line description of what was adopted from main>
 
 ## 7. Verify
 
-Run the project build and tests to confirm the merged state is healthy. Use the same commands as `/pre-pr` step 2, with the same "tail 40 lines + exit code" capture pattern.
+Run the project build and tests to confirm the merged state is healthy. Use the same commands as `/cdd-pre-pr` step 2, with the same "tail 40 lines + exit code" capture pattern.
 
 If anything fails, report the failure and stop. Do not push.
 
@@ -156,7 +156,7 @@ Present a final summary:
 - [ ] Build passes
 - [ ] Tests pass
 
-Next: re-run /pre-pr before opening or updating the PR.
+Next: re-run /cdd-pre-pr before opening or updating the PR.
 ```
 
-The user should re-run `/pre-pr` in a fresh session after `/merge-main` to ensure the merged state passes all gates.
+The user should re-run `/cdd-pre-pr` in a fresh session after `/cdd-merge-main` to ensure the merged state passes all gates.

.claude/commands/next-step.md → .claude/commands/cdd-next-step.md

@@ -112,7 +112,7 @@ When you defer a question, list it explicitly in the handoff's Notes section so
 
 When the user signals they're ready, draft:
 
-**Branch name**: short, lowercase, underscore-separated. No `fix/` / `feature/` prefix. Derive from the task (e.g. `imu_calibration_wiring`, `setpoint_timeout_handling`). **Issue-driven mode**: prefix the name with the fixed `gh_issue_NN_` token so the issue number is durable and groups cleanly — `gh_issue_NN_<descriptive_slug>` (e.g. `gh_issue_42_dark_mode`). This token is the sole mechanism threading the issue to its PR (`/pre-pr` turns it into `Closes #NN`).
+**Branch name**: short, lowercase, underscore-separated. No `fix/` / `feature/` prefix. Derive from the task (e.g. `imu_calibration_wiring`, `setpoint_timeout_handling`). **Issue-driven mode**: prefix the name with the fixed `gh_issue_NN_` token so the issue number is durable and groups cleanly — `gh_issue_NN_<descriptive_slug>` (e.g. `gh_issue_42_dark_mode`). This token is the sole mechanism threading the issue to its PR (`/cdd-pre-pr` turns it into `Closes #NN`).
 
 **Implementation prompt**: a self-contained prompt for the new session. Critical rule, the new session will read `CLAUDE.md`, the roadmap, and the architecture/feature docs itself. Include only context that is **not** inferable from the repo:
 

.claude/commands/pre-pr.md → .claude/commands/cdd-pre-pr.md

@@ -71,7 +71,7 @@ git fetch origin main
 git log --oneline HEAD..origin/main
 ```
 
-If `origin/main` has advanced beyond the branch point, mention it and recommend running `/merge-main` before opening the PR. Do not merge from this session.
+If `origin/main` has advanced beyond the branch point, mention it and recommend running `/cdd-merge-main` before opening the PR. Do not merge from this session.
 
 <!-- cdd-only-begin -->
 ## Command-set drift (CDD repo only)
@@ -82,7 +82,7 @@ This check is specific to the CDD repo (the meta-project): it surfaces unintende
 ./scripts/command-drift-check.sh
 ```
 
-The script renders the template through `bootstrap-cdd-project.sh --stage` with this repo's own identifiers, so expected substitution drift cancels out mechanically. Intentionally one-sided files are listed in `scripts/command-drift-whitelist.txt`; CDD-meta-only sections of shared files (such as this one) are fenced with `cdd-only` markers and stripped before comparison. The same script asserts that the handoff schema headings match between the process doc (Section 2.6) and `next-step.md`, that the worktree helpers (`tools/cdd-worktree.sh` vs the rendered template helper) match from the first function definition onward, and that no `cdd-only` markers leak into the template itself. CI runs it on every PR via `template-smoke.yml`.
+The script renders the template through `bootstrap-cdd-project.sh --stage` with this repo's own identifiers, so expected substitution drift cancels out mechanically. Intentionally one-sided files are listed in `scripts/command-drift-whitelist.txt`; CDD-meta-only sections of shared files (such as this one) are fenced with `cdd-only` markers and stripped before comparison. The same script asserts that the handoff schema headings match between the process doc (Section 2.6) and `cdd-next-step.md`, that the worktree helpers (`tools/cdd-worktree.sh` vs the rendered template helper) match from the first function definition onward, and that no `cdd-only` markers leak into the template itself. CI runs it on every PR via `template-smoke.yml`.
 
 If the script exits 0, report "no drift" and continue. If it reports divergence, present each diff to the user; for each, the user decides whether to reconcile the repo copy, reconcile the template copy, or record a justified exception (a whitelist entry or a `cdd-only` fence). Apply fixes only on user approval. Do not auto-edit either tree from this step.
 
@@ -106,7 +106,7 @@ Present a checklist summary:
 - [ ] README up to date
 - [ ] Roadmap up to date
 - [ ] CI gaps surfaced: none / proposed (list them)
-- [ ] No upstream drift (or: /merge-main recommended)
+- [ ] No upstream drift (or: /cdd-merge-main recommended)
 - [ ] Reconciliation edits committed
 ```
 
@@ -140,7 +140,7 @@ gh auth status && git remote get-url origin   # origin should be a github.com UR
 
 If either is missing, say so in one line and skip this step (the checklist above still stands).
 
-If §6 found upstream drift, restate the recommendation to run `/merge-main` before opening the PR, and let the user decide whether to proceed anyway.
+If §6 found upstream drift, restate the recommendation to run `/cdd-merge-main` before opening the PR, and let the user decide whether to proceed anyway.
 
 Ask: **"Open a PR now?"** Do not pre-show a title or body, and do not print manual `gh` instructions — just ask whether to proceed.
 

.claude/commands/process-pr.md → .claude/commands/cdd-process-pr.md

@@ -1,8 +1,8 @@
 Address the open PR's review feedback: read the review comments for the current branch, triage them, implement the change-requests (pushing back where warranted), then auto-post in-thread replies and auto-commit + push the result.
 
-Run this command on the feature branch (not on main), after a PR has been opened and someone has reviewed it. It is a post-review side-loop, analogous in position to `/merge-main`.
+Run this command on the feature branch (not on main), after a PR has been opened and someone has reviewed it. It is a post-review side-loop, analogous in position to `/cdd-merge-main`.
 
-**Note on automation:** this command has a single checkpoint, placed up front: the triage plan in step 4. Once the user approves that plan, the rest of the run — edits, in-thread replies, commit, push — executes without further confirmation gates (see the process doc, "The `/process-pr` exception"). Do not add per-action gates after the plan is approved. Review threads are never resolved by this command; the user resolves them.
+**Note on automation:** this command has a single checkpoint, placed up front: the triage plan in step 4. Once the user approves that plan, the rest of the run — edits, in-thread replies, commit, push — executes without further confirmation gates (see the process doc, "The `/cdd-process-pr` exception"). Do not add per-action gates after the plan is approved. Review threads are never resolved by this command; the user resolves them.
 
 ## 1. Discover the open PR
 
@@ -89,7 +89,7 @@ Classify each open item and present a short plan to the user **before editing an
 Present the plan compactly, e.g.:
 
 ```
-## /process-pr triage (PR #NUMBER)
+## /cdd-process-pr triage (PR #NUMBER)
 
 1. [change-request] src/foo.ts:42 — "rename to X" → will rename.
 2. [question]        review summary — "why no retry?" → will answer, no code change.
@@ -147,7 +147,7 @@ Push to the PR branch. Sequencing note: if you want the reply in step 6 to cite
 Summarize what was processed:
 
 ```
-## /process-pr summary (PR #NUMBER)
+## /cdd-process-pr summary (PR #NUMBER)
 - Threads addressed: <count>
 - Questions answered: <count>
 - Change-requests declined: <count> (replies explain why)

.claude/commands/quick-create.md → .claude/commands/cdd-quick-create.md

@@ -1,18 +1,18 @@
-Produce a small, self-contained deliverable — a script plus a README, not a full CDD project: `/quick-create` (takes an optional one-line description of what to build).
+Produce a small, self-contained deliverable — a script plus a README, not a full CDD project: `/cdd-quick-create` (takes an optional one-line description of what to build).
 
-Run this command from a CDD-repo session. It is the third sibling of `/bootstrap` and `/retrofit`: `/bootstrap` creates a new CDD *project*, `/retrofit` adapts an *existing* one, and `/quick-create` creates a lightweight *deliverable* — a one-off artifact with none of the project substrate (no roadmap, no `doc/` tree, no `.claude/commands/`, no worktree helper, no baseline marker, no `/pre-pr` lifecycle). Like its siblings it exists only in the CDD repo and has no counterpart in `template/.claude/commands/`; unlike them it needs neither `template/` nor the bootstrap script, because a one-off has no template — it writes plain files directly (see the process doc, Section 6).
+Run this command from a CDD-repo session. It is the third sibling of `/cdd-bootstrap` and `/cdd-retrofit`: `/cdd-bootstrap` creates a new CDD *project*, `/cdd-retrofit` adapts an *existing* one, and `/cdd-quick-create` creates a lightweight *deliverable* — a one-off artifact with none of the project substrate (no roadmap, no `doc/` tree, no `.claude/commands/`, no worktree helper, no baseline marker, no `/cdd-pre-pr` lifecycle). Like its siblings it exists only in the CDD repo and has no counterpart in `template/.claude/commands/`; unlike them it needs neither `template/` nor the bootstrap script, because a one-off has no template — it writes plain files directly (see the process doc, Section 6).
 
-This is a **guided** command, but deliberately lighter than `/bootstrap`: a few natural questions, not the seven discovery headings. What it keeps from CDD is the part that pays off even for a one-off — a little guided discovery, clean single-purpose code, and a README so future-you can use it. What it drops is everything a single artifact doesn't need.
+This is a **guided** command, but deliberately lighter than `/cdd-bootstrap`: a few natural questions, not the seven discovery headings. What it keeps from CDD is the part that pays off even for a one-off — a little guided discovery, clean single-purpose code, and a README so future-you can use it. What it drops is everything a single artifact doesn't need.
 
 **Checkpoint discipline:** confirm the scope (step 1), then the captured definition (step 2), then the name and target (step 3) — each before moving on. The deliverable is written **files-first** (step 4), before any version control. The two outward-facing actions — a local commit (step 6) and a GitHub repo (step 7) — are offered separately, confirmed individually, and never done silently or by default.
 
 ## 1. Scope check (the gate)
 
-Before discovery, confirm this is actually a deliverable and not a project. Apply the shared scope-triage heuristic (process doc, Section 6): a task is a **project** (→ `/bootstrap`) when any of these hold — it is expected to evolve across many sessions and needs a roadmap; it has more than one cooperating component or an architecture worth documenting; it involves multiple collaborators or handoffs; it is long-lived and will accrete features. It is a **deliverable** (→ `/quick-create`) when none hold: a single self-contained artifact, finished in essentially one sitting, used as-is by future-you.
+Before discovery, confirm this is actually a deliverable and not a project. Apply the shared scope-triage heuristic (process doc, Section 6): a task is a **project** (→ `/cdd-bootstrap`) when any of these hold — it is expected to evolve across many sessions and needs a roadmap; it has more than one cooperating component or an architecture worth documenting; it involves multiple collaborators or handoffs; it is long-lived and will accrete features. It is a **deliverable** (→ `/cdd-quick-create`) when none hold: a single self-contained artifact, finished in essentially one sitting, used as-is by future-you.
 
-If, from the description (`$ARGUMENTS`) or an opening exchange, project-signals trip, **surface them and offer to switch to `/bootstrap`** rather than proceeding. The human decides.
+If, from the description (`$ARGUMENTS`) or an opening exchange, project-signals trip, **surface them and offer to switch to `/cdd-bootstrap`** rather than proceeding. The human decides.
 
-**Checkpoint:** if any project-signal is present, name it and get an explicit "stay lightweight" or "switch to `/bootstrap`" before continuing.
+**Checkpoint:** if any project-signal is present, name it and get an explicit "stay lightweight" or "switch to `/cdd-bootstrap`" before continuing.
 
 ## 2. Lightweight discovery
 
@@ -89,4 +89,4 @@ Report:
 - What was written: the artifact(s) and the README, plus any optional extras (inline dependency metadata, license header).
 - Whether a smoke test ran and its result.
 - Whether a local commit was made (step 6) and whether a GitHub repo was created (step 7).
-- That this is a **deliverable**, not a project: there is no roadmap, worktree helper, or `/pre-pr` lifecycle. If it later grows into a project, `/retrofit` can install CDD onto it.
+- That this is a **deliverable**, not a project: there is no roadmap, worktree helper, or `/cdd-pre-pr` lifecycle. If it later grows into a project, `/cdd-retrofit` can install CDD onto it.