cc-codeconductor 1.5.1 → 1.6.1

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).
-
----
-
-## 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.
-
-## 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/claude/commands/cc/openspec.md

@@ -146,6 +146,13 @@ Show:
 
 Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs
+and stops. Before Step 4, review the plan in this order — proposal → delta
+specs → tasks — and confirm: intent is right, no scope creep, every FR is
+testable with a scenario that exercises it, edge/error cases are covered, and
+each task traces to an FR/SC. Fix the Markdown directly or ask for revisions.
+Do not `start` any card until the plan reads correctly.
+
 ---
 
 ## Drive card status (CLI)
@@ -156,10 +163,12 @@ Do not edit `.codeconductor/openspec-state.json` by hand.
 npx cc-codeconductor openspec start <cardId>
 npx cc-codeconductor openspec done <cardId>
 npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec sync <itemId>
+npx cc-codeconductor openspec verify <itemId>
 npx cc-codeconductor openspec archive <itemId>
 ```
 
-`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `sync` merges delta specs into `openspec/specs/` without closing the item (optional before archive). `verify` is the advisory pre-archive checklist: exit 0 with `archiveReady` plus Completeness/Correctness/Coherence issues. `archive` requires all cards done (and review evidence when Global review is required), re-checks planning artifacts and analyze CRITICALs, warns on unchecked `tasks.md` boxes, then moves `openspec/changes/<slug>` to `archive/`.
 
 ---
 
@@ -196,6 +205,14 @@ After each phase:
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 
+Discover is read-only: `repo-explorer` never writes code. The implementer ticks
+`tasks.md` boxes (`- [ ]` → `- [x]`) as each FR lands — only `x`/`X` counts as
+done. If implementation reveals a design problem, pause and reconcile the
+planning artifacts first (any direction: a later artifact may force revising an
+earlier one). Planning artifacts only in that step — never code — and confirm
+each edit. If the item's intent changed rather than its details, open a fresh
+item with `/cc:backlog` instead of warping this one.
+
 ---
 
 ## Step 5 — Review gate
@@ -221,6 +238,8 @@ If **approved**: proceed to Step 6.
 
 ## Step 6 — Scorecard and update backlog
 
+First run the advisory pre-archive check (`npx cc-codeconductor openspec verify <BC-id> --output json`): confirm `archiveReady` and clear any Completeness/Correctness/Coherence issues. Optionally run `openspec sync <BC-id>` to merge delta specs into `openspec/specs/` without closing the item. Then:
+
 1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
 2. Complete criteria; `scorecard record` with verdict and optional cost/tokens
 3. Set item `Progress: 100%`, `Status: DONE` if PASS

package/presets/claude/skills/openspec/SKILL.md

@@ -16,7 +16,7 @@ gates, not a reference doc. Specs describe WHAT; `design.md` describes HOW.
 
 ## When to Use
 
-- `/cc-openspec` or `openspec next` / `plan` / `done` / `archive`
+- `/cc-openspec` or `openspec plan` / `next` / `done` / `sync` / `verify` / `archive`
 - An item is `READY` or later and must move through the state machine
 
 **NOT** for creating `BACKLOG.md` (use skill `backlog`) or for stack-specific
@@ -26,22 +26,43 @@ coding rules.
 
 Local CLI is `bun run dev`. Published package is `npx cc-codeconductor`.
 
-1. `openspec validate` — must pass before delivery.
-2. `openspec plan BC-xxx` if the item is not yet `PLANNED`.
-3. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
-4. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
+1. `openspec validate` — must pass before delivery. If you reached this
+   workflow on your own (the user did not ask for OpenSpec) and there is no
+   `BACKLOG.md` / `openspec/` root, answer normally instead — never scaffold
+   one as a side effect.
+2. `openspec plan BC-xxx` if the item is not yet `PLANNED`. Planning only: it
+   writes TaskCards plus proposal/design/tasks/specs under
+   `openspec/changes/<slug>/` and stops. Never implement in this step.
+3. Review the plan before `start`: read proposal → delta specs → tasks, in that
+   order, and confirm intent, scope, testable FR/SC, and edge-case scenarios.
+   Fix the Markdown directly or ask for revisions — code comes later.
+4. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
+5. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
    implement (`implementer`) → review (`reviewer`). If Global `TDD required: yes`,
