claude-code-pilot 2.0.0 → 3.0.0

package/src/pilot/templates/claude-md.md

@@ -0,0 +1,122 @@
+# CLAUDE.md Template
+
+Template for project-root `CLAUDE.md` — auto-generated by `ccp-tools generate-claude-md`.
+
+Contains 6 marker-bounded sections. Each section is independently updatable.
+The `generate-claude-md` subcommand manages 5 sections (project, stack, conventions, architecture, workflow enforcement).
+The profile section is managed exclusively by `generate-claude-profile`.
+
+---
+
+## Section Templates
+
+### Project Section
+```
+<!-- CCP:project-start source:PROJECT.md -->
+## Project
+
+{{project_content}}
+<!-- CCP:project-end -->
+```
+
+**Fallback text:**
+```
+Project not yet initialized. Run /ccp:new-project to set up.
+```
+
+### Stack Section
+```
+<!-- CCP:stack-start source:STACK.md -->
+## Technology Stack
+
+{{stack_content}}
+<!-- CCP:stack-end -->
+```
+
+**Fallback text:**
+```
+Technology stack not yet documented. Will populate after codebase mapping or first phase.
+```
+
+### Conventions Section
+```
+<!-- CCP:conventions-start source:CONVENTIONS.md -->
+## Conventions
+
+{{conventions_content}}
+<!-- CCP:conventions-end -->
+```
+
+**Fallback text:**
+```
+Conventions not yet established. Will populate as patterns emerge during development.
+```
+
+### Architecture Section
+```
+<!-- CCP:architecture-start source:ARCHITECTURE.md -->
+## Architecture
+
+{{architecture_content}}
+<!-- CCP:architecture-end -->
+```
+
+**Fallback text:**
+```
+Architecture not yet mapped. Follow existing patterns found in the codebase.
+```
+
+### Workflow Enforcement Section
+```
+<!-- CCP:workflow-start source:CCP defaults -->
+## CCP Workflow Enforcement
+
+Before using Edit, Write, or other file-changing tools, start work through a CCP command so planning artifacts and execution context stay in sync.
+
+Use these entry points:
+- `/ccp:quick` for small fixes, doc updates, and ad-hoc tasks
+- `/ccp:debug` for investigation and bug fixing
+- `/ccp:execute-phase` for planned phase work
+
+Do not make direct repo edits outside a CCP workflow unless the user explicitly asks to bypass it.
+<!-- CCP:workflow-end -->
+```
+
+### Profile Section (Placeholder Only)
+```
+<!-- CCP:profile-start -->
+## Developer Profile
+
+> Profile not yet configured. Run `/ccp:profile-user` to generate your developer profile.
+> This section is managed by `generate-claude-profile` — do not edit manually.
+<!-- CCP:profile-end -->
+```
+
+**Note:** This section is NOT managed by `generate-claude-md`. It is managed exclusively
+by `generate-claude-profile`. The placeholder above is only used when creating a new
+CLAUDE.md file and no profile section exists yet.
+
+---
+
+## Section Ordering
+
+1. **Project** — Identity and purpose (what this project is)
+2. **Stack** — Technology choices (what tools are used)
+3. **Conventions** — Code patterns and rules (how code is written)
+4. **Architecture** — System structure (how components fit together)
+5. **Workflow Enforcement** — Default CCP entry points for file-changing work
+6. **Profile** — Developer behavioral preferences (how to interact)
+
+## Marker Format
+
+- Start: `<!-- CCP:{name}-start source:{file} -->`
+- End: `<!-- CCP:{name}-end -->`
+- Source attribute enables targeted updates when source files change
+- Partial match on start marker (without closing `-->`) for detection
+
+## Fallback Behavior
+
+When a source file is missing, fallback text provides Claude-actionable guidance:
+- Guides Claude's behavior in the absence of data
+- Not placeholder ads or "missing" notices
+- Each fallback tells Claude what to do, not just what's absent

package/{gsd/get-shit-done → src/pilot}/templates/codebase/architecture.md

@@ -146,7 +146,7 @@ Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code org
 
 **CLI Command Execution:**
 
-1. User runs: `gsd new-project`
+1. User runs: `ccp new-project`
 2. Commander parses args and flags
 3. Command handler invoked (`src/commands/new-project.ts`)
 4. Handler calls service methods (`src/services/project.ts` → `create()`)
