cc-codeconductor 0.5.0 → 1.1.0

package/presets/cursor/commands/cc/db-migration.md

@@ -8,6 +8,19 @@ description: >-
 
 Migration request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `db-migration` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command db-migration "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command db-migration "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile db-migration --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
 ## Step 1 — Task Card validation (Task Coach role)
 
 Invoke the `task-coach` subagent via the Task tool.
@@ -31,22 +44,22 @@ rollback/forward-fix notes, and test approach.
 
 ---
 
-## Step 3 — Implementation (Implementer role)
+## Step 3 — Migration Tests (Tester role)
 
-Invoke the `implementer` subagent via the Task tool.
+Invoke the `tester` subagent via the Task tool.
 
-Keep model and migration changes together, avoid unrelated refactors, and
-preserve the deployment order specified by architect.
+Cover migration-sensitive behavior where the stack supports it, including
+existing-data edge cases and rollback/forward-fix notes when automated rollback
+tests are not practical.
 
 ---
 
-## Step 4 — Migration Tests (Tester role)
+## Step 4 — Implementation (Implementer role)
 
-Invoke the `tester` subagent via the Task tool.
+Invoke the `implementer` subagent via the Task tool.
 
-Cover migration-sensitive behavior where the stack supports it, including
-existing-data edge cases and rollback/forward-fix notes when automated rollback
-tests are not practical.
+Keep model and migration changes together, avoid unrelated refactors, and
+preserve the deployment order specified by architect.
 
 ---
 

package/presets/cursor/commands/cc/explore.md