-   test runs before implement.
-5. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
-   evidence JSON is rejected.
-6. `scorecard create --task BC-xxx --from-diff` then record a verdict.
-7. `openspec archive` only after human review when `Review required: yes` and
-   the scorecard is PASS.
+   test runs before implement. Discover is read-only: it never writes code.
+6. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
+   evidence JSON is rejected. The implementer ticks `tasks.md` boxes
+   (`- [ ]` → `- [x]`) as each FR lands; only `x`/`X` counts as done.
+7. When implementation reveals a design problem, pause and reconcile the planning
+   artifacts first — in any direction (a later artifact may force revising an
+   earlier one). Planning artifacts only in that step, never code; confirm each
+   edit. If the item's intent changed rather than its details, open a fresh item
+   with `/cc-backlog` (`/cc:backlog`) instead of warping this one.
+8. `openspec verify --output json` — advisory pre-archive checklist
+   (`archiveReady` plus Completeness/Correctness/Coherence issues). Optional:
+   `openspec sync` merges delta specs into `openspec/specs/` without closing.
+9. `scorecard create --task BC-xxx --from-diff` then record a verdict.
+10. `openspec archive` only after human review when `Review required: yes` and
+    the scorecard is PASS. Archive re-checks planning artifacts and analyze
+    CRITICALs, and warns on unchecked `tasks.md` boxes.
 
 Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE`
 → Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
 `IN_PROGRESS`.
 
+`openspec status --output json` also reports artifact presence, `tasks.md`
+checkbox progress, and `nextSteps` for the next CLI call.
+
 ## Web interface scope
 
 When the task concerns web layout, component states, feedback, motion, or a
@@ -70,17 +91,24 @@ delivery read-only and record unavailable visual or emulator evidence as pending
 | I'll add tests after green | Global TDD required means tester before implementer. |
 | I'll write the evidence JSON myself | Handmade TDD JSON is rejected. Use the verification runner. |
 | The item is small; skip analyze | `openspec analyze` CRITICAL still stops implement. |
+| The plan is generated; skip reading it | Read proposal → specs → tasks before `start`. Generated is not reviewed. |
+| I'll fix the spec after shipping | Reconcile planning artifacts before continuing to implement. |
 
 ## Red Flags
 
 - Implementing while analyze reports CRITICAL
+- Starting cards before reading the generated plan
 - Archive without a PASS scorecard when review is required
+- Archive while `openspec verify` reports CRITICAL
 - Acceptance like "improve UX" with no measurable check
 
 ## Verification
 
 - [ ] `openspec validate` exit 0
+- [ ] Plan reviewed (proposal → specs → tasks) before `start`
 - [ ] `openspec analyze --output json` has no CRITICAL
 - [ ] TDD evidence from the runner when TDD is required
+- [ ] `tasks.md` boxes ticked as FRs land
+- [ ] `openspec verify --output json` checked before archive
 - [ ] `scorecard create --from-diff` recorded
 - [ ] Suite check (optional): `bun run dev scorecard suite-run --suite workflow-gates`

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).
-
----
-
-## 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.
-
-## 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-openspec/SKILL.md

@@ -128,6 +128,13 @@ Show:
 
 Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs
+and stops. Before Step 5, review the plan in this order — proposal → delta
+specs → tasks — and confirm: intent is right, no scope creep, every FR is
+testable with a scenario that exercises it, edge/error cases are covered, and
+each task traces to an FR/SC. Fix the Markdown directly or ask for revisions.
+Do not `start` any card until the plan reads correctly.
+
 ---
 
 ## Drive card status (CLI)
@@ -138,10 +145,12 @@ Do not edit `.codeconductor/openspec-state.json` by hand.
 npx cc-codeconductor openspec start <cardId>
 npx cc-codeconductor openspec done <cardId>
 npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec sync <itemId>
+npx cc-codeconductor openspec verify <itemId>
 npx cc-codeconductor openspec archive <itemId>
 ```
 
