cc-codeconductor 0.5.0 → 1.0.0

package/presets/cursor/agents/impact-analyst.md

@@ -0,0 +1,43 @@
+---
+name: impact-analyst
+description: Produces ImpactReport before medium/high-risk changes — endpoints, contracts, tests, flows affected.
+---
+
+# Impact Analyst
+
+You are the **Impact Analyst** for CodeConductor. Before implementation of
+medium or high-risk tasks, you analyze blast radius using the product graph.
+
+## Input
+
+- Task Card with `targetFiles` or capability ID
+- Product graph context from `cc impact` or CCEP `knowledge`
+
+## Output
+
+Structured `ImpactReport`:
+
+```json
+{
+  "target": "string",
+  "brokenEndpoints": ["string"],
+  "brokenContracts": ["string"],
+  "affectedTests": ["string"],
+  "affectedFlows": ["string"],
+  "affectedComponents": ["string"],
+  "summary": "If you implement this, you may affect: ..."
+}
+```
+
+## Process
+
+1. Map target files to product graph components
+2. Traverse `depends_on`, `affects`, `implements` relations
+3. List contracts, tests, and flows at risk
+4. Summarize in one actionable sentence
+
+## Constraints
+
+- Read-only analysis — no code changes
+- Cite graph node IDs in summary when available
+- Block routing to implementer if critical contracts lack migration plan

package/presets/cursor/agents/orchestrator.md

@@ -95,22 +95,22 @@ regression.
 
 | Task type          | Risk        | Route                                                              |
 | ------------------ | ----------- | ------------------------------------------------------------------ |
-| New feature        | high        | `architect` → `implementer` → `tester` → `security-reviewer` → `reviewer` |
-| New feature        | low-medium  | `architect` → `implementer` → `tester` → `reviewer`                |
+| New feature        | high        | `architect` → `tester` → `implementer` → `security-reviewer` → `reviewer` |
+| New feature        | low-medium  | `architect` → `tester` → `implementer` → `reviewer`                |
 | Performance Opt    | medium      | `task-coach` → `implementer` → `reviewer`                           |
-| Bug fix            | low         | `implementer` → `tester`                                           |
-| Bug fix            | medium–high | `task-coach` → `architect` → `implementer` → `tester` → `reviewer` |
+| Bug fix            | low         | `tester` → `implementer`                                           |
+| Bug fix            | medium–high | `task-coach` → `architect` → `tester` → `implementer` → `reviewer` |
 | Refactor           | low         | `architect` → `implementer`                                        |
 | Refactor           | medium–high | `architect` → `implementer` → `reviewer`                           |
 | API change         | any         | `architect` → `implementer` → `reviewer`                           |
-| Database migration | any         | `architect` → `implementer` → `tester` → `reviewer`                |
+| Database migration | any         | `architect` → `tester` → `implementer` → `reviewer`                |
 | Test coverage      | any         | `tester`                                                           |
 | Documentation      | any         | `docs`                                                             |
 | Codebase question  | any         | `repo-explorer`                                                    |
 | Code review        | any         | `reviewer`                                                         |
 | Task unclear       | any         | `task-coach`                                                       |
 | Multi-step goal    | any         | `goal-planner` → [dependency-ordered agents]                       |
-| DDD→SDD→TDD        | any         | `contract-builder` → `architect` → `implementer` → `tester`        |
+| DDD→SDD→TDD        | any         | `contract-builder` → `architect` → `tester` → `implementer`        |
 
 ---
 

package/presets/cursor/commands/cc/api-contract.md

@@ -8,6 +8,18 @@ description: >-
 
 API contract request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `api-contract` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command api-contract "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command api-contract "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile api-contract --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command api-contract --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 — Task Card validation (Task Coach role)
 
 Invoke the `task-coach` subagent via the Task tool.

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

@@ -0,0 +1,55 @@
+---
+description: >-
+  [cc: alias] Recommend one CodeConductor slash command from a natural-language
+  problem. Does not start that workflow.
+---
+
+# Ask — recommend a slash command
+
+Problem: $ARGUMENTS
+
+This is a **router**, not a delivery workflow. Recommend exactly one command.
+Do **not** run the recommended `/cc:` command unless the human confirms.
+
+---
+
+## Step 1 — Recommend (deterministic)
+
+Run (local repo: `bun run dev`; published package: `npx cc-codeconductor`):
+
+```bash
+bun run dev ask "$ARGUMENTS" --output json
+```
+
+or:
+
+```bash
+npx cc-codeconductor ask "$ARGUMENTS" --output json
+```
+
+The catalog is only:
+
+| Slash | When |
+| ----- | ---- |
+| `/cc:feature` | new behavior |
+| `/cc:fix` | bug / regression |
+| `/cc:refactor` | structure, no behavior change |
+| `/cc:review` | inspect a diff/PR |
+| `/cc:tdd-cycle` | red → green → refactor |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+openspec → tdd-cycle → review → refactor → fix → feature (default).
+
+---
+
+## Step 2 — Show and stop
+
+Print:
+
+- **Recommended:** the slash command
+- **Why:** one or two sentences from the CLI `reason` (or your matching)
+
+**STOP.** Wait for the human. Do not invoke the recommended workflow.
+
+For a full preset inventory (skills, commands on disk), use `/cc:help` / `cc-help`.

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

@@ -0,0 +1,32 @@
+---
+description: >-
+  [cc: alias] Re-explain the last deliverable in Task Card vocabulary when it did not land.
+---
+
+# Clarify Workflow
+
+Clarify request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `clarify` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command clarify "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command clarify "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile clarify --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command clarify --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 — Re-explain (task-coach)
+
+Invoke `task-coach` / `orchestrator`. Restate the last Task Card, plan, or review in the project's vocabulary. Do not add new scope. If questions remain, one question per branch.
+
+**STOP if ConfirmationGate reports questions.**
+
+---
+
+## Completion
+
+A plain-language restatement plus any remaining questions. Then resume the previous workflow.

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

@@ -0,0 +1,87 @@
+---
+description: Council-driven workflow with CCEP-1 bootstrap
+---
+
+# Council-Driven Workflow
+
+Task request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `council` (fixed for this workflow — do not infer from user text)
+command: council
+
+1. Run: `npx cc-codeconductor ccep parse --command council "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command council "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile council --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --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 — 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 impact radius before deliberation. Do not write code in this step.
+
+---
+
+## Step 2 — Deliberation & Specification (SDD)
+
+Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
+
+The council must:
+1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
+2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
+3. Draft a Task Card & Technical Plan (The Specification).
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
+CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
+answers. Show the agreed Task Card & Technical Plan and wait for confirmation
+before continuing.
+
+---
+
+## Step 3 — Test Definition (TDD)
+
+Invoke `tester` with the approved Task Card & Technical Plan.
+
+tester must:
+1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
+2. Confirm the tests fail as expected (Red state).
+
+**Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
+
+---
+
+## Step 4 — Surgical Implementation
+
+Invoke `implementer` with the failing tests and the Technical Plan.
+
+implementer must:
+1. Write the minimal code required to pass the tests.
+2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
+3. NOT refactor adjacent code, change existing styles, or build speculative features.
+4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state).
+
+---
+
+## Step 5 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff to perform the final review phase.
+
+The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
+
+If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
+- The Review Report status is **BLOCKED**.
+- Return to Step 4 with the feedback.
+
+If APPROVED (no CRITICAL findings):
+- Deliver the final Council Verdict and the diff summary.
+
+---
+
+## Completion
+
+Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.

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: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.