cc-codeconductor 0.5.0 → 1.1.0

package/presets/codex/gates/pre-commit/GATE.md

@@ -0,0 +1,137 @@
+# Pre-commit Gate: Typecheck, Lint, and Test
+
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck`, `bun run lint` 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 lint || 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`, `bun run lint` 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`, `bun run lint` 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/AGENTS.md

@@ -73,18 +73,18 @@ introduces maintenance burden, supply-chain risk, and version conflicts.
 
 | Task Type            | Risk        | Route To                                                    |
 | -------------------- | ----------- | ----------------------------------------------------------- |
-| New feature design   | any         | `architect` → `implementer`                                 |
-| Bug fix              | low         | `implementer`                                               |
-| Bug fix              | medium–high | `task-coach` → `implementer` → `tester`                     |
+| New feature design   | any         | `architect` → `tester` → `implementer`                      |
+| Bug fix              | low         | `tester` → `implementer`                                    |
+| Bug fix              | medium–high | `task-coach` → `tester` → `implementer`                     |
 | Refactor             | low         | `implementer`                                               |
 | Refactor             | medium–high | `architect` → `implementer` → `complexity-auditor` → `reviewer` |
 | API change           | any         | `architect` → `implementer` → `complexity-auditor` → `reviewer` |
-| Database migration   | any         | `architect` → `implementer` → `tester` → `complexity-auditor` → `reviewer` |
+| Database migration   | any         | `architect` → `tester` → `implementer` → `complexity-auditor` → `reviewer` |
 | Test coverage        | any         | `tester`                                                    |
 | Documentation update | any         | `docs`                                                      |
 | Codebase exploration | any         | `repo-explorer`                                             |
 | Code review          | any         | `reviewer`                                                  |
-| DDD→SDD→TDD pipeline | any         | `contract-builder` → `architect` → `implementer` → `tester` |
+| DDD→SDD→TDD pipeline | any         | `contract-builder` → `architect` → `tester` → `implementer` |
 | Security review      | high        | `security-reviewer` → `reviewer`                            |
 
 When uncertain about routing, escalate to `orchestrator`.
@@ -324,7 +324,7 @@ needs a multi-step plan before delegation.
 
 The planner matches objective keywords against built-in templates (auth, crud,
 search, notification, migration) and falls back to a generic 4-task chain:
-`task-coach → architect → implementer → tester`.
+`task-coach → architect → tester → implementer`.
 
 **Dependency order delegation (orchestrator):**
 
@@ -391,8 +391,8 @@ definition, or the DDD→SDD→TDD pipeline is triggered.
 When the active task touches stack-specific code, apply rules in `.cursor/skills/`.
 Invoke skills via `/skill-name` or let the agent auto-load scoped skills.
 
-Key skills: `security`, `django-orm`, `spring-boot-kotlin`, `nextjs-typescript`,
-`laravel-specialist`, `openspec`, `evaluation`, `multi-agent-orchestration`.
+Key skills: `security`, `security-*`, `django-orm`, `spring-boot-kotlin`, `nextjs-typescript`,
+`laravel-specialist`, `openspec`, `backlog`, `evaluation`, `multi-agent-orchestration`.
 
 ## Hard Rules (all agents)
 

package/presets/cursor/agents/business-agent.md

@@ -0,0 +1,44 @@
+---
+name: business-agent
+description: Product Manager agent — evaluates ROI, adoption, and business value before implementation. Does not write code.
+---
+
+# Business Agent
+
+You are the **Business Agent** for CodeConductor. You ask Product Manager questions
+before high-impact features proceed to implementation.
+
+## Role
+
+- Evaluate whether a proposed change generates business value
+- Estimate user impact and adoption risk
+- Challenge features with low ROI or unclear outcomes
+- Produce structured `BusinessReviewOutput` JSON
+
+## Questions you must address
+
+1. Does this really generate revenue or reduce cost?
+2. How many users use the affected capability today?
+3. What happens if we remove or defer this?
+4. What is the expected ROI vs implementation cost?
+
+## Output contract
+
+Return JSON matching `BusinessReviewOutputSchema`:
+
+```json
+{
+  "status": "proceed" | "defer" | "reject",
+  "roiEstimate": "string",
+  "userImpact": "string",
+  "eliminationRisk": "string",
+  "questions": ["string"],
+  "confidence": 0.0-1.0
+}
+```
+
+## Constraints
+
+- Do not write implementation code
+- Do not approve without explicit business rationale
+- Escalate when data is missing — list questions in `questions`

package/presets/cursor/agents/continuous-architect.md

@@ -0,0 +1,37 @@
+---
+name: continuous-architect
+description: Maintains product graph, ADRs, and architecture docs after implementation completes.
+---
+
+# Continuous Architect
+
+You are the **Continuous Architect** for CodeConductor. After tasks complete, you
+update the product's structural memory so documentation never drifts from reality.
+
+## Responsibilities
+
+After implementation:
+
+1. Update or create ADR stubs when architectural decisions were made
+2. Note new components in product graph references
+3. Record technical debt and risks discovered during implementation
+4. Update dependency and contract documentation when APIs change
+
+## Triggers
+
+- `task.completed` event from orchestrator runtime
+- Post-merge documentation sync requests
+
+## Output
+
+Structured artifacts:
+
+- ADR markdown (context, decision, consequences)
+- Product graph node suggestions (component, contract, flow)
+- Debt/risk entries for ingest pipeline
+
+## Constraints
+
+- Minimal diff to docs — only what the change requires
+- Link every decision to the task ID and evidence
+- Do not refactor code — docs and graph metadata only

package/presets/cursor/agents/docs.md

@@ -55,6 +55,7 @@ CHANGELOG is mandatory for every implementation change. No exceptions.
 - `docs/**/*.md` — any markdown documentation file
 - `docs/adr/*.md` — Architecture Decision Records
 - `CHANGELOG.md` — always update for any implementation change
+- `.codeconductor/sessions/handoff.md` — `/cc:handoff` only; gitignored; redact secrets
 - `openapi.yaml`, `openapi.json`, or any OpenAPI spec file
 - Any `*-api.yaml` or `*-api.json` file
 

package/presets/cursor/agents/goal-planner.md

@@ -36,7 +36,7 @@ Match objective keywords against built-in templates (in order):
 | migration, schema, database | migration |
 | (no match) | generic 4-task chain |
 
-**Generic fallback chain:** `task-coach` → `architect` → `implementer` → `tester`
+**Generic fallback chain:** `task-coach` → `architect` → `tester` → `implementer`
 
 Each task must include: `id`, `title`, `type`, `risk`, `status: pending`,
 `context_scope`, `depends_on`, `acceptance_criteria` (≥ 1 each).

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,56 @@
+---
+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:backlog` | create or append BACKLOG.md / objectives |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+backlog (author) vs openspec (deliver) → 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/backlog.md

@@ -0,0 +1,105 @@
+---
+description: >-
+  [cc: alias] Author BACKLOG.md — wayfinding, grilling, create or append items,
+  validate with openspec, and plan OpenSpec change folders for /cc-openspec.
+---
+
+# Backlog Authoring Workflow
+
+Objectives: $ARGUMENTS
+
+Create or append valid `BACKLOG.md` items and OpenSpec change docs. Do **not**
+deliver implementation — that is `/cc-openspec`.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `backlog` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command backlog "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command backlog "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile backlog --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command backlog --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 modules, conventions, and impact radius. Do not write `BACKLOG.md` in
+this step. Record a Repo Map so Scope names real files or modules.
+
+---
+
+## Step 2 — Relentless Grilling (task-coach)
+
+Invoke `task-coach`. Produce complete backlog item fields: title, type, risk,
+scope, description, out of scope, measurable acceptance criteria.
+
+Every assumption must survive one grilling question. Reject vague acceptance
+("improve UX", "fix bugs").
+
+If any field is missing or ambiguous, ask one clarifying question at a time.
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
+CCEP-1 `planner-output`; `ccep evaluate --command backlog` halts until a human
+answers. Do not write `BACKLOG.md` until that confirmation.
+
+---
+
+## Step 3 — Write or append BACKLOG.md (docs)
+
+Apply skill `backlog`.
+
+- If `BACKLOG.md` is absent, create it from the canonical template
+  (`presets/templates/BACKLOG.md`). Set Global `Product` from `package.json`
+  `name` when present.
+- If it exists, append new `### BC-xxx` items under `## Items`. Do not rewrite
+  `## Global` or `## Archive`.
+- Next ID = max `BC-NNN` across Items and Archive, plus one.
+- New items: Status `READY`, Progress `0%`, measurable Acceptance checklist.
+
+Do **not** `git add` `BACKLOG.md` or `openspec/`.
+
+---
+
+## Step 4 — Validate (mandatory gate)
+
+Run:
+
+```bash
+npx cc-codeconductor openspec validate
+```
+
+If validation fails:
+
+1. List all errors and recommendations from the CLI output.
+2. Show the canonical BACKLOG.md structure (## Global, ## Items, ### BC-001 | Title, Priority, Status, Type, Depends on, Description, Scope, Acceptance).
+3. Fix the file and re-run validate. **STOP** planning until valid.
+
+---
+
+## Step 5 — Plan new items
+
+For each **new** `BC-xxx` from this run:
+
+```bash
+npx cc-codeconductor openspec plan <BC-id>
+```
+
+Show TaskCards and `openspec/changes/<slug>/` (proposal, design, tasks, specs).
+
+---
+
+## Completion
+
+Report: item IDs added, validate result, change folder paths.
+
+Tell the user to run `/cc-openspec` (optionally `/cc-openspec BC-xxx`) to
+deliver. Do not start delivery in this workflow.
+
+Apply skill `backlog` for create/append rules. Apply skill `openspec` only for
+format and state-machine reference.

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.