cc-codeconductor 1.2.0 → 1.3.0

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

@@ -1,6 +1,5 @@
 ---
 id: android
-version: 1.0.0
 name: Android + Kotlin (Jetpack Compose & Media3)
 description: >
   Provides expert knowledge for building modern native Android apps using Kotlin, Jetpack Compose, Material Design 3, MVI architecture, Hilt dependency injection, and Media3/ExoPlayer.

package/presets/codex/skills/api-versioning/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: api-versioning
-version: 1.0.0
 name: API Versioning
 description: >
   Provides expert knowledge for designing, implementing, and managing REST API

package/presets/codex/skills/cc-api-contract/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-api-contract
-description: compatibility constraints, contract tests, documentation, and review.
+description: Run the API contract workflow for public interface changes, compatibility constraints, contract tests, documentation, and review.
 ---
 
 # api-contract
@@ -30,7 +30,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:api-contract`
+4. Next command spelling on this runner: `$cc-api-contract`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -39,7 +39,7 @@ Local development: `bun run dev <same argv>`. Published package: `npx cc-codecon
 
 ## Step 1 — Task Card validation (Task Coach role)
 
-Invoke the `task-coach` subagent via the Task tool.
+Adopt the `task-coach` role as defined in `AGENTS.md`.
 
 The Task Card must classify the task as high risk by default and include the
 affected public interface, request/response examples, compatibility notes,
@@ -52,7 +52,7 @@ criteria.
 
 ## Step 2 — Technical Plan (Architect role)
 
-Invoke the `architect` subagent via the Task tool.
+Adopt the `architect` role as defined in `AGENTS.md`.
 
 Define the API contract, validation strategy, compatibility behavior, docs or
 OpenAPI changes, and reviewer blocking conditions.
@@ -63,7 +63,7 @@ OpenAPI changes, and reviewer blocking conditions.
 
 ## Step 3 — Implementation (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 Apply the minimal diff, preserve compatible behavior unless explicitly approved
 as breaking, and update only the planned files.
@@ -72,7 +72,7 @@ as breaking, and update only the planned files.
 
 ## Step 4 — Contract Tests (Tester role)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `AGENTS.md`.
 
 Add or update tests for request shape, response shape, status/error behavior,
 and backward compatibility.
@@ -81,7 +81,11 @@ and backward compatibility.
 
 ## Step 5 — Review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `AGENTS.md`.
 
 Block on missing contract tests, undocumented breaking changes, or docs/OpenAPI
 drift.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-backlog
-description: validate with openspec, and plan OpenSpec change folders for /cc-openspec.
+description: Author BACKLOG.md — wayfinding, grilling, create or append items, validate with openspec, and plan OpenSpec change folders for /cc-openspec.
 ---
 
 # backlog

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

@@ -1,6 +1,6 @@
 ---
 name: cc-clarify
-description: CodeConductor clarify workflow
+description: Re-explain the last deliverable in Task Card vocabulary when it did not land.
 ---
 
 # clarify

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

@@ -90,3 +90,7 @@ If APPROVED (no CRITICAL findings):
 ## 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`.

package/presets/codex/skills/cc-db-migration/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-db-migration
-description: operational sequencing, tests, and review.
+description: Run the database migration workflow for schema/data changes, operational sequencing, tests, and review.
 ---
 
 # db-migration
@@ -31,7 +31,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:db-migration`
+4. Next command spelling on this runner: `$cc-db-migration`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -40,7 +40,7 @@ Local development: `bun run dev <same argv>`. Published package: `npx cc-codecon
 
 ## Step 1 — Task Card validation (Task Coach role)
 
-Invoke the `task-coach` subagent via the Task tool.
+Adopt the `task-coach` role as defined in `AGENTS.md`.
 
 The Task Card must classify the task as high risk and include affected schema,
 model, and migration files; data backfill needs; deployment ordering;
@@ -52,7 +52,7 @@ rollback/forward-fix strategy; lock risk; data risk; and verification commands.
 
 ## Step 2 — Migration Plan (Architect role)
 
