cc-codeconductor 1.5.1 → 1.6.0

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

@@ -62,7 +62,7 @@ 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).
+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.
 
 ---
 
@@ -74,7 +74,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 4 with the feedback.
+- 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.

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

package/presets/cursor/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/gemini/commands/cc/council.toml

@@ -61,7 +61,7 @@ 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).
+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.
 
 ---
 
@@ -73,7 +73,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 4 with the feedback.
+- 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.

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

@@ -116,6 +116,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)
@@ -126,10 +133,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
@@ -170,6 +179,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
@@ -195,6 +212,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/muse/AGENTS.md

@@ -0,0 +1,46 @@
+<!-- CODECONDUCTOR:BEGIN managed -->
+
+# CodeConductor — Muse Preset
+
+This file configures CodeConductor for **Muse** (Meta's coding-agent CLI,
+binary `muse`). It lives at the project root (`AGENTS.md`) so Muse's
+context-file loader picks it up automatically.
+
+## Behavioral Discipline
+
+1. **Think Before Coding** — state assumptions; ask if uncertain; present
+   alternatives instead of picking silently.
+2. **Simplicity First** — minimum code that solves the problem; no
+   speculative abstractions.
+3. **Surgical Changes** — touch only what the task requires; match existing
+   style; remove only what your own change made unused.
+4. **Goal-Driven Execution** — turn the task into a verifiable goal with a
+   success check; loop until it passes.
+
+## Commands
+
+CodeConductor ships its workflows as Muse skills under `.agents/skills/`,
+invoked as `/cc:<name>` (e.g. `/cc:feature`, `/cc:review`). Run `/cc:ask
+"<problem>"` when unsure which one applies — it recommends exactly one and
+stops; it does not start the workflow.
+
+Skills live under `.agents/skills/` (Muse discovers skills there natively,
+per its own docs). Read `.agents/skills/using-cc-skills/SKILL.md` first —
+it maps intent to the right slash command.
+
+Where a step says "adopt the `X` role", read the matching skill under
+`.agents/skills/` and act as that role for the rest of the step.
+
+## What never changes
+
+- Do not invoke the Implementer without an accepted Technical Plan.
+- Do not skip the Reviewer step for medium- or high-risk changes.
+- Do not store secrets in any file loaded by Muse.
+
+## Receipt integrity
+
+- For any implementation, test, review, handoff, or delivery decision, capture or verify the current RDD receipt with `bun run dev rdd`.
+- A receipt is valid only for its exact candidate. If code, tests, contracts, or runner configuration changed, repeat the affected verification.
+- TDD and Mutation Testing retain their existing gates; RDD verifies that their observed evidence still belongs to the current candidate.
+
+<!-- CODECONDUCTOR:END managed -->

package/presets/muse/hooks.json

@@ -0,0 +1,30 @@
+{
+  "safety-gate": {
+    "enabled": true,
+    "PreToolUse": [
+      {
+        "matcher": ".*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node -e \"const fs=require('fs');const c=['.muse/hooks/invoke-hook.cjs'];const p=c.find(f=>fs.existsSync(f));if(p){require(require('path').resolve(p));}else{process.exit(0);}\" pre-tool --format=muse"
+          }
+        ]
+      }
+    ]
+  },
+  "code-formatter": {
+    "enabled": true,
+    "PostToolUse": [
+      {
+        "matcher": ".*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node -e \"const fs=require('fs');const c=['.muse/hooks/invoke-hook.cjs'];const p=c.find(f=>fs.existsSync(f));if(p){require(require('path').resolve(p));}else{process.exit(0);}\" post-tool --format=muse"
+          }
+        ]
+      }
+    ]
+  }
+}

package/presets/opencode/commands/cc-council.md

@@ -62,7 +62,7 @@ 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).
+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.
 
 ---
 
@@ -74,7 +74,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 4 with the feedback.
+- 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.

package/presets/opencode/commands/cc-openspec.md

@@ -80,7 +80,9 @@ Use `$ARGUMENTS` BC-id or `npx cc-codeconductor openspec status` for next READY
 
 Run `npx cc-codeconductor openspec plan <BC-id>`. Show TaskCards and `openspec/changes/` path.
 
-Drive status with CLI (do not edit openspec-state.json): `openspec start <cardId>`, `openspec done <cardId>`, `openspec block <cardId> --reason "…"`, `openspec archive <itemId>`.
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs and stops. Before Step 4, review the plan in order — proposal → delta specs → tasks — and confirm intent, scope, testable FR/SC, and edge-case scenarios. Do not `start` any card until the plan reads correctly.
+
+Drive status with CLI (do not edit openspec-state.json): `openspec start <cardId>`, `openspec done <cardId>`, `openspec block <cardId> --reason "…"`, `openspec sync <itemId>` (merge specs without closing, optional), `openspec verify <itemId>` (advisory pre-archive checklist), `openspec archive <itemId>` (re-checks artifacts and analyze CRITICALs).
 
 ---
 
@@ -94,7 +96,7 @@ For each pending card: `npx cc-codeconductor openspec next`, then invoke the lis
 - implement → `implementer`
 - review → `reviewer`
 
-Run each phase as a subagent with isolated context. Implementer uses a git worktree.
+Run each phase as a subagent with isolated context. Implementer uses a git worktree. Discover is read-only (never writes code); implementer ticks `tasks.md` boxes (`- [ ]` → `- [x]`, only `x`/`X` counts). If implementation reveals a design problem, pause and reconcile planning artifacts first (any direction, planning-only, confirm each edit); if the intent changed, open a fresh item with `/cc-backlog`.
 
 ---
 
@@ -106,6 +108,6 @@ Reviewer approves or rejects against acceptance criteria. Reject → `IN_PROGRES
 
 ## Step 6 — Update
 
-Mark DONE with `openspec archive <itemId>` (all cards must be done), then run `openspec scan`.
+First `openspec verify <itemId> --output json` (advisory: confirm `archiveReady`). Mark DONE with `openspec archive <itemId>` (all cards must be done), then run `openspec scan`.
 
 Apply skill `openspec` for format and state rules.

package/presets/opencode/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/src/presets/manifests/muse.yml

@@ -0,0 +1,18 @@
+target: muse
+entries:
+  - src: muse/AGENTS.md
+    dest: AGENTS.md
+    strategy: merge-managed
+    globalStrategy: skip
+    template: true
+  - src: opencode/skills
+    dest: .agents/skills
+    strategy: overwrite
+  - src: muse/hooks.json
+    dest: .muse/hooks.json
+    strategy: overwrite
+    globalStrategy: skip
+  - src: shared/invoke-hook.cjs
+    dest: .muse/hooks/invoke-hook.cjs
+    strategy: overwrite
+    globalStrategy: skip

package/src/presets/models/muse.yml

@@ -0,0 +1,4 @@
+# Model configuration for Muse preset
+# Agent models and tool-name mappings live in roles.yml; loadModelConfig()
+# merges this file with it. See roles.yml for the shared table.
+target: muse