@@ -0,0 +1,36 @@
+---
+description: >-
+  [cc: alias] Map the repository and recommend the next CodeConductor slash command. Read-only.
+---
+
+# Explore Workflow
+
+Explore request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `explore` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command explore "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command explore "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile explore --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Map (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `repo-explorer`. Produce a Repo Map. Do not write code.
+
+---
+
+## Step 2 — Suggest next command (orchestrator)
+
+Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:backlog`, `/cc:openspec`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+
+---
+
+## Completion
+
+Report the Repo Map and the recommended next `/cc:` command.

package/presets/cursor/commands/cc/feature.md

@@ -10,7 +10,29 @@ Feature request: $ARGUMENTS
 
 ---
 
-## Step 1 — Task Card validation (Task Coach role)
+## Step 0 — CCEP Bootstrap
+
+Command: `feature` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile feature --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
 
 Invoke the `task-coach` subagent via the Task tool.
 
@@ -25,7 +47,7 @@ continuing.**
 
 ---
 
-## Step 2 — Technical Plan (Architect role)
+## Step 3 — Technical Plan (Architect role)
 
 Invoke the `architect` subagent via the Task tool.
 
@@ -43,7 +65,20 @@ not proceed to implementation until the plan is approved.**
 
 ---
 
-## Step 3 — Implementation (Implementer role)
+## Step 4 — Test coverage (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+Use the Implementation Summary and the Task Card.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Run the full test suite and confirm it passes.
+4. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (Implementer role)
 
 Invoke the `implementer` subagent via the Task tool.
 
@@ -52,26 +87,13 @@ Implementer creates a Git Worktree before touching any file; all edits happen in
 
 1. Read the Technical Plan before touching any file.
 2. Apply the minimal diff — only what the plan specifies.
-3. Run the project test suite after implementation.
+3. Run the project test suite and make the previously written failing tests pass.
 4. Produce an Implementation Summary: what changed, which files, how to verify
    locally.
 
 ---
 
-## Step 4 — Test coverage (Tester role)
-
-Invoke the `tester` subagent via the Task tool.
-
-Use the Implementation Summary and the Task Card.
-
-1. Write or extend tests to cover the new behavior.
-2. Ensure all acceptance criteria from the Task Card have at least one test.
-3. Run the full test suite and confirm it passes.
-4. Produce a Test Report: test files added or modified, cases covered.
-
----
-
-## Step 5 — Code review (Reviewer role)
+## Step 6 — Code review (Reviewer role)
 
 Invoke the `reviewer` subagent via the Task tool.
 
@@ -85,7 +107,7 @@ they are resolved and the diff is re-reviewed.
 
 ---
 
-## Step 6 — Documentation (Docs role)
+## Step 7 — Documentation (Docs role)
 
 Invoke the `docs` subagent via the Task tool.
 

package/presets/cursor/commands/cc/fix.md

@@ -18,7 +18,29 @@ Provide the following information in $ARGUMENTS:
 
 ---
 
-## Step 1 — Task Card validation (Task Coach role)
+## Step 0 — CCEP Bootstrap
+
+Command: `fix` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command fix "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command fix "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile fix --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
 
 Invoke the `task-coach` subagent via the Task tool.
 
@@ -32,11 +54,16 @@ Produce a Task Card that includes:
 If reproduction steps are missing, ask for them before classifying risk. A bug
 without a reproduction path cannot be classified reliably.
 
+Capture evidence before tests: reproduction, logs or stack traces, and one
+falsifiable hypothesis of the root cause. Do not patch without that evidence.
+Redact secrets, tokens, and credential dumps from logs before they enter the
+Task Card. Summarize stack traces; do not paste env files.
+
 **STOP here. Show the Task Card and wait for human confirmation.**
 
 ---
 
-## Step 2 — Route by risk
+## Step 3 — Route by risk
 
 Read the risk field from the Task Card and follow the corresponding route.
 
@@ -45,16 +72,16 @@ Read the risk field from the Task Card and follow the corresponding route.
 Applies when: the bug is isolated to a single component, existing tests cover
 the affected code, and no public API or shared state is involved.
 
-Route: Task Coach → Implementer → Tester
+Route: Task Coach → Tester → Implementer
 
-Proceed directly to Step 3a.
+Proceed directly to Step 3 (tests), then Step 4a.
 
 ### Medium or high-risk route
 
 Applies when: the bug touches shared state, a public API, auth or payment paths,
 database writes, or the root cause is not yet understood.
 
-Route: Task Coach → Architect → Implementer → Tester → Reviewer
+Route: Task Coach → Architect → Tester → Implementer → Reviewer
 
 Invoke the `architect` subagent before implementation. Architect must:
 
@@ -68,19 +95,30 @@ before continuing.**
 
 ---
 
-## Step 3a — Implementation, low-risk (Implementer role)
+## Step 4 — Regression tests (Tester role)
+
+Invoke the `tester` subagent via the Task tool. Apply for all risk levels.
+
+1. Write a regression test that reproduces the original bug and confirm it fails
+   before any fix (RED).
+2. Verify that existing tests still pass.
+3. Produce a Test Report: test added, case covered.
+
+---
+
+## Step 5a — Implementation, low-risk (Implementer role)
 
 Invoke the `implementer` subagent via the Task tool. Use the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
 1. Locate the defect using the reproduction steps.
 2. Apply the minimal fix — no unrelated changes.
-3. Run the test suite.
+3. Run the suite and make the RED regression test pass.
 4. Produce an Implementation Summary: root cause, fix applied, files changed.
 
 ---
 
-## Step 3b — Implementation, medium/high-risk (Implementer role)
+## Step 5b — Implementation, medium/high-risk (Implementer role)
 
 Invoke the `implementer` subagent via the Task tool. Use the approved
 Technical Plan and the Task Card.
@@ -91,18 +129,7 @@ After implementation, run the full test suite.
 
 ---
 
-## Step 4 — Regression tests (Tester role)
-
-Invoke the `tester` subagent via the Task tool. Apply for all risk levels.
-
-1. Write a regression test that reproduces the original bug (fails before the
-   fix, passes after).
-2. Verify that existing tests still pass.
-3. Produce a Test Report: test added, case covered.
-
----
-
-## Step 5 — Review (Reviewer role) — medium/high-risk only
+## Step 6 — Review (Reviewer role) — medium/high-risk only
 
 Invoke the `reviewer` subagent via the Task tool. Use the diff and Task
 Card.

package/presets/cursor/commands/cc/handoff.md

@@ -0,0 +1,41 @@
+---
+description: >-
+  [cc: alias] Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets).
+---
+
+# Handoff Workflow
+
+Handoff request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `handoff` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command handoff "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command handoff "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile handoff --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command handoff --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Compact (docs)
+
+Invoke `docs`. Write **only** `.codeconductor/sessions/handoff.md` (gitignored).
+Do not write `.codeconductor/handoff.md` or any tracked path.
+
+Before writing, redact secrets, tokens, API keys, passwords, connection strings,
+`.env` contents, and log/stack-trace lines that embed those values. Summarize
+errors instead of pasting dumps. If unresolved credential material remains, stop
+and wait for a human (CCEP `stopOnHighRisk`).
+
+Include: goal, Task Card status (no secret fields), files touched, test
+pass/fail (not log dumps), open questions, and the next `/cc:` command.
+
+Do not edit source or tests.
+
+---
+
+## Completion
+
+Report the handoff path. Another session should be able to continue from that file alone.

package/presets/cursor/commands/cc/iterative.md

@@ -0,0 +1,133 @@
+---
+description: >-
+  [cc: alias] Run the advanced iterative workflow — Wayfinding AST discovery,
+  Relentless Grilling, contract and spec design, TDD, council review, and docs.
+---
+
+# Advanced Iterative Workflow
+
+Iterative request: $ARGUMENTS
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `iterative` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command iterative "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command iterative "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile iterative --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command iterative --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when two modules or one concept need a
+scoped subgraph). Then invoke the `repo-explorer` subagent via the Task tool
+with that graph output.
+
+repo-explorer maps directory trees, conventions, god nodes, and affected
+modules. Do not write code in this step. Write a short phase handoff (scope,
+files, open questions) before the next phase — do not chain agents on unspoken
+context.
+
+---
+
+## Step 2 — Relentless Grilling & Task Card (task-coach)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+Produce a complete Task Card. The Task Card is ready when it contains: title,
+type, risk classification, scope, context, acceptance criteria, and
+constraints, and every assumption behind it has survived one grilling
+question (Grilling protocol).
+
+If any field is missing or ambiguous, ask one clarifying question at a time and
+wait for the answer. Do not proceed with an incomplete Task Card.
+
+**STOP here.** Unresolved grilling questions or missing fields populate
+`questionsForUser` in the CCEP-1 `planner-output`; the `ConfirmationGate`
+(`ccep evaluate`) reads that field and halts the workflow until a human
+answers. Show the completed Task Card and wait for that confirmation before
+continuing.
+
+---
+
+## Step 3 — Contract & Technical Plan (contract-builder & architect)
+
+Invoke `contract-builder` then `architect` via the Task tool.
+
+1. Define API contracts, JSON Schemas, or TypeScript interfaces.
+2. Formulate the Technical Plan (chosen approach, affected files, trade-offs).
+3. Apply YAGNI, Simplicity First, and Stdlib-First.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval. Do
+not proceed to tests until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+Use the approved Technical Plan, contracts, and the failing tests.
+Implementer creates a Git Worktree before touching any file; all edits happen
+inside it.
+
+1. Read the Technical Plan before touching any file.
+2. Apply the minimal diff — only what the plan specifies.
+3. Run the project test suite and make the previously written failing tests pass.
+4. If tests fail, run up to 3 repair cycles (`implementer` → `tester`).
+5. Produce an Implementation Summary: what changed, which files, how to verify
+   locally.
+
+---
+
+## Step 6 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff (`council-review` phase).
+
+The council evaluates Architecture, Security, Product, Delivery, DataOps, and
+Devil. `security-reviewer` may set `securityVeto: true`; that REJECTED verdict
+overrides majority consensus.
+
+If ANY agent votes CRITICAL:
+- The Review Report status is **BLOCKED**.
+- Return to Step 5 with the feedback.
+
+If APPROVED (no CRITICAL findings), continue.
+
+---
+
+## Step 7 — Documentation (Docs role)
+
+Invoke the `docs` subagent via the Task tool when a public API, public module,
+or user-visible behavior changed.
+
+Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG
+(always when implementation changed), ADR (if an architectural decision was
+made).
+
+If `graphify-out/` is in use, run `graphify update .` (AST-only).
+
+---
+
+## Completion
+
+The iterative workflow is complete only when: all tests pass, the council
+approves the spec and the diff, no CRITICAL findings remain, and documentation
+and the knowledge graph reflect the implemented behavior.

package/presets/cursor/commands/cc/openspec.md

@@ -12,7 +12,22 @@ Orchestrate FIFO delivery from `BACKLOG.md`. CodeConductor owns planning; agents
 
 ---
 
-## Step 0 — Validate (mandatory gate)
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `openspec` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command openspec "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command openspec "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile openspec --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command openspec --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Validate (mandatory gate)
 
 Run:
 
@@ -28,7 +43,7 @@ If validation fails:
 
 ---
 
-## Step 1 — Scan
+## Step 2 — Scan
 
 Run:
 
@@ -40,7 +55,7 @@ Report: new items, modified items, closed/archived items, and whether the file c
 
 ---
 
-## Step 2 — Select item
+## Step 3 — Select item
 
 If `$ARGUMENTS` contains a `BC-xxx` ID, use that item. Otherwise run:
 
@@ -54,7 +69,7 @@ Pick the next `READY` item with satisfied dependencies (FIFO by priority). Skip
 
 ---
 
-## Step 3 — Plan
+## Step 4 — Plan
 
 Run:
 
@@ -71,7 +86,22 @@ Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
 ---
 
-## Step 4 — Model matrix and execute loop
+## Drive card status (CLI)
+
+Do not edit `.codeconductor/openspec-state.json` by hand.
+
+```bash
+npx cc-codeconductor openspec start <cardId>
+npx cc-codeconductor openspec done <cardId>
+npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec archive <itemId>
+```
+
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+
+---
+
+## Step 5 — Model matrix and execute loop
 
 Before executing phases, show resolved models:
 
@@ -100,13 +130,13 @@ Use the model configured in the installed preset for each agent role.
 After each phase:
 
 - Mark progress in deliverable summary.
-- Set TaskCard status to `done` in `.codeconductor/openspec-state.json` when phase completes.
+- Run `npx cc-codeconductor openspec done <cardId>` when the phase completes. Do not edit openspec-state.json by hand.
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 
 ---
 
-## Step 5 — Review gate
+## Step 6 — Review gate
 
 Run regression when BACKLOG Global `Review required: yes`:
 
@@ -127,7 +157,7 @@ If **approved**: proceed to Step 6.
 
 ---
 
-## Step 6 — Scorecard and update backlog
+## Step 7 — Scorecard and update backlog
 
 1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
 2. Complete criteria; `scorecard record` with verdict and optional cost/tokens

package/presets/cursor/commands/cc/pagespeed.md

@@ -4,6 +4,18 @@ Audit web performance using the PageSpeed Insights API. Applies the 80/20
 principle: identify the 20% of changes that produce 80% of the performance gain.
 Produces a prioritized report in the current working directory.
 
+## Step 0 — CCEP Bootstrap
+
+Command: `pagespeed` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command pagespeed "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command pagespeed "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile pagespeed --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command pagespeed --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Usage
 
 ```

package/presets/cursor/commands/cc/prototype.md

@@ -0,0 +1,38 @@
+---
+description: >-
+  [cc: alias] Disposable spike in an isolated worktree. Not a merge candidate.
+---
+
+# Prototype Workflow
+
+Prototype request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `prototype` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command prototype "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command prototype "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile prototype --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command prototype --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Bounds (architect)
+
+Invoke `architect`. Define what the spike may touch, time-box, and what must not leak into main. Do not treat this as a production Technical Plan.
+
+**STOP here. Wait for approval of the spike bounds.**
+
+---
+
+## Step 2 — Spike (implementer)
+
+Invoke `implementer` in a Git worktree that is not a merge candidate. Label the Implementation Summary as disposable. Do not open a PR against protected branches.
+
+---
+
+## Completion
+
+Report bounds, worktree path, and what was learned. Recommend `/cc:feature` or `/cc:fix` if the spike should become real work.

package/presets/cursor/commands/cc/refactor.md

@@ -33,6 +33,18 @@ If coverage is insufficient:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `refactor` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command refactor "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command refactor "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile refactor --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command refactor --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Architectural justification (Architect role)
 
 Invoke the `architect` subagent via the Task tool. Always invoke this step

package/presets/cursor/commands/cc/review.md

@@ -17,6 +17,18 @@ Specify what to review. Accepted formats:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `review` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command review "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command review "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile review --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command review --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Diff collection
 
 Before adopting the Reviewer role, collect the diff for the specified target.