-Invoke the `architect` subagent via the Task tool.
+Adopt the `architect` role as defined in `AGENTS.md`.
 
 Define the schema/data plan, operational sequencing, compatibility strategy,
 rollback/forward-fix notes, and test approach.
@@ -63,7 +63,7 @@ rollback/forward-fix notes, and test approach.
 
 ## Step 3 — Migration Tests (Tester role)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `AGENTS.md`.
 
 Cover migration-sensitive behavior where the stack supports it, including
 existing-data edge cases and rollback/forward-fix notes when automated rollback
@@ -73,7 +73,7 @@ tests are not practical.
 
 ## Step 4 — Implementation (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 Keep model and migration changes together, avoid unrelated refactors, and
 preserve the deployment order specified by architect.
@@ -82,7 +82,11 @@ preserve the deployment order specified by architect.
 
 ## Step 5 — Review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `AGENTS.md`.
 
 Block on missing migration tests, missing data-risk notes, undocumented
 deployment sequencing, or model/migration drift.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-explore
-description: CodeConductor explore workflow
+description: Map the repository and recommend the next CodeConductor slash command. Read-only.
 ---
 
 # explore
@@ -31,10 +31,10 @@ If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `
 
 ## 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.
+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.
+Report the Repo Map and the recommended next `$cc-` command.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-feature
-description: implementation, testing, review, and documentation.
+description: Run the full feature workflow — task validation, technical design, implementation, testing, review, and documentation.
 ---
 
 # feature
@@ -33,10 +33,14 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:feature`
+4. Next command spelling on this runner: `$cc-feature`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
+Skills: `using-cc-skills`, `openspec`, `testing-tdd`, `evaluation`.
+Do not skip `openspec analyze` when a change folder is active.
+"I'll add tests later" is not allowed — tester before implementer.
+
 ---
 
 
@@ -51,7 +55,7 @@ Record a Repo Map artifact before intake.
 
 ## Step 2 — Task Card validation (Task Coach role)
 
-Invoke the `task-coach` subagent via the Task tool.
+Adopt the `task-coach` role as defined in `AGENTS.md`.
 
 Produce a complete Task Card. The Task Card is ready when it contains: title,
 type, risk classification, scope, context, acceptance criteria, and constraints.
@@ -66,7 +70,7 @@ continuing.**
 
 ## Step 3 — Technical Plan (Architect role)
 
-Invoke the `architect` subagent via the Task tool.
+Adopt the `architect` role as defined in `AGENTS.md`.
 
 Produce a Technical Plan that covers:
 
@@ -84,7 +88,7 @@ not proceed to implementation until the plan is approved.**
 
 ## Step 4 — Test coverage (Tester role)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `AGENTS.md`.
 
 Use the Implementation Summary and the Task Card.
 
@@ -97,7 +101,7 @@ Use the Implementation Summary and the Task Card.
 
 ## Step 5 — Implementation (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 Use the approved Technical Plan and the Task Card from the steps above.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -112,7 +116,7 @@ Implementer creates a Git Worktree before touching any file; all edits happen in
 
 ## Step 6 — Code review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `AGENTS.md`.
 
 Use the complete diff and the Task Card.
 
@@ -126,7 +130,7 @@ they are resolved and the diff is re-reviewed.
 
 ## Step 7 — Documentation (Docs role)
 
-Invoke the `docs` subagent via the Task tool.
+Adopt the `docs` role as defined in `AGENTS.md`.
 
 Invoke this step only if any of the following changed:
 
@@ -152,3 +156,7 @@ Report the following:
 
 The feature is complete only when: all tests pass, no CRITICAL review findings
 remain, and documentation reflects the implemented behavior.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-fix
-description: validation, implementation, testing, and optional review.
+description: Run the bug fix workflow — risk-based routing through task validation, implementation, testing, and optional review.
 ---
 
 # fix
