cc-codeconductor 0.5.0 → 1.0.0

package/presets/agy/workflows/cc-fix.md

@@ -2,7 +2,7 @@
 name: cc-fix
 description:
   Run the bug fix workflow — risk-based routing through task validation,
-  implementation, testing, and optional review.
+  testing, implementation, and optional review.
 ---
 
 # Bug Fix Workflow
@@ -19,7 +19,29 @@ Provide the following information in $ARGUMENTS:
 
 ---
 
-## Step 1 — Task Card validation (task-coach)
+## 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)
 
 Invoke `task-coach` with the bug description above.
 
@@ -34,11 +56,16 @@ If reproduction steps are missing, task-coach must 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.
 
@@ -47,16 +74,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 `architect` before implementation. architect must:
 
@@ -70,7 +97,20 @@ before continuing.**
 
 ---
 
-## Step 3a — Implementation, low-risk (implementer)
+## Step 4 — Regression tests (tester)
+
+Invoke `tester` for all risk levels.
+
+tester must:
+
+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 Coverage Summary: test added, case covered
+
+---
+
+## Step 5a — Implementation, low-risk (implementer)
 
 Invoke `implementer` with the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -79,12 +119,12 @@ implementer must:
 
 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)
+## Step 5b — Implementation, medium/high-risk (implementer)
 
 Invoke `implementer` with the approved Technical Plan and the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -94,20 +134,7 @@ Plan approval. After implementation, run the full test suite.
 
 ---
 
-## Step 4 — Regression tests (tester)
-
-Invoke `tester` for all risk levels.
-
-tester must:
-
-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 Coverage Summary: test added, case covered
-
----
-
-## Step 5 — Review (reviewer) — medium/high-risk only
+## Step 6 — Review (reviewer) — medium/high-risk only
 
 Invoke `reviewer` with the diff and Task Card.
 

package/presets/agy/workflows/cc-handoff.md

@@ -0,0 +1,42 @@
+---
+name: cc-handoff
+description:
+  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/agy/workflows/cc-iterative.md

@@ -0,0 +1,128 @@
+---
+name: cc-iterative
+description:
+  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 `repo-explorer` 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 `task-coach` using the Grilling protocol to stress-test all assumptions.
+
+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.
+
+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` with the validated Task Card.
+
+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 invoke implementer until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (tester)
+
+Invoke `tester` with the Task Card and Technical Plan.
+
+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)
+
+Invoke `implementer` with the approved Technical Plan, contracts, and 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)
+
+Invoke `docs` 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/agy/workflows/cc-openspec.md

@@ -17,6 +17,19 @@ Run `npx cc-codeconductor openspec validate`. If invalid, show errors and recomm
 
 ---
 
+## 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 — Scan
 
 Run `npx cc-codeconductor openspec scan`. Report new, modified, and closed items.

package/presets/agy/workflows/cc-pagespeed.md

@@ -11,6 +11,18 @@ Audit URL: $ARGUMENTS
 
 ---
 
+## 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.
+
+---
+
 ## Step 1 — Pre-flight (pagespeed-perf skill)
 
 Invoke `pagespeed-perf` skill.

package/presets/agy/workflows/cc-prototype.md

@@ -0,0 +1,39 @@
+---
+name: cc-prototype
+description:
+  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/agy/workflows/cc-refactor.md

@@ -34,6 +34,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)
 
 Always invoke `architect` first, regardless of risk level. A refactor without a

package/presets/agy/workflows/cc-review.md

@@ -18,6 +18,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 invoking `reviewer`, collect the diff for the specified target.

package/presets/agy/workflows/cc-scorecard.md

@@ -8,6 +8,18 @@ description:
 
 Scope: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `scorecard` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command scorecard "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command scorecard "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile scorecard --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command scorecard --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.
+
+---
+
 1. `npx cc-codeconductor scorecard create --task <id> --from-diff`
 2. Complete criteria per docs/agent-scorecard.md
 3. `scorecard regression` if needed

package/presets/agy/workflows/cc-tdd-cycle.md

@@ -18,6 +18,19 @@ Describe what behavior you want to implement. Include:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `tdd-cycle` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command tdd-cycle "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command tdd-cycle "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile tdd-cycle --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command tdd-cycle --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.
+
+---
+
 ## Before you begin — mandatory pre-check
 
 This command enforces strict TDD discipline. The three phases are sequential and
@@ -30,6 +43,17 @@ non-negotiable:
 Do not write implementation code during RED. Do not refactor during GREEN.
 Mixing phases invalidates the cycle.
 
+## Verifiable phase gates
+
+RED → GREEN and GREEN → REFACTOR are enforced by `tddCycleStateMachine` in
+`domain/loop`. Evidence must be captured with `captureTddSuiteEvidence` (verification
+runner) — do not hand-edit JSON under `.codeconductor/evidence/`.
+
+- RED→GREEN requires runner evidence that the suite **failed**.
+- GREEN→REFACTOR requires runner evidence that the suite **passed**.
+
+Do not advance phases until that evidence exists.
+
 ---
 
 ## Phase 1 — RED (Tester role)

package/presets/agy/workflows/cc-test-plan.md

@@ -21,6 +21,18 @@ If $ARGUMENTS is empty, describe the scope in your next message before invoking
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `test-plan` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command test-plan "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command test-plan "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile test-plan --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command test-plan --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 — Scope confirmation
 
 Before invoking `tester`, confirm the scope is well-defined.

package/presets/agy/workflows/cc-triage.md

@@ -0,0 +1,35 @@
+---
+name: cc-triage
+description:
+  Classify a request into type, risk, and the destination CodeConductor command.
+---
+
+# Triage Workflow
+
+Triage request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `triage` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command triage "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command triage "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile triage --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command triage --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 — Classify (task-coach)
+
+Invoke `task-coach`. Produce: title, type (`feature` | `fix` | `refactor` | `review` | `docs` | `test`), risk, named scope, and the destination command (`feature`, `fix`, `refactor`, `review`, `explore`, …).
+
+Ask one question per unresolved branch. If the human is unavailable, emit a Markdown questionnaire and stop at ConfirmationGate.
+
+**STOP here. Show the classification and wait for confirmation before running the destination workflow.**
+
+---
+
+## Completion
+
+Do not implement. Hand the human a destination slash command and a partial Task Card.

package/presets/claude/CLAUDE.md

@@ -384,6 +384,20 @@ contract tests. Does not write production code.
 - Cover three cases for every behavior: happy path, edge case, error case.
 - Test names must describe what is being tested and the expected outcome.
 
+**Anti-pattern checklist** — before declaring tests ready, verify none of
+these apply:
+
+- **Implementation-coupled** — the test asserts internal implementation
+  details (private state, call order, mock invocations) instead of observable
+  behavior. It breaks when the implementation is refactored even if the
+  behavior is unchanged.
+- **Tautological** — the test asserts something that cannot fail given the
+  test's own setup (e.g., asserting a value the test itself just hardcoded).
+  It always passes regardless of the code under test.
+- **Horizontal slicing** — the test spans multiple unrelated behaviors or
+  layers in one assertion block instead of a single vertical slice of one
+  behavior.
+
 **Test types:**
 
 | Type        | When to write                                            |
@@ -494,6 +508,56 @@ _(none)_ if no suggestions
 - **Verdict justification**: [one sentence]
 ```
 