-`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `sync` merges delta specs into `openspec/specs/` without closing the item (optional before archive). `verify` is the advisory pre-archive checklist: exit 0 with `archiveReady` plus Completeness/Correctness/Coherence issues. `archive` requires all cards done (and review evidence when Global review is required), re-checks planning artifacts and analyze CRITICALs, warns on unchecked `tasks.md` boxes, then moves `openspec/changes/<slug>` to `archive/`.
 
 For test and implementation cards, `done` also requires a current RDD-backed
 RED or GREEN receipt respectively. Do not reuse evidence after candidate files
@@ -182,6 +191,14 @@ After each phase:
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 
+Discover is read-only: `repo-explorer` never writes code. The implementer ticks
+`tasks.md` boxes (`- [ ]` → `- [x]`) as each FR lands — only `x`/`X` counts as
+done. If implementation reveals a design problem, pause and reconcile the
+planning artifacts first (any direction: a later artifact may force revising an
+earlier one). Planning artifacts only in that step — never code — and confirm
+each edit. If the item's intent changed rather than its details, open a fresh
+item with `$cc-backlog` instead of warping this one.
+
 ---
 
 ## Step 6 — Review gate
@@ -207,6 +224,8 @@ If **approved**: proceed to Step 6.
 
 ## Step 7 — Scorecard and update backlog
 
+First run the advisory pre-archive check (`npx cc-codeconductor openspec verify <BC-id> --output json`): confirm `archiveReady` and clear any Completeness/Correctness/Coherence issues. Optionally run `openspec sync <BC-id>` to merge delta specs into `openspec/specs/` without closing the item. Then:
+
 1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
 2. Complete criteria; `scorecard record` with verdict and optional cost/tokens
 3. Set item `Progress: 100%`, `Status: DONE` if PASS

package/presets/codex/skills/openspec/SKILL.md

@@ -16,7 +16,7 @@ gates, not a reference doc. Specs describe WHAT; `design.md` describes HOW.
 
 ## When to Use
 
-- `/cc-openspec` or `openspec next` / `plan` / `done` / `archive`
+- `/cc-openspec` or `openspec plan` / `next` / `done` / `sync` / `verify` / `archive`
 - An item is `READY` or later and must move through the state machine
 
 **NOT** for creating `BACKLOG.md` (use skill `backlog`) or for stack-specific
@@ -26,22 +26,43 @@ coding rules.
 
 Local CLI is `bun run dev`. Published package is `npx cc-codeconductor`.
 
-1. `openspec validate` — must pass before delivery.
-2. `openspec plan BC-xxx` if the item is not yet `PLANNED`.
-3. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
-4. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
+1. `openspec validate` — must pass before delivery. If you reached this
+   workflow on your own (the user did not ask for OpenSpec) and there is no
+   `BACKLOG.md` / `openspec/` root, answer normally instead — never scaffold
+   one as a side effect.
+2. `openspec plan BC-xxx` if the item is not yet `PLANNED`. Planning only: it
+   writes TaskCards plus proposal/design/tasks/specs under
+   `openspec/changes/<slug>/` and stops. Never implement in this step.
+3. Review the plan before `start`: read proposal → delta specs → tasks, in that
+   order, and confirm intent, scope, testable FR/SC, and edge-case scenarios.
+   Fix the Markdown directly or ask for revisions — code comes later.
+4. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
+5. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
    implement (`implementer`) → review (`reviewer`). If Global `TDD required: yes`,
-   test runs before implement.
-5. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
-   evidence JSON is rejected.
-6. `scorecard create --task BC-xxx --from-diff` then record a verdict.
-7. `openspec archive` only after human review when `Review required: yes` and
-   the scorecard is PASS.
+   test runs before implement. Discover is read-only: it never writes code.
+6. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
+   evidence JSON is rejected. The implementer ticks `tasks.md` boxes
+   (`- [ ]` → `- [x]`) as each FR lands; only `x`/`X` counts as done.
+7. When implementation reveals a design problem, pause and reconcile the planning
+   artifacts first — in any direction (a later artifact may force revising an
+   earlier one). Planning artifacts only in that step, never code; confirm each
+   edit. If the item's intent changed rather than its details, open a fresh item
+   with `/cc-backlog` (`/cc:backlog`) instead of warping this one.
+8. `openspec verify --output json` — advisory pre-archive checklist
+   (`archiveReady` plus Completeness/Correctness/Coherence issues). Optional:
+   `openspec sync` merges delta specs into `openspec/specs/` without closing.
+9. `scorecard create --task BC-xxx --from-diff` then record a verdict.
+10. `openspec archive` only after human review when `Review required: yes` and
+    the scorecard is PASS. Archive re-checks planning artifacts and analyze
+    CRITICALs, and warns on unchecked `tasks.md` boxes.
 
 Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE`
 → Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
 `IN_PROGRESS`.
 