@@ -41,7 +41,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:fix`
+4. Next command spelling on this runner: `$cc-fix`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -59,7 +59,7 @@ Record a Repo Map artifact before intake.
 
 ## Step 2 — Task Card validation (Task Coach role)
 
-Invoke the `task-coach` subagent via the Task tool.
+Adopt the `task-coach` role as defined in `AGENTS.md`.
 
 Produce a Task Card that includes:
 
@@ -114,7 +114,7 @@ before continuing.**
 
 ## Step 4 — Regression tests (Tester role)
 
-Invoke the `tester` subagent via the Task tool. Apply for all risk levels.
+Adopt the `tester` role as defined in `AGENTS.md`. Apply for all risk levels.
 
 1. Write a regression test that reproduces the original bug and confirm it fails
    before any fix (RED).
@@ -125,7 +125,7 @@ Invoke the `tester` subagent via the Task tool. Apply for all risk levels.
 
 ## Step 5a — Implementation, low-risk (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool. Use the Task Card.
+Adopt the `implementer` role as defined in `AGENTS.md`. Use the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
 1. Locate the defect using the reproduction steps.
@@ -137,7 +137,7 @@ Implementer creates a Git Worktree before touching any file; all edits happen in
 
 ## Step 5b — Implementation, medium/high-risk (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool. Use the approved
+Adopt the `implementer` role as defined in `AGENTS.md`. Use the approved
 Technical Plan and the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
@@ -148,7 +148,7 @@ After implementation, run the full test suite.
 
 ## Step 6 — Review (Reviewer role) — medium/high-risk only
 
-Invoke the `reviewer` subagent via the Task tool. Use the diff and Task
+Adopt the `reviewer` role as defined in `AGENTS.md`. Use the diff and Task
 Card.
 
 Produce a Review Report with CRITICAL / WARNING / SUGGESTION findings. If any
@@ -163,3 +163,10 @@ Report: Task Card, Implementation Summary, regression test added, Review Report
 
 The fix is complete only when: the regression test passes, the full suite
 passes, and no CRITICAL review findings remain.
+
+Skills: `testing-tdd`, `evaluation`. Record `scorecard create --from-diff`.
+A small fix still needs a Task Card and a failing regression test first.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-handoff
-description: CodeConductor handoff workflow
+description: Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets).
 ---
 
 # handoff
@@ -34,7 +34,7 @@ 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.
+pass/fail (not log dumps), open questions, and the next `$cc-` command.
 
 Do not edit source or tests.
 

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

@@ -1,6 +1,6 @@
 ---
 name: cc-iterative
-description: Relentless Grilling, contract and spec design, TDD, council review, and docs.
+description: Run the advanced iterative workflow — Wayfinding AST discovery, Relentless Grilling, contract and spec design, TDD, council review, and docs.
 ---
 
 # iterative
@@ -33,7 +33,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:iterative`
+4. Next command spelling on this runner: `$cc-iterative`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -44,7 +44,7 @@ Local development: `bun run dev <same argv>`. Published package: `npx cc-codecon
 
 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 the `repo-explorer` subagent via the Task tool
+scoped subgraph). Then adopt the `repo-explorer` role as defined in `AGENTS.md`
 with that graph output.
 
 repo-explorer maps directory trees, conventions, god nodes, and affected
@@ -56,7 +56,7 @@ context.
 
 ## Step 2 — Relentless Grilling & Task Card (task-coach)
 
-Invoke the `task-coach` subagent via the Task tool.
+Adopt the `task-coach` role as defined in `AGENTS.md`.
 
 Produce a complete Task Card. The Task Card is ready when it contains: title,
 type, risk classification, scope, context, acceptance criteria, and
@@ -76,7 +76,7 @@ continuing.
 
 ## Step 3 — Contract & Technical Plan (contract-builder & architect)
 
-Invoke `contract-builder` then `architect` via the Task tool.
+Adopt the `contract-builder` role as defined in `AGENTS.md`, then the `architect` role as defined in `AGENTS.md`.
 
 1. Define API contracts, JSON Schemas, or TypeScript interfaces.
 2. Formulate the Technical Plan (chosen approach, affected files, trade-offs).
@@ -89,7 +89,7 @@ not proceed to tests until the plan is approved.**
 
 ## Step 4 — Test coverage (Tester role)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `AGENTS.md`.
 
 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.
@@ -99,7 +99,7 @@ Invoke the `tester` subagent via the Task tool.
 
 ## Step 5 — Implementation (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 Use the approved Technical Plan, contracts, and the failing tests.
 Implementer creates a Git Worktree before touching any file; all edits happen
@@ -132,7 +132,7 @@ If APPROVED (no CRITICAL findings), continue.
 
 ## Step 7 — Documentation (Docs role)
 
-Invoke the `docs` subagent via the Task tool when a public API, public module,
+Adopt the `docs` role as defined in `AGENTS.md` when a public API, public module,
 or user-visible behavior changed.
 
 Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG

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

@@ -1,6 +1,6 @@
 ---
 name: cc-openspec
-description: orchestrate agents by phase, review gate, and update backlog state.
+description: Run OpenSpec backlog delivery — validate BACKLOG.md, plan TaskCards, orchestrate agents by phase, review gate, and update backlog state.
 ---
 
 # openspec
@@ -37,7 +37,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:openspec`
+4. Next command spelling on this runner: `$cc-openspec`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 

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