+
+**Two-Axis Review Model (Standards + Spec)**
+
+The Reviewer role executes two independent, parallel sub-agents without reranking between them:
+
+1.
+
+_El modelo de dos ejes (Standards, Spec) es la estructura de ejecución de `/cc:review`; los review axes listados en la tabla anterior se aplican DENTRO de cada eje._ **Standards Axis** — Code smell detection against the Fowler baseline (Long Method, Large Class, Duplicated Code, Feature Envy, Shotgun Surgery, Primitive Obsession, Data Clumps, Switch Statements, Speculative Generality, Temporary Fields, Message Chains, Middle Man, Inappropriate Intimacy, Data Class, Comments-as-apology), with documented override allowed via repo standards documentation (e.g., CONTEXT.md or project norms).
+
+2. **Spec Axis** — Alignment with Task Card, acceptance criteria, and scope boundaries.
+
+Each axis produces findings independently. **No reranking** occurs between axes — each axis is evaluated in parallel and its findings remain independent. After parallel execution, a **combined verdict** integrates findings from both axes:
+
+- If either axis finds CRITICAL issues → verdict is `blocked`
+- Else if either axis finds WARNING → verdict is `approved with warnings`
+- Else → verdict is `approved`
+
+**Two-Axis Review Report format:**
+
+```markdown
+## Review Report
+
+**Task**: [objective from Task Card] **Verdict**: [approved | approved with warnings | blocked]
+
+---
+
+### Standards Axis
+
+Applies Fowler code smell baseline with documented overrides.
+
+- [ ] [S1] [file:line] — [code smell] | Override: [documented or N/A] | Required action: [what must change] (CRITICAL) or Recommended action: [what must change] (WARNING)
+
+_(none)_ if no findings
+
+### Spec Axis
+
+Validates Task Card, acceptance criteria, and scope alignment.
+
+- [ ] [Sp1] [criterion number] — [description] | Evidence: [quote] | Required action: [what must change] (CRITICAL) or Recommended action: [what must change] (WARNING)
+
+_(none)_ if no findings
+
+### Combined Summary
+
+- Standards findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- Spec findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- **Combined Verdict**: [approved | approved with warnings | blocked]
+- **Verdict justification**: [one sentence]
+```
+
 ---
 
 ### Complexity Auditor

package/presets/claude/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)
 
 Adopt the **Task Coach** role as defined in `CLAUDE.md`.