cc-codeconductor 0.5.0 → 1.1.0

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

@@ -0,0 +1,69 @@
+---
+name: cc-backlog
+description:
+  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"`. Invoke
+`repo-explorer`. Do not write `BACKLOG.md`. Scope must name real files.
+
+---
+
+## Step 2 — Relentless Grilling (task-coach)
+
+Invoke `task-coach`. Measurable acceptance only. One grilling question at a time.
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser`;
+`ccep evaluate --command backlog` halts until a human answers.
+
+---
+
+## Step 3 — Write or append BACKLOG.md
+
+Apply skill `backlog`. Create from template if missing; otherwise append under
+`## Items`. Next `BC-NNN` = max existing + 1. Status `READY`. Do not rewrite
+`## Global` or `## Archive`. Do not `git add` `BACKLOG.md` or `openspec/`.
+
+---
+
+## Step 4 — Validate (mandatory gate)
+
+Run `npx cc-codeconductor openspec validate`. If invalid, show errors and
+canonical structure, fix, re-validate. **STOP** planning until valid.
+
+---
+
+## Step 5 — Plan new items
+
+For each new `BC-id`: `npx cc-codeconductor openspec plan <BC-id>`.
+
+---
+
+## Completion
+
+Report IDs, validate result, change folders. Tell the user to run `/cc-openspec`.
+Apply skill `backlog`.

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

@@ -0,0 +1,33 @@
+---
+name: cc-clarify
+description:
+  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/agy/workflows/cc-council.md

@@ -7,20 +7,44 @@ description: Run the full Council-Driven Development workflow — SDD spec creat
 
 Task request: $ARGUMENTS
 
-## Step 1 — Deliberation & Specification (SDD)
+## 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 resolve ambiguities (Think Before Coding).
+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. Show the agreed Task Card & Technical Plan and wait for human confirmation before continuing.**
+**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 2 — Test Definition (TDD)
+## Step 3 — Test Definition (TDD)
 
 Invoke `tester` with the approved Task Card & Technical Plan.
 
@@ -32,7 +56,7 @@ tester must:
 
 ---
 
-## Step 3 — Surgical Implementation
+## Step 4 — Surgical Implementation
 
 Invoke `implementer` with the failing tests and the Technical Plan.
 
@@ -44,7 +68,7 @@ implementer must:
 
 ---
 
-## Step 4 — Multi-Perspective Council Review
+## Step 5 — Multi-Perspective Council Review
 
 Invoke the `council` skill on the generated diff to perform the final review phase.
 
@@ -52,7 +76,7 @@ The council will evaluate the diff against the 6 axes (Architecture, Security, P
 
 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 3 with the feedback.
+- Return to Step 4 with the feedback.
 
 If APPROVED (no CRITICAL findings):
 - Deliver the final Council Verdict and the diff summary.

package/presets/agy/workflows/cc-db-migration.md

@@ -9,6 +9,19 @@ description:
 
 Migration request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `db-migration` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command db-migration "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command db-migration "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile db-migration --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
 ## Step 1 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the request above.
@@ -36,22 +49,22 @@ compatibility strategy, rollback/forward-fix notes, and test approach.
 
 ---
 
-## Step 3 — Implementation (implementer)
+## Step 3 — Migration tests (tester)
 
-Invoke `implementer` with the approved plan.
+Invoke `tester`.
 
-implementer must keep model and migration changes together, avoid unrelated
-refactors, and preserve the deployment order specified by architect.
+tester must cover migration-sensitive behavior where the stack supports it,
+including happy path, existing-data edge cases, and rollback/forward-fix notes
+when automated rollback tests are not practical.
 
 ---
 
-## Step 4 — Migration tests (tester)
+## Step 4 — Implementation (implementer)
 
-Invoke `tester`.
+Invoke `implementer` with the approved plan.
 
-tester must cover migration-sensitive behavior where the stack supports it,
-including happy path, existing-data edge cases, and rollback/forward-fix notes
-when automated rollback tests are not practical.
+implementer must keep model and migration changes together, avoid unrelated
+refactors, and preserve the deployment order specified by architect.
 
 ---
 

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

@@ -0,0 +1,37 @@
+---
+name: cc-explore
+description:
+  Map the repository and recommend the next CodeConductor slash command. Read-only.
+---
+
+# Explore Workflow
+
+Explore request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `explore` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command explore "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command explore "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile explore --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Map (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `repo-explorer`. Produce a Repo Map. Do not write code.
+
+---
+
+## Step 2 — Suggest next command (orchestrator)
+
+Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:backlog`, `/cc:openspec`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+
+---
+
+## Completion
+
+Report the Repo Map and the recommended next `/cc:` command.

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

@@ -9,7 +9,29 @@ description:
 
 Feature request: $ARGUMENTS
 
-## Step 1 — Task Card validation (task-coach)
+## Step 0 — CCEP Bootstrap
+
+Command: `feature` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile feature --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the feature description above.
 
@@ -26,7 +48,7 @@ continuing.**
 
 ---
 
-## Step 2 — Technical Plan (architect)
+## Step 3 — Technical Plan (architect)
 
 Invoke `architect` with the validated Task Card from Step 1.
 
@@ -44,7 +66,20 @@ not invoke implementer until the plan is approved.**
 
 ---
 
-## Step 3 — Implementation (implementer)
+## Step 4 — Test coverage (tester)
+
+Invoke `tester` with the Implementation Summary and the Task Card.
+
+tester must:
+
+1. Write or extend failing tests for the new behavior before implementation (RED)
+2. Ensure all acceptance criteria from the Task Card have at least one test
+3. Run the full test suite and confirm it passes
+4. Produce a Coverage Summary: test files added or modified, cases covered
+
+---
+
+## Step 5 — Implementation (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.
@@ -53,26 +88,13 @@ implementer 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
+3. Run the project test suite and make the previously written failing tests pass
 4. Produce an Implementation Summary: what changed, which files, how to verify
    locally
 
 ---
 
-## Step 4 — Test coverage (tester)
-
-Invoke `tester` with the Implementation Summary and the Task Card.
-
-tester 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
-
----
-
-## Step 5 — Code review (reviewer)
+## Step 6 — Code review (reviewer)
 
 Invoke `reviewer` with the complete diff and the Task Card.
 
@@ -87,7 +109,7 @@ they are resolved and re-reviewed.
 
 ---
 
-## Step 6 — Documentation (docs)
+## Step 7 — Documentation (docs)
 
 Invoke `docs` only if any of the following changed:
 

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.