+`openspec status --output json` also reports artifact presence, `tasks.md`
+checkbox progress, and `nextSteps` for the next CLI call.
+
 ## Web interface scope
 
 When the task concerns web layout, component states, feedback, motion, or a
@@ -70,17 +91,24 @@ delivery read-only and record unavailable visual or emulator evidence as pending
 | I'll add tests after green | Global TDD required means tester before implementer. |
 | I'll write the evidence JSON myself | Handmade TDD JSON is rejected. Use the verification runner. |
 | The item is small; skip analyze | `openspec analyze` CRITICAL still stops implement. |
+| The plan is generated; skip reading it | Read proposal → specs → tasks before `start`. Generated is not reviewed. |
+| I'll fix the spec after shipping | Reconcile planning artifacts before continuing to implement. |
 
 ## Red Flags
 
 - Implementing while analyze reports CRITICAL
+- Starting cards before reading the generated plan
 - Archive without a PASS scorecard when review is required
+- Archive while `openspec verify` reports CRITICAL
 - Acceptance like "improve UX" with no measurable check
 
 ## Verification
 
 - [ ] `openspec validate` exit 0
+- [ ] Plan reviewed (proposal → specs → tasks) before `start`
 - [ ] `openspec analyze --output json` has no CRITICAL
 - [ ] TDD evidence from the runner when TDD is required
+- [ ] `tasks.md` boxes ticked as FRs land
+- [ ] `openspec verify --output json` checked before archive
 - [ ] `scorecard create --from-diff` recorded
 - [ ] Suite check (optional): `bun run dev scorecard suite-run --suite workflow-gates`

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).
-
----
-
-## 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.
-
-## 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/openspec.md

@@ -119,6 +119,13 @@ Show:
 
 Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs
+and stops. Before Step 5, review the plan in this order — proposal → delta
+specs → tasks — and confirm: intent is right, no scope creep, every FR is
+testable with a scenario that exercises it, edge/error cases are covered, and
+each task traces to an FR/SC. Fix the Markdown directly or ask for revisions.
+Do not `start` any card until the plan reads correctly.
+
 ---
 
 ## Drive card status (CLI)
@@ -129,10 +136,12 @@ Do not edit `.codeconductor/openspec-state.json` by hand.
 npx cc-codeconductor openspec start <cardId>
 npx cc-codeconductor openspec done <cardId>
 npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec sync <itemId>
+npx cc-codeconductor openspec verify <itemId>
 npx cc-codeconductor openspec archive <itemId>
 ```
 
-`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `sync` merges delta specs into `openspec/specs/` without closing the item (optional before archive). `verify` is the advisory pre-archive checklist: exit 0 with `archiveReady` plus Completeness/Correctness/Coherence issues. `archive` requires all cards done (and review evidence when Global review is required), re-checks planning artifacts and analyze CRITICALs, warns on unchecked `tasks.md` boxes, then moves `openspec/changes/<slug>` to `archive/`.
 
 For test and implementation cards, `done` also requires a current RDD-backed
 RED or GREEN receipt respectively. Do not reuse evidence after candidate files
@@ -173,6 +182,14 @@ After each phase:
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 
+Discover is read-only: `repo-explorer` never writes code. The implementer ticks
+`tasks.md` boxes (`- [ ]` → `- [x]`) as each FR lands — only `x`/`X` counts as
+done. If implementation reveals a design problem, pause and reconcile the
+planning artifacts first (any direction: a later artifact may force revising an
+earlier one). Planning artifacts only in that step — never code — and confirm
+each edit. If the item's intent changed rather than its details, open a fresh
+item with `/cc:backlog` instead of warping this one.
+
 ---
 
 ## Step 6 — Review gate
@@ -198,6 +215,8 @@ If **approved**: proceed to Step 6.
 
 ## Step 7 — Scorecard and update backlog
 
+First run the advisory pre-archive check (`npx cc-codeconductor openspec verify <BC-id> --output json`): confirm `archiveReady` and clear any Completeness/Correctness/Coherence issues. Optionally run `openspec sync <BC-id>` to merge delta specs into `openspec/specs/` without closing the item. Then:
+
 1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
 2. Complete criteria; `scorecard record` with verdict and optional cost/tokens
 3. Set item `Progress: 100%`, `Status: DONE` if PASS