@@ -1,6 +1,6 @@
 ---
 name: cc-prototype
-description: CodeConductor prototype workflow
+description: Disposable spike in an isolated worktree. Not a merge candidate.
 ---
 
 # prototype
@@ -39,4 +39,4 @@ Invoke `implementer` in a Git worktree that is not a merge candidate. Label the
 
 ## Completion
 
-Report bounds, worktree path, and what was learned. Recommend `/cc:feature` or `/cc:fix` if the spike should become real work.
+Report bounds, worktree path, and what was learned. Recommend `$cc-feature` or `$cc-fix` if the spike should become real work.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-refactor
-description: test verification, risk-based implementation, and scope enforcement.
+description: Run the refactor workflow — mandatory architectural justification, test verification, risk-based implementation, and scope enforcement.
 ---
 
 # refactor
@@ -50,7 +50,7 @@ Command: `refactor` (fixed for this workflow — do not infer from user text)
 
 ## Step 1 — Architectural justification (Architect role)
 
-Invoke the `architect` subagent via the Task tool. Always invoke this step
+Adopt the `architect` role as defined in `AGENTS.md`. Always invoke this step
 first, regardless of risk level. A refactor without a written justification is
 scope creep in disguise.
 
@@ -99,7 +99,7 @@ Proceed to Step 3b.
 
 ## Step 3a — Implementation, low-risk (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool. Use the approved
+Adopt the `implementer` role as defined in `AGENTS.md`. Use the approved
 Refactor Plan.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
@@ -139,7 +139,7 @@ regression. **STOP and report.**
 
 ## Step 5 — Code review (Reviewer role) — medium/high-risk only
 
-Invoke the `reviewer` subagent via the Task tool. Use the diff and Refactor
+Adopt the `reviewer` role as defined in `AGENTS.md`. Use the diff and Refactor
 Plan.
 
 Verify:
@@ -161,3 +161,7 @@ and after, Review Report (if applicable).
 The refactor is complete only when: all pre-existing tests still pass, the
 implementation matches the approved plan exactly, and no CRITICAL review
 findings remain.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-review
-description: CRITICAL, WARNING, and SUGGESTION findings; CRITICAL findings block merge.
+description: Run a structured code review — produces a Review Report with CRITICAL, WARNING, and SUGGESTION findings; CRITICAL findings block merge.
 ---
 
 # review
@@ -58,7 +58,7 @@ Show the diff summary (files changed, lines added/removed) before proceeding.
 
 ## Step 2 — Code review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `AGENTS.md`.
 
 Evaluate the diff against the following checklist:
 
