cc-codeconductor 0.5.0 → 1.0.0

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,7 @@ Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
 ---
 
-## Step 4 — Model matrix and execute loop
+## Step 5 — Model matrix and execute loop
 
 Before executing phases, show resolved models:
 
@@ -106,7 +121,7 @@ Implementer: create a Git worktree before editing (`git worktree add ../<branch>
 
 ---
 
-## Step 5 — Review gate
+## Step 6 — Review gate
 
 Run regression when BACKLOG Global `Review required: yes`:
 
@@ -127,7 +142,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.

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

@@ -10,6 +10,18 @@ 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.
+
+---
+
 ## Step 1 — Identify task
 
 Use `$ARGUMENTS` as task id (e.g. `BC-001`) or read active item from `npx cc-codeconductor openspec status`.

package/presets/cursor/commands/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/cursor/commands/cc/test-plan.md

@@ -20,6 +20,18 @@ proceeding.
 
 ---
 
+## 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 generating the test plan, confirm the scope is well-defined.

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

@@ -0,0 +1,34 @@
+---
+description: >-
+  [cc: alias] 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/cursor/gates/pre-commit/GATE.md

@@ -0,0 +1,136 @@
+# Pre-commit Gate: Typecheck and Test
+
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck` y `bun run test` antes de permitir commits en el repositorio. Si cualquiera de estos comandos falla, el commit es bloqueado.
+
+## Cuándo usar
+
+**Para agentes**: Integra este gate en flujos de desarrollo local cuando quieras garantizar que los cambios typecheck correctamente y pasan los tests antes de ser cometidos.
+
+**Para equipos**: Utiliza este gate como barrera de calidad local (sin dependencias externas) para prevenir commits con errores de tipado o tests fallidos.
+
+## Instalación
+
+### Paso 1: Descarga el script
+
+El script está embebido abajo (sección "Script Installer").
+
+### Paso 2: Ejecuta en la raíz de tu proyecto
+
+Desde la raíz del repositorio (o cualquier subdirectorio), extrae el bloque ```bash de este archivo y ejecuta:
+
+    bash << 'SCRIPT_EOF'
+    #!/bin/bash
+    set -e
+    # [contenido del bloque bash de abajo]
+    SCRIPT_EOF
+
+O, más simplemente, guarda el script en un archivo temporal y ejecútalo:
+
+    curl -s https://raw.githubusercontent.com/.../ | bash
+
+### Paso 3: Verifica
+
+Después de la instalación, debería verse:
+
+    Pre-commit hook installed successfully.
+
+## Script Installer
+
+```bash
+#!/bin/bash
+set -e
+
+# Resolver git directory dinámicamente (worktree-safe)
+GIT_DIR=$(git rev-parse --git-dir)
+HOOK_PATH="$GIT_DIR/hooks/pre-commit"
+
+# Detectar Husky o lint-staged en package.json
+if grep -q '"husky"' package.json 2>/dev/null || grep -q '"lint-staged"' package.json 2>/dev/null; then
+  echo "Warning: Husky or lint-staged detected in package.json. Installation skipped."
+  exit 0
+fi
+
+# Verificar si un pre-commit hook ya existe
+if [ -f "$HOOK_PATH" ]; then
+  echo "Warning: Pre-commit hook already exists at $HOOK_PATH. Not overwriting."
+  exit 0
+fi
+
+# Crear directorio hooks si no existe
+mkdir -p "$GIT_DIR/hooks"
+
+# Escribir el hook pre-commit
+cat > "$HOOK_PATH" << 'HOOK_EOF'
+#!/bin/bash
+bun run typecheck || exit 1
+bun run test || exit 1
+HOOK_EOF
+
+# Hacer el hook ejecutable
+chmod +x "$HOOK_PATH"
+
+echo "Pre-commit hook installed successfully."
+```
+
+## Notas de implementación
+
+- **Sin dependencias externas**: El script no instala Husky, lint-staged, ni ninguna otra herramienta. Solo escribe un archivo shell y configura permisos.
+- **Resolución dinámica de git dir**: Usa `git rev-parse --git-dir` para localizar el directorio correcto, incluso en worktrees.
+- **Detección de conflictos**: Si Husky o lint-staged ya está en `package.json`, el script avisa y no instala para evitar conflictos.
+- **Protección de hooks existentes**: Si ya existe un `.git/hooks/pre-commit`, el script no lo sobrescribe.
+- **Solo Bun**: El hook ejecuta `bun run typecheck` y `bun run test`. Asegúrate de que estos scripts están definidos en `package.json`.
+
+## Verificación
+
+Después de instalar, verifica que el hook está en su lugar.
+
+Para verificar, ejecuta:
+
+    ls -la .git/hooks/pre-commit
+
+Debe mostrar algo como:
+
+    -rwxr-xr-x  user  group  ... .git/hooks/pre-commit
+
+Luego, intenta hacer un commit. Si hay errores de tipo o tests fallidos, el commit será bloqueado:
+
+    git add .
+    git commit -m "test"
+    # Si typecheck o test falla, verás el error y el commit será abortado.
+
+## Troubleshooting
+
+### "Warning: Pre-commit hook already exists"
+
+Ya hay un hook pre-commit. Revisa su contenido:
+
+    cat .git/hooks/pre-commit
+
+Si quieres reemplazarlo, bórralo y ejecuta el script nuevamente:
+
+    rm .git/hooks/pre-commit
+    bash /path/to/installer
+
+### "Warning: Husky or lint-staged detected"
+
+Tu proyecto usa Husky o lint-staged. Este gate no se instala para evitar conflictos. Si quieres usar este gate, remove Husky/lint-staged de `package.json` y ejecuta de nuevo.
+
+### Hook no se ejecuta al hacer commit
+
+Verifica que el hook es ejecutable:
+
+    chmod +x .git/hooks/pre-commit
+
+Verifica que `bun run typecheck` y `bun run test` existen en `package.json`:
+
+    cat package.json | grep -A 5 '"scripts"'
+
+### "command not found: bun"
+
+Bun no está instalado o no está en PATH. Instala Bun desde https://bun.sh o configura PATH adecuadamente.
+
+## Adicional: Desinstalación
+
+Para remover el hook, simplemente bórralo:
+
+    rm .git/hooks/pre-commit

package/presets/cursor/rules/orchestration.mdc

@@ -7,6 +7,6 @@ alwaysApply: false
 
 - Use `/multitask` for independent parallel steps (review + docs).
 - Invoke subagents via Task tool: `orchestrator`, `architect`, `implementer`, `tester`, `reviewer`, `security-reviewer`, `complexity-auditor`, `docs`, `task-coach`, `repo-explorer`.
-- High-risk routes: `architect` → `implementer` → `tester` → `security-reviewer` → `reviewer`.
+- High-risk routes: `architect` → `tester` → `implementer` → `security-reviewer` → `reviewer`.
 - Run `repo-explorer` as background subagent for codebase mapping.
 - See `.cursor/agents/orchestrator.md` for full routing table.

package/presets/opencode/agents/architect.md

@@ -4,6 +4,7 @@ description:
   Designs the technical approach for a task — produces ADRs, module boundaries,
   and API contracts — so the Implementer has a reviewed plan before touching
   code.
+effort: high
 mode: subagent
 model: "{{MODEL}}"
 temperature: 0.1
@@ -21,7 +22,7 @@ permission:
   websearch: deny
   skill: ask
 ---
-# Agent Contract — architect v0.5.0
+# Agent Contract — architect v1.0.0
 
 ## Role
 
@@ -216,6 +217,26 @@ strategy and why]
 
 ---
 
+## CCEP-1 structured output
+
+When invoked via the CodeConductor Execution Protocol (`design` phase), return
+**valid JSON only** matching `technical-plan` — the Markdown plan above is the
+human-facing form; under CCEP-1 the same design is serialized to the schema:
+
+```json
+{ "approach": "", "filesAffected": [], "risks": [] }
+```
+
+Rules under CCEP-1:
+
+- `filesAffected` is the minimal-diff contract — nothing outside it may be
+  touched during implementation without a plan revision.
+- If a decision requires human input, do not resolve it silently; surface it so
+  the approval gate stops before implementation.
+- Never return free-form prose as the final answer in CCEP-1 mode.
+
+---
+
 ## Hard rules
 
 - Never write implementation code (no functions, no classes, no methods).

package/presets/opencode/agents/complexity-auditor.md

@@ -4,6 +4,7 @@ description:
   Analyzes code for bloat, unnecessary abstractions, and non-native solutions —
   produces a Complexity Audit Report with LOC deltas, dependency changes,
   cyclomatic complexity metrics, and bloat pattern findings.
+effort: medium
 mode: subagent
 model: "{{MODEL}}"
 temperature: 0.1
@@ -19,7 +20,7 @@ permission:
   websearch: deny
   skill: deny
 ---
-# Agent Contract — complexity-auditor v0.5.0
+# Agent Contract — complexity-auditor v1.0.0
 
 You are the Complexity Auditor — the code quality gate in the CodeConductor
 framework. You analyze diffs for bloat, unnecessary abstractions, and non-native
@@ -80,6 +81,20 @@ _(none)_ if no bloat patterns detected
 - Findings: [count]
 ```
 
+## CCEP-1 structured output
+
+When invoked via the CodeConductor Execution Protocol (`audit` phase in the
+`refactor` workflow), return **valid JSON only** matching `agent-output` and
+serialize the audit into `artifacts`:
+
+```json
+{ "status": "success", "artifacts": [{ "type": "complexity-audit", "path": "" }], "next_actions": [] }
+```
+
+Feed the metrics into the scorecard `cc-gain` criterion. Every finding must
+carry its `delete` / `replace-native` action — a finding without an action is
+not valid CCEP-1 output.
+
 ## What You Never Do
 
 - Edit any file — source, test, documentation, or configuration

package/presets/opencode/agents/contract-builder.md

@@ -3,6 +3,7 @@ name: contract-builder
 description:
   Defines API contracts, data shapes, and behavior specs before implementation —
   OpenAPI, JSON Schema, or TypeScript interfaces as source of truth.
+effort: high
 mode: subagent
 model: "{{MODEL}}"
 temperature: 0.1
@@ -24,7 +25,7 @@ permission:
   websearch: deny
   skill: ask
 ---
-# Agent Contract — contract-builder v0.5.0
+# Agent Contract — contract-builder v1.0.0
 
 ## Role
 
@@ -85,6 +86,21 @@ Produce one or more of:
 
 ---
 
+## CCEP-1 structured output
+
+When invoked via the CodeConductor Execution Protocol (`api-contract` phase),
+return **valid JSON only** matching `agent-output` and serialize the contract
+spec into `artifacts`:
+
+```json
+{ "status": "success", "artifacts": [{ "type": "api-contract", "path": "openapi.yaml" }], "next_actions": [] }
+```
+
+If contracts are ambiguous, set `status` to `needs_clarification` (or return the
+question in `next_actions`) rather than inventing shapes.
+
+---
+
 ## Hard rules
 
 - Never modify production source files outside docs and spec paths.