@@ -180,7 +180,7 @@ Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code org
 
 **CLI Entry:**
 - Location: `src/index.ts`
-- Triggers: User runs `gsd <command>`
+- Triggers: User runs `ccp <command>`
 - Responsibilities: Register commands, parse args, display help
 
 **Commands:**

package/{gsd/get-shit-done → src/pilot}/templates/codebase/structure.md

@@ -123,11 +123,11 @@ Template for `.planning/codebase/STRUCTURE.md` - captures physical file organiza
 ## Directory Layout
 
 ```
-get-shit-done/
+pilot/
 ├── bin/                # Executable entry points
 ├── commands/           # Slash command definitions
-│   └── gsd/           # GSD-specific commands
-├── get-shit-done/     # Skill resources
+│   └── ccp/           # CCP-specific commands
+├── pilot/     # Skill resources
 │   ├── references/    # Principle documents
 │   ├── templates/     # File templates
 │   └── workflows/     # Multi-step procedures
@@ -145,25 +145,25 @@ get-shit-done/
 - Key files: install.js - handles npx installation
 - Subdirectories: None
 
-**commands/gsd/**
+**commands/ccp/**
 - Purpose: Slash command definitions for Claude Code
 - Contains: *.md files (one per command)
 - Key files: new-project.md, plan-phase.md, execute-plan.md
 - Subdirectories: None (flat structure)
 
-**get-shit-done/references/**
+**pilot/references/**
 - Purpose: Core philosophy and guidance documents
 - Contains: principles.md, questioning.md, plan-format.md
 - Key files: principles.md - system philosophy
 - Subdirectories: None
 
-**get-shit-done/templates/**
+**pilot/templates/**
 - Purpose: Document templates for .planning/ files
 - Contains: Template definitions with frontmatter
 - Key files: project.md, roadmap.md, plan.md, summary.md
 - Subdirectories: codebase/ (new - for stack/architecture/structure templates)
 
-**get-shit-done/workflows/**
+**pilot/workflows/**
 - Purpose: Reusable multi-step procedures
 - Contains: Workflow definitions called by commands
 - Key files: execute-plan.md, research-phase.md
@@ -206,20 +206,20 @@ get-shit-done/
 ## Where to Add New Code
 
 **New Slash Command:**
-- Primary code: `commands/gsd/{command-name}.md`
+- Primary code: `commands/ccp/{command-name}.md`
 - Tests: `tests/commands/{command-name}.test.js` (if testing implemented)
 - Documentation: Update `README.md` with new command
 
 **New Template:**
-- Implementation: `get-shit-done/templates/{name}.md`
+- Implementation: `pilot/templates/{name}.md`
 - Documentation: Template is self-documenting (includes guidelines)
 
 **New Workflow:**
-- Implementation: `get-shit-done/workflows/{name}.md`
-- Usage: Reference from command with `@~/.claude/get-shit-done/workflows/{name}.md`
+- Implementation: `pilot/workflows/{name}.md`
+- Usage: Reference from command with `@~/.claude/pilot/workflows/{name}.md`
 
 **New Reference Document:**
-- Implementation: `get-shit-done/references/{name}.md`
+- Implementation: `pilot/references/{name}.md`
 - Usage: Reference from commands/workflows as needed
 
 **Utilities:**
@@ -228,7 +228,7 @@ get-shit-done/
 
 ## Special Directories
 
-**get-shit-done/**
+**pilot/**
 - Purpose: Resources installed to ~/.claude/
 - Source: Copied by bin/install.js during installation
 - Committed: Yes (source of truth)

package/{gsd/get-shit-done → src/pilot}/templates/context.md

@@ -7,8 +7,8 @@ Template for `.planning/phases/XX-name/{phase_num}-CONTEXT.md` - captures implem
 **Key principle:** Categories are NOT predefined. They emerge from what was actually discussed for THIS phase. A CLI phase has CLI-relevant sections, a UI phase has UI-relevant sections.
 
 **Downstream consumers:**
-- `gsd-phase-researcher` — Reads decisions to focus research (e.g., "card layout" → research card component patterns)
-- `gsd-planner` — Reads decisions to create specific tasks (e.g., "infinite scroll" → task includes virtualization)
+- `ccp-phase-researcher` — Reads decisions to focus research (e.g., "card layout" → research card component patterns)
+- `ccp-planner` — Reads decisions to create specific tasks (e.g., "infinite scroll" → task includes virtualization)
 
 ---
 
@@ -291,7 +291,7 @@ The output should answer: "What does the researcher need to investigate? What ch
 
 **After creation:**
 - File lives in phase directory: `.planning/phases/XX-name/{phase_num}-CONTEXT.md`
-- `gsd-phase-researcher` uses decisions to focus investigation
-- `gsd-planner` uses decisions + research to create executable tasks
+- `ccp-phase-researcher` uses decisions to focus investigation
+- `ccp-planner` uses decisions + research to create executable tasks
 - Downstream agents should NOT need to ask the user again about captured decisions
 </guidelines>

package/src/pilot/templates/copilot-instructions.md

@@ -0,0 +1,7 @@
+# Instructions for CCP
+
+- Use the claude-code-pilot skill when the user asks for CCP or uses a `ccp-*` command.
+- Treat `/ccp-...` or `ccp-...` as command invocations and load the matching file from `.github/skills/ccp-*`.
+- When a command says to spawn a subagent, prefer a matching custom agent from `.github/agents`.
+- Do not apply CCP workflows unless the user explicitly asks for them.
+- After completing any `ccp-*` command (or any deliverable it triggers: feature, bug fix, tests, docs, etc.), ALWAYS: (1) offer the user the next step by prompting via `ask_user`; repeat this feedback loop until the user explicitly indicates they are done.

package/{gsd/get-shit-done → src/pilot}/templates/debug-subagent-prompt.md

@@ -1,6 +1,6 @@
 # Debug Subagent Prompt Template
 
-Template for spawning gsd-debugger agent. The agent contains all debugging expertise - this template provides problem context only.
+Template for spawning ccp-debugger agent. The agent contains all debugging expertise - this template provides problem context only.
 
 ---
 
@@ -51,18 +51,18 @@ Create: .planning/debug/{slug}.md
 
 ## Usage
 
-**From /gsd:debug:**
+**From /ccp:debug:**
 ```python
 Task(
   prompt=filled_template,
-  subagent_type="gsd-debugger",
+  subagent_type="ccp-debugger",
   description="Debug {slug}"
 )
 ```
 
 **From diagnose-issues (UAT):**
 ```python
