claude-code-pilot 3.0.0 → 3.1.0

package/src/commands/{aside.md → ccp/aside.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:aside
 description: Answer a quick side question without interrupting or losing context from the current task. Resume work automatically after answering.
 ---
 
@@ -17,12 +18,12 @@ Ask a question mid-task and get an immediate, focused answer — then continue r
 ## Usage
 
 ```
-/aside <your question>
-/aside what does this function actually return?
-/aside is this pattern thread-safe?
-/aside why are we using X instead of Y here?
-/aside what's the difference between foo() and bar()?
-/aside should we be worried about the N+1 query we just added?
+/ccp:aside <your question>
+/ccp:aside what does this function actually return?
+/ccp:aside is this pattern thread-safe?
+/ccp:aside why are we using X instead of Y here?
+/ccp:aside what's the difference between foo() and bar()?
+/ccp:aside should we be worried about the N+1 query we just added?
 ```
 
 ## Process
@@ -31,7 +32,7 @@ Ask a question mid-task and get an immediate, focused answer — then continue r
 
 Before answering anything, mentally note:
 - What is the active task? (what file, feature, or problem was being worked on)
-- What step was in progress at the moment `/aside` was invoked?
+- What step was in progress at the moment `/ccp:aside` was invoked?
 - What was about to happen next?
 
 Do NOT touch, edit, create, or delete any files during the aside.
@@ -63,7 +64,7 @@ After delivering the answer, immediately continue the active task from the exact
 
 ## Edge Cases
 
-**No question provided (`/aside` with nothing after it):**
+**No question provided (`/ccp:aside` with nothing after it):**
 Respond:
 ```
 ASIDE: no question provided
@@ -83,7 +84,7 @@ ASIDE: [answer]
 Wait for the user's decision before resuming.
 
 **Question is actually a task redirect (not a side question):**
-If the question implies changing what is being built (e.g., `/aside actually, let's use Redis instead`), clarify:
+If the question implies changing what is being built (e.g., `/ccp:aside actually, let's use Redis instead`), clarify:
 ```
 ASIDE: That sounds like a direction change, not just a side question.
 Do you want to:
@@ -95,7 +96,7 @@ Wait for the user's answer — do not make assumptions.
 **Question is about the currently open file or code:**
 Answer from the live context. If the file was read earlier in the session, reference it directly. If not, read it now (read-only) and answer with a file:line reference.
 
-**No active task (nothing in progress when `/aside` is invoked):**
+**No active task (nothing in progress when `/ccp:aside` is invoked):**
 Still use the standard wrapper so the response shape stays consistent:
 ```
 ASIDE: [restate the question briefly]
@@ -111,7 +112,7 @@ Give the essential answer concisely, then offer:
 That's the short version. Want a deeper explanation after we finish [current task]?
 ```
 
-**Multiple `/aside` questions in a row:**
+**Multiple `/ccp:aside` questions in a row:**
 Answer each one in sequence. After the last answer, resume the main task. Do not lose task state across a chain of asides.
 
 **Aside answer implies a code change is needed:**
@@ -130,7 +131,7 @@ Ask one clarifying question — the shortest question that gets the information
 ## Example Output
 
 ```
-User: /aside what does fetchWithRetry() actually do?
+User: /ccp:aside what does fetchWithRetry() actually do?
 
 ASIDE: what does fetchWithRetry() do?
 
@@ -142,7 +143,7 @@ network errors — 4xx errors are treated as final and not retried.
 ```
 
 ```
-User: /aside is the approach we're taking thread-safe?
+User: /ccp:aside is the approach we're taking thread-safe?
 
 ASIDE: is the current approach thread-safe?
 

package/src/commands/{build-fix.md → ccp/build-fix.md}

@@ -1,3 +1,8 @@
+---
+name: ccp:build-fix
+description: "Incrementally fix build and type errors with minimal, safe changes"
+---
+
 # Build and Fix
 
 Incrementally fix build and type errors with minimal, safe changes.

package/src/commands/{checkpoint.md → ccp/checkpoint.md}

@@ -1,16 +1,21 @@
+---
+name: ccp:checkpoint
+description: "Create or verify a checkpoint in your workflow"
+---
+
 # Checkpoint Command
 
 Create or verify a checkpoint in your workflow.
 
 ## Usage
 
-`/checkpoint [create|verify|list] [name]`
+`/ccp:checkpoint [create|verify|list] [name]`
 
 ## Create Checkpoint
 
 When creating a checkpoint:
 
-1. Run `/verify quick` to ensure current state is clean
+1. Run `/ccp:verify quick` to ensure current state is clean
 2. Create a git stash or commit with checkpoint name
 3. Log checkpoint to `.claude/checkpoints.log`:
 
@@ -54,15 +59,15 @@ Show all checkpoints with:
 Typical checkpoint flow:
 
 ```
-[Start] --> /checkpoint create "feature-start"
+[Start] --> /ccp:checkpoint create "feature-start"
    |
-[Implement] --> /checkpoint create "core-done"
+[Implement] --> /ccp:checkpoint create "core-done"
    |
-[Test] --> /checkpoint verify "core-done"
+[Test] --> /ccp:checkpoint verify "core-done"
    |
-[Refactor] --> /checkpoint create "refactor-done"
+[Refactor] --> /ccp:checkpoint create "refactor-done"
    |
-[PR] --> /checkpoint verify "feature-start"
+[PR] --> /ccp:checkpoint verify "feature-start"
 ```
 
 ## Arguments

package/src/commands/{code-review.md → ccp/code-review.md}

@@ -1,3 +1,8 @@
+---
+name: ccp:code-review
+description: "Comprehensive security and quality review of uncommitted changes"
+---
+
 # Code Review
 
 Comprehensive security and quality review of uncommitted changes:

package/src/commands/{context-budget.md → ccp/context-budget.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:context-budget
 description: Analyze context window usage across agents, skills, MCP servers, and rules to find optimization opportunities. Helps reduce token overhead and avoid performance warnings.
 ---
 
@@ -9,7 +10,7 @@ Analyze your Claude Code setup's context window consumption and produce actionab
 ## Usage
 
 ```
-/context-budget [--verbose]
+/ccp:context-budget [--verbose]
 ```
 
 - Default: summary with top recommendations

package/src/commands/{cpp-build.md → ccp/cpp-build.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:cpp-build
 description: Fix C++ build errors, CMake issues, and linker problems incrementally. Invokes the cpp-build-resolver agent for minimal, surgical fixes.
 ---
 
@@ -16,7 +17,7 @@ This command invokes the **cpp-build-resolver** agent to incrementally fix C++ b
 
 ## When to Use
 
-Use `/cpp-build` when:
+Use `/ccp:cpp-build` when:
 - `cmake --build build` fails with errors
 - Linker errors (undefined references, multiple definitions)
 - Template instantiation failures
@@ -40,7 +41,7 @@ cppcheck --enable=all src/
 ## Example Session
 
 ```text
-User: /cpp-build
+User: /ccp:cpp-build
 
 Agent:
 # C++ Build Resolution
@@ -163,9 +164,9 @@ The agent will stop and report if:
 
 ## Related Commands
 
-- `/cpp-test` - Run tests after build succeeds
-- `/cpp-review` - Review code quality
-- `/verify` - Full verification loop
+- `/ccp:cpp-test` - Run tests after build succeeds
+- `/ccp:cpp-review` - Review code quality
+- `/ccp:verify` - Full verification loop
 
 ## Related
 

package/src/commands/{cpp-review.md → ccp/cpp-review.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:cpp-review
 description: Comprehensive C++ code review for memory safety, modern C++ idioms, concurrency, and security. Invokes the cpp-reviewer agent.
 ---
 
@@ -17,7 +18,7 @@ This command invokes the **cpp-reviewer** agent for comprehensive C++-specific c
 
 ## When to Use
 
-Use `/cpp-review` when:
+Use `/ccp:cpp-review` when:
 - After writing or modifying C++ code
 - Before committing C++ changes
 - Reviewing pull requests with C++ code
@@ -64,7 +65,7 @@ cmake --build build -- -Wall -Wextra -Wpedantic
 ## Example Usage
 
 ```text
-User: /cpp-review
+User: /ccp:cpp-review
 
 Agent:
 # C++ Code Review Report
@@ -121,10 +122,10 @@ Recommendation: ❌ Block merge until CRITICAL issue is fixed
 
 ## Integration with Other Commands
 
-- Use `/cpp-test` first to ensure tests pass
-- Use `/cpp-build` if build errors occur
-- Use `/cpp-review` before committing
-- Use `/code-review` for non-C++ specific concerns
+- Use `/ccp:cpp-test` first to ensure tests pass
+- Use `/ccp:cpp-build` if build errors occur
+- Use `/ccp:cpp-review` before committing
+- Use `/ccp:code-review` for non-C++ specific concerns
 
 ## Related
 

package/src/commands/{cpp-test.md → ccp/cpp-test.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:cpp-test
 description: Enforce TDD workflow for C++. Write GoogleTest tests first, then implement. Verify coverage with gcov/lcov.
 ---
 
@@ -17,7 +18,7 @@ This command enforces test-driven development methodology for C++ code using Goo
 
 ## When to Use
 
-Use `/cpp-test` when:
+Use `/ccp:cpp-test` when:
 - Implementing new C++ functions or classes
 - Adding test coverage to existing code
 - Fixing bugs (write failing test first)
@@ -36,7 +37,7 @@ REPEAT  → Next test case
 ## Example Session
 
 ````
-User: /cpp-test I need a function to validate email addresses
+User: /ccp:cpp-test I need a function to validate email addresses
 
 Agent:
 # TDD Session: Email Validator
@@ -241,9 +242,9 @@ genhtml coverage.info --output-directory coverage_html
 
 ## Related Commands
 
-- `/cpp-build` - Fix build errors
-- `/cpp-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `/ccp:cpp-build` - Fix build errors
+- `/ccp:cpp-review` - Review code after implementation
+- `/ccp:verify` - Run full verification loop
 
 ## Related
 

package/src/commands/ccp/docs-update.md

@@ -0,0 +1,48 @@
+---
+name: ccp:docs-update
+description: Generate or update project documentation verified against the codebase
+argument-hint: "[--force] [--verify-only]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - Task
+  - AskUserQuestion
+---
+<objective>
+Generate and update up to 9 documentation files for the current project. Each doc type is written by a ccp-doc-writer subagent that explores the codebase directly — no hallucinated paths, phantom endpoints, or stale signatures.
+
+Flag handling rule:
+- The optional flags documented below are available behaviors, not implied active behaviors
+- A flag is active only when its literal token appears in `$ARGUMENTS`
+- If a documented flag is absent from `$ARGUMENTS`, treat it as inactive
+- `--force`: skip preservation prompts, regenerate all docs regardless of existing content or GSD markers
+- `--verify-only`: check existing docs for accuracy against codebase, no generation (full verification requires Phase 4 verifier)
+- If `--force` and `--verify-only` both appear in `$ARGUMENTS`, `--force` takes precedence
+</objective>
+
+<execution_context>
+@~/.claude/pilot/workflows/docs-update.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS
+
+**Available optional flags (documentation only — not automatically active):**
+- `--force` — Regenerate all docs. Overwrites hand-written and GSD docs alike. No preservation prompts.
+- `--verify-only` — Check existing docs for accuracy against the codebase. No files are written. Reports VERIFY marker count. Full codebase fact-checking requires the ccp-doc-verifier agent (Phase 4).
+
+**Active flags must be derived from `$ARGUMENTS`:**
+- `--force` is active only if the literal `--force` token is present in `$ARGUMENTS`
+- `--verify-only` is active only if the literal `--verify-only` token is present in `$ARGUMENTS`
+- If neither token appears, run the standard full-phase generation flow
+- Do not infer that a flag is active just because it is documented in this prompt
+</context>
+
+<process>
+Execute the docs-update workflow from @~/.claude/pilot/workflows/docs-update.md end-to-end.
+Preserve all workflow gates (preservation_check, flag handling, wave execution, monorepo dispatch, commit, reporting).
+</process>

package/src/commands/{docs.md → ccp/docs.md}

@@ -1,8 +1,9 @@
 ---
+name: ccp:docs
 description: Look up current documentation for a library or topic via Context7.
 ---
 
-# /docs
+# /ccp:docs
 
 ## Purpose
 
@@ -11,10 +12,10 @@ Look up up-to-date documentation for a library, framework, or API and return a s
 ## Usage
 
 ```
-/docs [library name] [question]
+/ccp:docs [library name] [question]
 ```
 
-Use quotes for multi-word arguments so they are parsed as a single token. Example: `/docs "Next.js" "How do I configure middleware?"`
+Use quotes for multi-word arguments so they are parsed as a single token. Example: `/ccp:docs "Next.js" "How do I configure middleware?"`
 
 If library or question is omitted, prompt the user for:
 1. The library or product name (e.g. Next.js, Prisma, Supabase).

package/src/commands/{e2e.md → ccp/e2e.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:e2e
 description: Generate and run end-to-end tests with Playwright. Creates test journeys, runs tests, captures screenshots/videos/traces, and uploads artifacts.
 ---
 
@@ -16,7 +17,7 @@ This command invokes the **e2e-runner** agent to generate, maintain, and execute
 
 ## When to Use
 
-Use `/e2e` when:
+Use `/ccp:e2e` when:
 - Testing critical user journeys (login, trading, payments)
 - Verifying multi-step flows work end-to-end
 - Testing UI interactions and navigation
@@ -37,7 +38,7 @@ The e2e-runner agent will:
 ## Example Usage
 
 ```
-User: /e2e Test the market search and view flow
+User: /ccp:e2e Test the market search and view flow
 
 Agent (e2e-runner):
 # E2E Test Generation: Market Search and View Flow
@@ -330,10 +331,10 @@ For PMX, prioritize these E2E tests:
 
 ## Integration with Other Commands
 
-- Use `/plan` to identify critical journeys to test
-- Use `/tdd` for unit tests (faster, more granular)
-- Use `/e2e` for integration and user journey tests
-- Use `/code-review` to verify test quality
+- Use `/ccp:plan` to identify critical journeys to test
+- Use `/ccp:tdd` for unit tests (faster, more granular)
+- Use `/ccp:e2e` for integration and user journey tests
+- Use `/ccp:code-review` to verify test quality
 
 ## Related Agents
 

package/src/commands/{eval.md → ccp/eval.md}

@@ -1,14 +1,19 @@
+---
+name: ccp:eval
+description: "Manage eval-driven development workflow"
+---
+
 # Eval Command
 
 Manage eval-driven development workflow.
 
 ## Usage
 
-`/eval [define|check|report|list] [feature-name]`
+`/ccp:eval [define|check|report|list] [feature-name]`
 
 ## Define Evals
 
-`/eval define feature-name`
+`/ccp:eval define feature-name`
 
 Create a new eval definition:
 
@@ -35,7 +40,7 @@ Created: $(date)
 
 ## Check Evals
 
-`/eval check feature-name`
+`/ccp:eval check feature-name`
 
 Run evals for a feature:
 
@@ -60,7 +65,7 @@ Status: IN PROGRESS / READY
 
 ## Report Evals
 
-`/eval report feature-name`
+`/ccp:eval report feature-name`
 
 Generate comprehensive eval report:
 
@@ -98,7 +103,7 @@ RECOMMENDATION
 
 ## List Evals
 
-`/eval list`
+`/ccp:eval list`
 
 Show all eval definitions:
 

package/src/commands/{evolve.md → ccp/evolve.md}

@@ -1,5 +1,5 @@
 ---
-name: evolve
+name: ccp:evolve
 description: Analyze instincts and suggest or generate evolved structures
 command: true
 ---
@@ -28,8 +28,8 @@ Analyzes instincts and clusters related ones into higher-level structures:
 ## Usage
 
 ```
-/evolve                    # Analyze all instincts and suggest evolutions
-/evolve --generate         # Also generate files under evolved/{skills,commands,agents}
+/ccp:evolve                    # Analyze all instincts and suggest evolutions
+/ccp:evolve --generate         # Also generate files under evolved/{skills,commands,agents}
 ```
 
 ## Evolution Rules

package/src/commands/{go-build.md → ccp/go-build.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:go-build
 description: Fix Go build errors, go vet warnings, and linter issues incrementally. Invokes the go-build-resolver agent for minimal, surgical fixes.
 ---
 
@@ -16,7 +17,7 @@ This command invokes the **go-build-resolver** agent to incrementally fix Go bui
 
 ## When to Use
 
-Use `/go-build` when:
+Use `/ccp:go-build` when:
 - `go build ./...` fails with errors
 - `go vet ./...` reports issues
 - `golangci-lint run` shows warnings
@@ -44,7 +45,7 @@ go mod tidy -v
 ## Example Session
 
 ```text
-User: /go-build
+User: /ccp:go-build
 
 Agent:
 # Go Build Resolution
@@ -173,9 +174,9 @@ The agent will stop and report if:
 
 ## Related Commands
 
-- `/go-test` - Run tests after build succeeds
-- `/go-review` - Review code quality
-- `/verify` - Full verification loop
+- `/ccp:go-test` - Run tests after build succeeds
+- `/ccp:go-review` - Review code quality
+- `/ccp:verify` - Full verification loop
 
 ## Related
 

package/src/commands/{go-review.md → ccp/go-review.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:go-review
 description: Comprehensive Go code review for idiomatic patterns, concurrency safety, error handling, and security. Invokes the go-reviewer agent.
 ---
 
@@ -17,7 +18,7 @@ This command invokes the **go-reviewer** agent for comprehensive Go-specific cod
 
 ## When to Use
 
-Use `/go-review` when:
+Use `/ccp:go-review` when:
 - After writing or modifying Go code
 - Before committing Go changes
 - Reviewing pull requests with Go code
@@ -69,7 +70,7 @@ govulncheck ./...
 ## Example Usage
 
 ```text
-User: /go-review
+User: /ccp:go-review
 
 Agent:
 # Go Code Review Report
@@ -137,10 +138,10 @@ Recommendation: ❌ Block merge until CRITICAL issue is fixed
 
 ## Integration with Other Commands
 
-- Use `/go-test` first to ensure tests pass
-- Use `/go-build` if build errors occur
-- Use `/go-review` before committing
-- Use `/code-review` for non-Go specific concerns
+- Use `/ccp:go-test` first to ensure tests pass
+- Use `/ccp:go-build` if build errors occur
+- Use `/ccp:go-review` before committing
+- Use `/ccp:code-review` for non-Go specific concerns
 
 ## Related
 

package/src/commands/{go-test.md → ccp/go-test.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:go-test
 description: Enforce TDD workflow for Go. Write table-driven tests first, then implement. Verify 80%+ coverage with go test -cover.
 ---
 
@@ -17,7 +18,7 @@ This command enforces test-driven development methodology for Go code using idio
 
 ## When to Use
 
-Use `/go-test` when:
+Use `/ccp:go-test` when:
 - Implementing new Go functions
 - Adding test coverage to existing code
 - Fixing bugs (write failing test first)
@@ -36,7 +37,7 @@ REPEAT  → Next test case
 ## Example Session
 
 ````
-User: /go-test I need a function to validate email addresses
+User: /ccp:go-test I need a function to validate email addresses
 
 Agent:
 # TDD Session: Email Validator
@@ -258,9 +259,9 @@ go test -race -cover ./...
 
 ## Related Commands
 
-- `/go-build` - Fix build errors
-- `/go-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `/ccp:go-build` - Fix build errors
+- `/ccp:go-review` - Review code after implementation
+- `/ccp:verify` - Run full verification loop
 
 ## Related
 

package/src/commands/{gradle-build.md → ccp/gradle-build.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:gradle-build
 description: Fix Gradle build errors for Android and KMP projects
 ---
 

package/src/commands/{harness-audit.md → ccp/harness-audit.md}

@@ -1,10 +1,15 @@
+---
+name: ccp:harness-audit
+description: "Run deterministic repository harness audit and return prioritized scorecard"
+---
+
 # Harness Audit Command
 
 Run a deterministic repository harness audit and return a prioritized scorecard.
 
 ## Usage
 
-`/harness-audit [scope] [--format text|json]`
+`/ccp:harness-audit [scope] [--format text|json]`
 
 - `scope` (optional): `repo` (default), `hooks`, `skills`, `commands`, `agents`
 - `--format`: output style (`text` default, `json` for automation)

package/src/commands/{kotlin-build.md → ccp/kotlin-build.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:kotlin-build
 description: Fix Kotlin/Gradle build errors, compiler warnings, and dependency issues incrementally. Invokes the kotlin-build-resolver agent for minimal, surgical fixes.
 ---
 
@@ -16,7 +17,7 @@ This command invokes the **kotlin-build-resolver** agent to incrementally fix Ko
 
 ## When to Use
 
-Use `/kotlin-build` when:
+Use `/ccp:kotlin-build` when:
 - `./gradlew build` fails with errors
 - Kotlin compiler reports errors
 - `./gradlew detekt` reports violations
@@ -43,7 +44,7 @@ Use `/kotlin-build` when:
 ## Example Session
 
 ````text
-User: /kotlin-build
+User: /ccp:kotlin-build
 
 Agent:
 # Kotlin Build Resolution
@@ -164,9 +165,9 @@ The agent will stop and report if:
 
 ## Related Commands
 
-- `/kotlin-test` - Run tests after build succeeds
-- `/kotlin-review` - Review code quality
-- `/verify` - Full verification loop
+- `/ccp:kotlin-test` - Run tests after build succeeds
+- `/ccp:kotlin-review` - Review code quality
+- `/ccp:verify` - Full verification loop
 
 ## Related
 

package/src/commands/{kotlin-review.md → ccp/kotlin-review.md}

@@ -1,4 +1,5 @@
 ---
+name: ccp:kotlin-review
 description: Comprehensive Kotlin code review for idiomatic patterns, null safety, coroutine safety, and security. Invokes the kotlin-reviewer agent.
 ---
 
@@ -17,7 +18,7 @@ This command invokes the **kotlin-reviewer** agent for comprehensive Kotlin-spec
 
 ## When to Use
 
-Use `/kotlin-review` when:
+Use `/ccp:kotlin-review` when:
 - After writing or modifying Kotlin code
 - Before committing Kotlin changes
 - Reviewing pull requests with Kotlin code
@@ -68,7 +69,7 @@ Use `/kotlin-review` when:
 ## Example Usage
 
 ````text
-User: /kotlin-review
+User: /ccp:kotlin-review
 
 Agent:
 # Kotlin Code Review Report
@@ -129,10 +130,10 @@ Recommendation: ❌ Block merge until CRITICAL issue is fixed
 
 ## Integration with Other Commands
 
-- Use `/kotlin-test` first to ensure tests pass
-- Use `/kotlin-build` if build errors occur
-- Use `/kotlin-review` before committing
-- Use `/code-review` for non-Kotlin-specific concerns
+- Use `/ccp:kotlin-test` first to ensure tests pass
+- Use `/ccp:kotlin-build` if build errors occur
+- Use `/ccp:kotlin-review` before committing
+- Use `/ccp:code-review` for non-Kotlin-specific concerns
 
 ## Related