cc-codeconductor 1.6.0 → 1.6.1

package/dist/library.js

@@ -1756,11 +1756,11 @@ async function runCompileCheck(options) {
   }
 }
 // src/core/verification/verification-runner.ts
-import { mkdir as mkdir5, readdir as readdir2, writeFile as writeFile4 } from "node:fs/promises";
+import { mkdir as mkdir6, readdir as readdir2, writeFile as writeFile5 } from "node:fs/promises";
 
 // src/core/verification/rdd-receipt.ts
-import { createHash } from "node:crypto";
-import { readdir, readFile as readFile6 } from "node:fs/promises";
+import { createHash, randomBytes } from "node:crypto";
+import { mkdir as mkdir5, readdir, readFile as readFile6, writeFile as writeFile4 } from "node:fs/promises";
 import { join as join2, relative, resolve as resolve5, sep } from "node:path";
 var EXCLUDED_DIRECTORIES = new Set([
   ".git",
@@ -1801,6 +1801,23 @@ function manifestHash(paths) {
   return sha256(paths.map((entry) => `${entry.path}\x00${entry.hash}`).join(`
 `));
 }
+function receiptRegistryDir(projectRoot) {
+  return join2(resolve5(projectRoot), ".codeconductor", "rdd-receipts");
+}
+function isWellFormedNonce(nonce) {
+  return typeof nonce === "string" && /^[0-9a-f]{32}$/.test(nonce);
+}
+async function isRegisteredReceipt(projectRoot, receipt) {
+  if (!isWellFormedNonce(receipt.nonce))
+    return false;
+  try {
+    const raw = await readFile6(join2(receiptRegistryDir(projectRoot), `${receipt.nonce}.json`), "utf-8");
+    const entry = JSON.parse(raw);
+    return entry.manifestHash === receipt.manifestHash;
+  } catch {
+    return false;
+  }
+}
 function isRddReceipt(value) {
   if (!value || typeof value !== "object")
     return false;
@@ -1814,17 +1831,26 @@ async function captureReceipt(projectRoot, input) {
     throw new Error("RDD receipts require at least one protected path");
   }
   const paths = await fingerprint(projectRoot, input.paths);
-  return {
+  const hashed = manifestHash(paths);
+  const nonce = randomBytes(16).toString("hex");
+  const capturedAt = new Date().toISOString();
+  const receipt = {
     version: 1,
     taskId: input.taskId,
     phase: input.phase,
     paths,
     coverage: input.coverage ?? "paths",
-    manifestHash: manifestHash(paths),
+    manifestHash: hashed,
     command: input.command,
     outcome: input.outcome,
-    capturedAt: new Date().toISOString()
+    capturedAt,
+    nonce
   };
+  const directory = receiptRegistryDir(projectRoot);
+  await mkdir5(directory, { recursive: true });
+  const entry = { manifestHash: hashed, taskId: input.taskId, capturedAt };
+  await writeFile4(join2(directory, `${nonce}.json`), JSON.stringify(entry, null, 2), "utf-8");
+  return receipt;
 }
 async function collectReceiptPaths(projectRoot) {
   const root = resolve5(projectRoot);
@@ -1845,6 +1871,7 @@ async function collectReceiptPaths(projectRoot) {
   return paths.sort();
 }
 async function verifyReceipt(projectRoot, receipt) {
+  const registered = await isRegisteredReceipt(projectRoot, receipt);
   const expected = new Map(receipt.paths.map((entry) => [entry.path, entry.hash]));
   const changedPaths = [];
   const current = [];
@@ -1870,7 +1897,7 @@ async function verifyReceipt(projectRoot, receipt) {
   changedPaths.sort();
   const actualHash = manifestHash(current.sort((left, right) => left.path.localeCompare(right.path)));
   return {
-    valid: changedPaths.length === 0 && actualHash === receipt.manifestHash,
+    valid: registered && changedPaths.length === 0 && actualHash === receipt.manifestHash,
     expectedHash: receipt.manifestHash,
     actualHash,
     changedPaths
@@ -1915,8 +1942,8 @@ async function persistEvidence(projectRoot, evidence) {
   if (!evidencePath.success)
     return evidencePath;
   try {
-    await mkdir5(evDir, { recursive: true });
-    await writeFile4(evidencePath.data, JSON.stringify(evidence, null, 2), "utf-8");
+    await mkdir6(evDir, { recursive: true });
+    await writeFile5(evidencePath.data, JSON.stringify(evidence, null, 2), "utf-8");
   } catch (e) {
     return err(e instanceof Error ? e : new Error(String(e)));
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-codeconductor",
-  "version": "1.6.0",
+  "version": "1.6.1",
   "description": "A multi-agent orchestration framework for AI-assisted software engineering workflows.",
   "keywords": [
     "ai",
@@ -54,6 +54,7 @@
     "test:fast": "bun run scripts/test-fast.ts",
     "typecheck": "tsc --noEmit",
     "lint": "bun run scripts/lint.ts",
+    "check:council-redirect": "bun run scripts/check-council-redirect.ts",
     "check:coverage": "bun run scripts/check-coverage.ts",
     "check:prompt-changelog": "bun run scripts/check-prompt-changelog.ts",
     "check:drift": "bun run scripts/check-drift.ts",

package/presets/agy/skills/cc-feature/SKILL.md

@@ -66,31 +66,32 @@ not invoke implementer until the plan is approved.**
 
 ---
 
-## Step 3 — Implementation (implementer)
+## Step 3 — Test coverage (tester)
 
-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.
+Invoke `tester` with the approved Technical Plan and the Task Card.
 
-implementer must:
+tester must:
 
-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
-4. Produce an Implementation Summary: what changed, which files, how to verify
-   locally
+1. Write failing tests to cover the new behavior (RED)
+2. Ensure all acceptance criteria from the Task Card have at least one test
+3. Confirm the new tests fail for the right reason before implementation
+4. Produce a Coverage Summary: test files added or modified, cases covered
 
 ---
 
-## Step 4 — Test coverage (tester)
+## Step 4 — Implementation (implementer)
 
-Invoke `tester` with the Implementation Summary and the Task Card.
+Invoke `implementer` with the approved Technical Plan, the Task Card, and the
+failing tests from Step 3.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
-tester must:
+implementer must:
 
-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 Coverage Summary: test files added or modified, cases covered
+1. Read the Technical Plan before touching any file
+2. Apply the minimal diff to make the failing tests pass — only what the plan specifies
+3. Run the project test suite after implementation
+4. Produce an Implementation Summary: what changed, which files, how to verify
+   locally
 
 ---
 

package/presets/agy/skills/cc-fix/SKILL.md

@@ -21,24 +21,17 @@ Provide the following information in $ARGUMENTS:
 
 ## Web interface scope
 
-When the task concerns web layout, component states, feedback, motion, or a
-requested UI audit, apply skill `web-design-engineering` from the installed skill
-library. Use it during intake/discovery, design, test/implement, and review as
-applicable; keep this workflow’s gates and TDD order. Framework presence alone
-does not activate it; backend-only and native mobile work are excluded. Record
-required visual checks as pending when unavailable. Keep findings in the existing
-Review Report: contract failures in Spec Axis, technical issues in existing
-subchecks, and aesthetic preferences as suggestions; do not add an axis.
+Same web scope as `cc-feature`: when the fix concerns web layout, component
+states, feedback, motion, or a requested UI audit, apply skill
+`web-design-engineering` during test/implementation and review; keep this
+workflow's gates and TDD order. See `cc-feature` for the full scope rule.
 
 ## Android phone interface scope
 
-When the task concerns concrete Jetpack Compose phone layout, component states,
-interaction, accessibility, visual behavior, or a requested UI audit, apply skill
-`android-ui-design`. Use it during design, test/implementation, and review as
-applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
-framework, or dependency presence alone does not activate it; non-UI Android work
-stays with the general `android` skill. Audit-only requests remain read-only, and
-unavailable visual or emulator checks remain pending rather than claimed complete.
+Same Android scope as `cc-feature`: when the fix concerns concrete Jetpack
+Compose phone UI or a requested UI audit, apply skill `android-ui-design`
+during test/implementation and review; keep this workflow's gates and TDD
+order. See `cc-feature` for the full scope rule.
 
 
 ## Step 1 — Task Card validation (task-coach)
@@ -71,7 +64,7 @@ the affected code, and no public API or shared state is involved.
 
 Route: `task-coach` → `tester` → `implementer`
 
-Proceed directly to Step 3a.
+Proceed directly to Step 3.
 
 ### Medium or high-risk route
 
@@ -92,23 +85,37 @@ before continuing.**
 
 ---
 
-## Step 3a — Implementation, low-risk (implementer)
+## Step 3 — Regression tests (tester)
 
-Invoke `implementer` with the Task Card.
+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 4a — Implementation, low-risk (implementer)
+
+Invoke `implementer` with the Task Card and the failing regression test from Step 3.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
 implementer must:
 
 1. Locate the defect using the reproduction steps
-2. Apply the minimal fix — no unrelated changes
+2. Apply the minimal fix to make the regression test pass — no unrelated changes
 3. Run the test suite
 4. Produce an Implementation Summary: root cause, fix applied, files changed
 
 ---
 
-## Step 3b — Implementation, medium/high-risk (implementer)
+## Step 4b — Implementation, medium/high-risk (implementer)
 
-Invoke `implementer` with the approved Technical Plan and the Task Card.
+Invoke `implementer` with the approved Technical Plan, the Task Card, and the
+failing regression test from Step 3.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
 implementer must follow the plan exactly. Any deviation requires a new Technical
@@ -116,19 +123,6 @@ 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
 
 Invoke `reviewer` with the diff and Task Card.

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

@@ -3,6 +3,8 @@ name: cc-council
 description: Run the full Council-Driven Development workflow — SDD spec creation, TDD enforcement, surgical implementation, and multi-perspective review.
 ---
 
+<!-- Source of truth for the council workflow command. The cursor, claude and opencode copies are generated from this template by scripts/inject-ccep-bootstrap.ts; gemini and codex derive from the cursor copy via scripts/render-agent-commands.ts. Edit here, then regenerate. -->
+
 # Council-Driven Workflow
 
 Task request: $ARGUMENTS

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

@@ -2,89 +2,8 @@
 description: Council-driven workflow with CCEP-1 bootstrap
 ---
 
-# Council-Driven Workflow
-
-Task request: $ARGUMENTS
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/inject-ccep-bootstrap.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
-3. 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.
-4. Pass each subagent only the compiled `prompt` for its phase — 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), at most 3 iterations -- then stop and report the failing tests instead of looping.
-
----
-
-## 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 (at most 3 review rounds in total -- then deliver the BLOCKED verdict with the unresolved findings instead of looping).
-
-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.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `/cc:fix` or `/cc:feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.

package/presets/codex/skills/cc-council/SKILL.md

@@ -3,99 +3,8 @@ name: cc-council
 description: Council-driven workflow with CCEP-1 bootstrap
 ---
 
-# council
-
-Invoke as `$cc-council`. The user request follows the skill mention.
-
-## Council context budget
-
-Use GPT-6.1 Sol with medium reasoning effort. Give each necessary council role
-the same short evidence summary and relevant diff. Reuse those findings in the
-verdict; avoid spawning roles for questions already answered by evidence.
-
-# Council-Driven Workflow
-
-Task request: $ARGUMENTS
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/render-agent-commands.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
-3. 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.
-4. Pass each subagent only the compiled `prompt` for its phase — 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), at most 3 iterations -- then stop and report the failing tests instead of looping.
-
----
-
-## 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 (at most 3 review rounds in total -- then deliver the BLOCKED verdict with the unresolved findings instead of looping).
-
-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.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `$cc-fix` or `$cc-feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.

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

@@ -2,89 +2,8 @@
 description: Council-driven workflow with CCEP-1 bootstrap
 ---
 
-# Council-Driven Workflow
-
-Task request: $ARGUMENTS
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/inject-ccep-bootstrap.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
-3. 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.
-4. Pass each subagent only the compiled `prompt` for its phase — 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), at most 3 iterations -- then stop and report the failing tests instead of looping.
-
----
-
-## 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 (at most 3 review rounds in total -- then deliver the BLOCKED verdict with the unresolved findings instead of looping).
-
-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.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `/cc:fix` or `/cc:feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.

package/presets/gemini/commands/cc/council.toml

@@ -1,90 +1,9 @@
 description = "Council-driven workflow with CCEP-1 bootstrap"
 
 prompt = """
-# Council-Driven Workflow
-
-Task request: {{args}}
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/render-agent-commands.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "{{args}}" --view prompt --output json`
-3. 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.
-4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `{{args}}` to planners.
-
----
-
-## Step 1 — Wayfinding (repo-explorer)
-
-If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (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), at most 3 iterations -- then stop and report the failing tests instead of looping.
-
----
-
-## 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 (at most 3 review rounds in total -- then deliver the BLOCKED verdict with the unresolved findings instead of looping).
-
-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.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `/cc:fix` or `/cc:feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.
 """