-Task(prompt=template, subagent_type="gsd-debugger", description="Debug UAT-001")
+Task(prompt=template, subagent_type="ccp-debugger", description="Debug UAT-001")
 ```
 
 ---

package/src/pilot/templates/dev-preferences.md

@@ -0,0 +1,21 @@
+---
+description: Load developer preferences into this session
+---
+
+# Developer Preferences
+
+> Generated by CCP on {{generated_at}} from {{data_source}}.
+> Run `/ccp:profile-user --refresh` to regenerate.
+
+## Behavioral Directives
+
+Follow these directives when working with this developer. Higher confidence
+directives should be applied directly. Lower confidence directives should be
+tried with hedging ("Based on your profile, I'll try X -- let me know if
+that's off").
+
+{{behavioral_directives}}
+
+## Stack Preferences
+
+{{stack_preferences}}

package/{gsd/get-shit-done → src/pilot}/templates/discovery.md

@@ -4,7 +4,7 @@ Template for `.planning/phases/XX-name/DISCOVERY.md` - shallow research for libr
 
 **Purpose:** Answer "which library/option should we use" questions during mandatory discovery in plan-phase.
 
-For deep ecosystem research ("how do experts build this"), use `/gsd:research-phase` which produces RESEARCH.md.
+For deep ecosystem research ("how do experts build this"), use `/ccp:research-phase` which produces RESEARCH.md.
 
 ---
 
@@ -142,5 +142,5 @@ Create `.planning/phases/XX-name/DISCOVERY.md`:
 - Niche/complex domains (3D, games, audio, shaders)
 - Need ecosystem knowledge, not just library choice
 - "How do experts build this" questions
-- Use `/gsd:research-phase` for these
+- Use `/ccp:research-phase` for these
 </guidelines>

package/src/pilot/templates/discussion-log.md

@@ -0,0 +1,63 @@
+# Discussion Log Template
+
+Template for `.planning/phases/XX-name/{phase_num}-DISCUSSION-LOG.md` — audit trail of discuss-phase Q&A sessions.
+
+**Purpose:** Software audit trail for decision-making. Captures all options considered, not just the selected one. Separate from CONTEXT.md which is the implementation artifact consumed by downstream agents.
+
+**NOT for LLM consumption.** This file should never be referenced in `<files_to_read>` blocks or agent prompts.
+
+## Format
+
+```markdown
+# Phase [X]: [Name] - Discussion Log
+
+> **Audit trail only.** Do not use as input to planning, research, or execution agents.
+> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
+
+**Date:** [ISO date]
+**Phase:** [phase number]-[phase name]
+**Areas discussed:** [comma-separated list]
+
+---
+
+## [Area 1 Name]
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| [Option 1] | [Brief description] | |
+| [Option 2] | [Brief description] | ✓ |
+| [Option 3] | [Brief description] | |
+
+**User's choice:** [Selected option or verbatim free-text response]
+**Notes:** [Any clarifications or rationale provided during discussion]
+
+---
+
+## [Area 2 Name]
+
+...
+
+---
+
+## Claude's Discretion
+
+[Areas delegated to Claude's judgment — list what was deferred and why]
+
+## Deferred Ideas
+
+[Ideas mentioned but not in scope for this phase]
+
+---
+
+*Phase: XX-name*
+*Discussion log generated: [date]*
+```
+
+## Rules
+
+- Generated automatically at end of every discuss-phase session
+- Includes ALL options considered, not just the selected one
+- Includes user's freeform notes and clarifications
+- Clearly marked as audit-only, not an implementation artifact
+- Does NOT interfere with CONTEXT.md generation or downstream agent behavior
+- Committed alongside CONTEXT.md in the same git commit

package/{gsd/get-shit-done → src/pilot}/templates/phase-prompt.md

@@ -1,6 +1,6 @@
 # Phase Prompt Template
 
-> **Note:** Planning methodology is in `agents/gsd-planner.md`.
+> **Note:** Planning methodology is in `agents/ccp-planner.md`.
 > This template defines the PLAN.md output format that the agent produces.
 
 Template for `.planning/phases/XX-name/{phase}-{plan}-PLAN.md` - executable phase plans optimized for parallel execution.
@@ -38,10 +38,10 @@ Output: [What artifacts will be created]
 </objective>
 
 <execution_context>
-@~/.claude/get-shit-done/workflows/execute-plan.md
-@~/.claude/get-shit-done/templates/summary.md
+@~/.claude/pilot/workflows/execute-plan.md
+@~/.claude/pilot/templates/summary.md
 [If plan contains checkpoint tasks (type="checkpoint:*"), add:]
-@~/.claude/get-shit-done/references/checkpoints.md
+@~/.claude/pilot/references/checkpoints.md
 </execution_context>
 
 <context>
@@ -76,7 +76,7 @@ Output: [What artifacts will be created]
   <done>[Acceptance criteria]</done>
 </task>
 
-<!-- For checkpoint task examples and patterns, see @~/.claude/get-shit-done/references/checkpoints.md -->
+<!-- For checkpoint task examples and patterns, see @~/.claude/pilot/references/checkpoints.md -->
 <!-- Key rule: Claude starts dev server BEFORE human-verify checkpoints. User only visits URLs. -->
 
 <task type="checkpoint:decision" gate="blocking">
@@ -134,7 +134,7 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
 | `user_setup` | No | Array of human-required setup items (external services) |
 | `must_haves` | Yes | Goal-backward verification criteria (see below) |
 
-**Wave is pre-computed:** Wave numbers are assigned during `/gsd:plan-phase`. Execute-phase reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
+**Wave is pre-computed:** Wave numbers are assigned during `/ccp:plan-phase`. Execute-phase reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
 
 **Must-haves enable verification:** The `must_haves` field carries goal-backward requirements from planning to execution. After all plans complete, execute-phase spawns a verification subagent that checks these criteria against the actual codebase.
 
@@ -270,7 +270,7 @@ TDD features get dedicated plans with `type: tdd`.
 → Yes: Create a TDD plan
 → No: Standard task in standard plan
 
-See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
+See `~/.claude/pilot/references/tdd.md` for TDD plan structure.
 
 ---
 
@@ -374,9 +374,9 @@ Output: Working dashboard component.
 </objective>
 
 <execution_context>
-@~/.claude/get-shit-done/workflows/execute-plan.md
-@~/.claude/get-shit-done/templates/summary.md
-@~/.claude/get-shit-done/references/checkpoints.md
+@~/.claude/pilot/workflows/execute-plan.md
+@~/.claude/pilot/templates/summary.md
+@~/.claude/pilot/references/checkpoints.md
 </execution_context>
 
 <context>
@@ -499,7 +499,7 @@ user_setup:
 
 **Result:** Execute-plan generates `{phase}-USER-SETUP.md` with checklist for the user.
 
-See `~/.claude/get-shit-done/templates/user-setup.md` for full schema and examples
+See `~/.claude/pilot/templates/user-setup.md` for full schema and examples
 
 ---
 
@@ -566,4 +566,4 @@ Task completion ≠ Goal achievement. A task "create chat component" can complet
 5. Gaps found → fix plans created → execute → re-verify
 6. All must_haves pass → phase complete
 
-See `~/.claude/get-shit-done/workflows/verify-phase.md` for verification logic.
+See `~/.claude/pilot/workflows/verify-phase.md` for verification logic.

package/{gsd/get-shit-done → src/pilot}/templates/planner-subagent-prompt.md

@@ -1,6 +1,6 @@
 # Planner Subagent Prompt Template
 
-Template for spawning gsd-planner agent. The agent contains all planning expertise - this template provides planning context only.
+Template for spawning ccp-planner agent. The agent contains all planning expertise - this template provides planning context only.
 
 ---
 
@@ -34,7 +34,7 @@ Template for spawning gsd-planner agent. The agent contains all planning experti
 </planning_context>
 
 <downstream_consumer>
-Output consumed by /gsd:execute-phase
+Output consumed by /ccp:execute-phase
 Plans must be executable prompts with:
 - Frontmatter (wave, depends_on, files_modified, autonomous)
 - Tasks in XML format
@@ -68,20 +68,20 @@ Before returning PLANNING COMPLETE:
 
 ## Usage
 
-**From /gsd:plan-phase (standard mode):**
+**From /ccp:plan-phase (standard mode):**
 ```python
 Task(
   prompt=filled_template,
-  subagent_type="gsd-planner",
+  subagent_type="ccp-planner",
   description="Plan Phase {phase}"
 )
 ```
 
-**From /gsd:plan-phase --gaps (gap closure mode):**
+**From /ccp:plan-phase --gaps (gap closure mode):**
 ```python
 Task(
   prompt=filled_template,  # with mode: gap_closure
-  subagent_type="gsd-planner",
+  subagent_type="ccp-planner",
   description="Plan gaps for Phase {phase}"
 )
 ```
@@ -114,4 +114,4 @@ Continue: {standard | gap_closure}
 
 ---
 
-**Note:** Planning methodology, task breakdown, dependency analysis, wave assignment, TDD detection, and goal-backward derivation are baked into the gsd-planner agent. This template only passes context.
+**Note:** Planning methodology, task breakdown, dependency analysis, wave assignment, TDD detection, and goal-backward derivation are baked into the ccp-planner agent. This template only passes context.

package/{gsd/get-shit-done → src/pilot}/templates/project.md

@@ -147,7 +147,7 @@ PROJECT.md evolves throughout the project lifecycle.
 
 For existing codebases:
 
-1. **Map codebase first** via `/gsd:map-codebase`
+1. **Map codebase first** via `/ccp:map-codebase`
 
 2. **Infer Validated requirements** from existing code:
    - What does the codebase actually do?

package/{gsd/get-shit-done → src/pilot}/templates/research.md

@@ -18,7 +18,7 @@ Template for `.planning/phases/XX-name/{phase_num}-RESEARCH.md` - comprehensive
 <user_constraints>
 ## User Constraints (from CONTEXT.md)
 
-**CRITICAL:** If CONTEXT.md exists from /gsd:discuss-phase, copy locked decisions here verbatim. These MUST be honored by the planner.
+**CRITICAL:** If CONTEXT.md exists from /ccp:discuss-phase, copy locked decisions here verbatim. These MUST be honored by the planner.
 
 ### Locked Decisions
 [Copy from CONTEXT.md `## Decisions` section - these are NON-NEGOTIABLE]
@@ -528,7 +528,7 @@ function useVehicleControls(rigidBodyRef) {
 - When "how do experts do this" matters more than "which library"
 
 **Structure:**
-- Use XML tags for section markers (matches GSD templates)
+- Use XML tags for section markers (matches CCP templates)
 - Seven core sections: summary, standard_stack, architecture_patterns, dont_hand_roll, common_pitfalls, code_examples, sources
 - All sections required (drives comprehensive research)
 

package/{gsd/get-shit-done → src/pilot}/templates/state.md

@@ -145,10 +145,10 @@ Updated after each plan completion.
 
 **Decisions:** Reference to PROJECT.md Key Decisions table, plus recent decisions summary for quick access. Full decision log lives in PROJECT.md.
 
-**Pending Todos:** Ideas captured via /gsd:add-todo
+**Pending Todos:** Ideas captured via /ccp:add-todo
 - Count of pending todos
 - Reference to .planning/todos/pending/
-- Brief list if few, count if many (e.g., "5 pending todos — see /gsd:check-todos")
+- Brief list if few, count if many (e.g., "5 pending todos — see /ccp:check-todos")
 
 **Blockers/Concerns:** From "Next Phase Readiness" sections
 - Issues that affect future work

package/{gsd/get-shit-done → src/pilot}/templates/summary-complex.md

@@ -49,7 +49,7 @@ completed: YYYY-MM-DD
 [Key decisions with brief rationale]
 
 ## Deviations from Plan (Auto-fixed)
-[Detailed auto-fix records per GSD deviation rules]
+[Detailed auto-fix records per CCP deviation rules]
 
 ## Issues Encountered
 [Problems during planned work and resolutions]

package/{gsd/get-shit-done → src/pilot}/workflows/add-phase.md

@@ -11,15 +11,15 @@ Read all files referenced by the invoking prompt's execution_context before star
 <step name="parse_arguments">
 Parse the command arguments:
 - All arguments become the phase description
-- Example: `/gsd:add-phase Add authentication` → description = "Add authentication"
-- Example: `/gsd:add-phase Fix critical performance issues` → description = "Fix critical performance issues"
+- Example: `/ccp:add-phase Add authentication` → description = "Add authentication"
+- Example: `/ccp:add-phase Fix critical performance issues` → description = "Fix critical performance issues"
 
 If no arguments provided:
 
 ```
 ERROR: Phase description required
-Usage: /gsd:add-phase <description>
-Example: /gsd:add-phase Add authentication system
+Usage: /ccp:add-phase <description>
+Example: /ccp:add-phase Add authentication system
 ```
 
 Exit.
@@ -29,23 +29,23 @@ Exit.
 Load phase operation context:
 
 ```bash
-INIT=$(node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" init phase-op "0")
+INIT=$(node "$HOME/.claude/pilot/bin/ccp-tools.cjs" init phase-op "0")
 if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
 ```
 
 Check `roadmap_exists` from init JSON. If false:
 ```
 ERROR: No roadmap found (.planning/ROADMAP.md)
-Run /gsd:new-project to initialize.
+Run /ccp:new-project to initialize.
 ```
 Exit.
 </step>
 
 <step name="add_phase">
-**Delegate the phase addition to gsd-tools:**
+**Delegate the phase addition to ccp-tools:**
 
 ```bash
-RESULT=$(node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" phase add "${description}")
+RESULT=$(node "$HOME/.claude/pilot/bin/ccp-tools.cjs" phase add "${description}")
 ```
 
 The CLI handles:
@@ -87,14 +87,14 @@ Roadmap updated: .planning/ROADMAP.md
 
 **Phase {N}: {description}**
 
-`/gsd:plan-phase {N}`
+`/ccp:plan-phase {N}`
 
 <sub>`/clear` first → fresh context window</sub>
 
 ---
 
 **Also available:**
-- `/gsd:add-phase <description>` — add another phase
+- `/ccp:add-phase <description>` — add another phase
 - Review roadmap
 
 ---
@@ -104,7 +104,7 @@ Roadmap updated: .planning/ROADMAP.md
 </process>
 
 <success_criteria>
-- [ ] `gsd-tools phase add` executed successfully
+- [ ] `ccp-tools phase add` executed successfully
 - [ ] Phase directory created
 - [ ] Roadmap updated with new phase entry
 - [ ] STATE.md updated with roadmap evolution note