@@ -150,3 +150,7 @@ npx cc-codeconductor scorecard regression
 ```
 
 Map merge recommendation to scorecard verdict. Record outcome for trend tracking.
+
+## Next
+
+Approved: merge. Blocked: return the findings to `$cc-fix` or `$cc-feature`.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-scorecard
-description: checklist, and aggregate stats.
+description: Evaluate deliverable quality — scorecard, outcome tracking, regression checklist, and aggregate stats.
 ---
 
 # scorecard

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

@@ -1,6 +1,6 @@
 ---
 name: cc-security
-description: security-* skills, authorization gate, risk-based routing, hardening, and review.
+description: Run the authorized defensive security workflow — domain security-* skills, authorization gate, risk-based routing, hardening, and review.
 ---
 
 # security
@@ -180,3 +180,7 @@ resolved.
 Report: Task Card, Implementation Summary, regression test added, Review Report
 (if applicable). The task is complete only when: the regression test passes, the
 full suite passes, and no CRITICAL review findings remain.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

package/presets/codex/skills/cc-spec-mutation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-spec-mutation
-description: into an immutable Gherkin contract (SHA-256 frozen), implement under the three laws of TDD, pass a judge audit, and merge only if every mutant dies.
+description: Spec-locked TDD with a mutation-testing gate — refine the intent into an immutable Gherkin contract (SHA-256 frozen), implement under the three laws of TDD, pass a judge audit, and merge only if every mutant dies.
 ---
 
 # spec-mutation
@@ -40,7 +40,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:spec-mutation`
+4. Next command spelling on this runner: `$cc-spec-mutation`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -103,7 +103,7 @@ aborts the pipeline with scorecard 0 (Specification Gaming).
 
 ## Stage 3 — TDD under the three laws (`tdd_craftsman`)
 
-Delegates to the `/cc:tdd-cycle` state machine (`tddCycleStateMachine` in
+Delegates to the `$cc-tdd-cycle` state machine (`tddCycleStateMachine` in
 `domain/loop`). Evidence must be captured with `captureTddSuiteEvidence` — do
 not hand-edit JSON under `.codeconductor/evidence/`.
 
@@ -190,3 +190,7 @@ The orchestrator keeps a persistent counter per Task Card. If the
 - [ ] Judge verdict PASS (compile clean, traceability complete, scope clean).
 - [ ] Mutation runner exits 0 with `total_mutants_killed == total_points`.
 - [ ] Scorecard records the kill rate and iteration count (≤ 3).
+
+## Next
+
+Run `$cc-review` on the diff before merging.

package/presets/codex/skills/cc-tdd-cycle/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-tdd-cycle
-description: test first, implement the minimum code to pass it, then refactor with the suite green.
+description: Run a structured Red-Green-Refactor TDD cycle — write a failing test first, implement the minimum code to pass it, then refactor with the suite green.
 ---
 
 # tdd-cycle
@@ -40,7 +40,7 @@ If `openspec status` reports an active change folder:
 1. Run: `npx cc-codeconductor openspec validate --output json`
 2. Run: `npx cc-codeconductor openspec analyze --output json`
 3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
-4. Next command spelling on this runner: `/cc:tdd-cycle`
+4. Next command spelling on this runner: `$cc-tdd-cycle`
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
@@ -74,7 +74,7 @@ Do not advance phases until that evidence exists.
 
 ## Phase 1 — RED (Tester role)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `AGENTS.md`.
 
 ### 1a — Scope clarification
 
@@ -130,7 +130,7 @@ confirmation.**
 
 ## Phase 2 — GREEN (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 ### 2a — Read the failing test before writing any code
 
@@ -177,7 +177,7 @@ confirmation.**
 
 ## Phase 3 — REFACTOR (Implementer role, then Reviewer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `AGENTS.md`.
 
 ### 3a — Assess what needs cleaning
 
@@ -208,7 +208,7 @@ change and investigate.
 
 ### 3d — Review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `AGENTS.md`.
 
 Review only the refactored code against these axes: