cc-codeconductor 1.2.0 → 1.4.0

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

@@ -1,4 +1,4 @@
-description = "CodeConductor handoff workflow"
+description = "Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets)."
 
 prompt = """
 # Handoff Workflow

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

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Advanced Iterative Workflow
@@ -38,7 +38,7 @@ Local development: `bun run dev <same argv>`. Published package: `npx cc-codecon
 
 If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (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 `.gemini/agents/repo-explorer.md`
 with that graph output.
 
 repo-explorer maps directory trees, conventions, god nodes, and affected
@@ -50,7 +50,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 `.gemini/agents/task-coach.md`.
 
 Produce a complete Task Card. The Task Card is ready when it contains: title,
 type, risk classification, scope, context, acceptance criteria, and
@@ -70,7 +70,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 `.gemini/agents/contract-builder.md`, then the `architect` role as defined in `.gemini/agents/architect.md`.
 
 1. Define API contracts, JSON Schemas, or TypeScript interfaces.
 2. Formulate the Technical Plan (chosen approach, affected files, trade-offs).
@@ -83,7 +83,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 `.gemini/agents/tester.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.
@@ -93,7 +93,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 `.gemini/agents/implementer.md`.
 
 Use the approved Technical Plan, contracts, and the failing tests.
 Implementer creates a Git Worktree before touching any file; all edits happen
@@ -126,7 +126,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 `.gemini/agents/docs.md` when a public API, public module,
 or user-visible behavior changed.
 
 Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG

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

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # OpenSpec Backlog Workflow
@@ -11,6 +11,28 @@ Orchestrate FIFO delivery from `BACKLOG.md`. CodeConductor owns planning; agents
 
 ---
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — CCEP Bootstrap
 
 Command: `openspec` (fixed for this workflow — do not infer from user text)

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

@@ -1,4 +1,4 @@
-description = "CodeConductor prototype workflow"
+description = "Disposable spike in an isolated worktree. Not a merge candidate."
 
 prompt = """
 # Prototype Workflow

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

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Refactor Workflow
@@ -44,7 +44,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 `.gemini/agents/architect.md`. Always invoke this step
 first, regardless of risk level. A refactor without a written justification is
 scope creep in disguise.
 
@@ -93,7 +93,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 `.gemini/agents/implementer.md`. Use the approved
 Refactor Plan.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
@@ -133,7 +133,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 `.gemini/agents/reviewer.md`. Use the diff and Refactor
 Plan.
 
 Verify:
@@ -155,4 +155,8 @@ 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/gemini/commands/cc/review.toml

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Code Review Workflow
@@ -14,6 +14,28 @@ Specify what to review. Accepted formats:
 
 ---
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — CCEP Bootstrap
 
 Command: `review` (fixed for this workflow — do not infer from user text)
@@ -52,7 +74,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 `.gemini/agents/reviewer.md`.
 
 Evaluate the diff against the following checklist:
 
@@ -145,6 +167,7 @@ npx cc-codeconductor scorecard regression
 
 Map merge recommendation to scorecard verdict. Record outcome for trend tracking.
 
-Skills: `evaluation`. Handmade TDD JSON is rejected. Run `scorecard suite-run`
-or `scorecard record` before declaring the review closed.
+## Next
+
+Approved: merge. Blocked: return the findings to `/cc:fix` or `/cc:feature`.
 """

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

@@ -1,4 +1,4 @@
-description = "checklist, and aggregate stats."
+description = "Evaluate deliverable quality — scorecard, outcome tracking, regression checklist, and aggregate stats."
 
 prompt = """
 # Scorecard Evaluation Workflow

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

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Defensive Security Workflow
@@ -174,4 +174,8 @@ 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/gemini/commands/cc/spec-mutation.toml

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Spec-Mutation — Hard Spec → TDD → Judge → Mutation Gate
@@ -184,4 +184,8 @@ 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/gemini/commands/cc/tdd-cycle.toml

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # TDD Cycle — Red → Green → Refactor
@@ -68,7 +68,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 `.gemini/agents/tester.md`.
 
 ### 1a — Scope clarification
 
@@ -124,7 +124,7 @@ confirmation.**
 
 ## Phase 2 — GREEN (Implementer role)
 
-Invoke the `implementer` subagent via the Task tool.
+Adopt the `implementer` role as defined in `.gemini/agents/implementer.md`.
 
 ### 2a — Read the failing test before writing any code
 
@@ -171,7 +171,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 `.gemini/agents/implementer.md`.
 
 ### 3a — Assess what needs cleaning
 
@@ -202,7 +202,7 @@ change and investigate.
 
 ### 3d — Review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `.gemini/agents/reviewer.md`.
 
 Review only the refactored code against these axes:
 
@@ -258,7 +258,4 @@ The TDD cycle is complete when:
 
 If the behavior requires additional test cases, start a new `/tdd-cycle` with
 the next scenario. One cycle = one behavior.
-
-Skill: `testing-tdd`. Evidence from the verification runner only — handmade TDD
-JSON is rejected. Optional gate: `bun run dev scorecard suite-run --suite workflow-gates`.
 """

package/presets/gemini/commands/cc/test-plan.toml

@@ -1,4 +1,4 @@
-description = "unit, integration, contract, and edge cases without writing implementation code."
+description = "Generate a structured test plan for a feature or module — covers unit, integration, contract, and edge cases without writing implementation code."
 
 prompt = """
 # Test Plan Workflow
@@ -46,7 +46,7 @@ question and wait for the answer.
 
 ## Step 2 — Test plan generation (Tester role, planning mode)
 
-Invoke the `tester` subagent via the Task tool.
+Adopt the `tester` role as defined in `.gemini/agents/tester.md`.
 
 Produce a test plan document — not test code. The plan will be used as input
 when tests are actually written.
@@ -145,4 +145,8 @@ Deliver the complete Test Plan document. Save it as
 
 This command produces a plan, not test files. No production code and no test
 code is written during this command.
+
+## Next
+
+Implement against this plan with `/cc:tdd-cycle` or `/cc:feature`.
 """

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

@@ -1,4 +1,4 @@
-description = "CodeConductor triage workflow"
+description = "Classify a request into type, risk, and the destination CodeConductor command."
 
 prompt = """
 # Triage Workflow

package/presets/gemini/settings.json

@@ -0,0 +1,3 @@
+{
+  "mcpServers": {}
+}

package/presets/opencode/agents/docs.md

@@ -77,7 +77,7 @@ CHANGELOG is mandatory for every implementation change. No exceptions.
 - `docs/**/*.md` — any markdown documentation file
 - `docs/adr/*.md` — Architecture Decision Records
 - `CHANGELOG.md` — always update for any implementation change
-- `.codeconductor/sessions/handoff.md` — `/cc:handoff` only; gitignored; redact secrets
+- `.codeconductor/sessions/handoff.md` — `/cc-handoff` only; gitignored; redact secrets
 - `openapi.yaml`, `openapi.json`, or any OpenAPI spec file
 - Any `*-api.yaml` or `*-api.json` file
 

package/presets/opencode/agents/reviewer.md

@@ -260,7 +260,7 @@ When the orchestrator requests evaluation, produce scores for all 8 criteria in
 2. Minimal diff (20%)
 3. Tests present and passing (15%)
 4. No regressions (15%)
-5. Code conventions (10%)
+5. Code conventions (5%)
 6. Documentation updated (5%)
 7. Context discipline (5%)
 8. Complexity diffusion / cc-gain (5%)

package/presets/opencode/commands/cc-api-contract.md

@@ -94,3 +94,7 @@ or docs/OpenAPI drift.
 
 Report the final Task Card, Technical Plan, implementation summary, test report,
 review report, docs updated, compatibility impact, and residual risks.
+
+## Next
+
+Run `/cc-review` on the diff before merging.

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

@@ -1,6 +1,6 @@
 ---
 description: >-
-  [cc: alias] Recommend one CodeConductor slash command from a natural-language
+  Recommend one CodeConductor slash command from a natural-language
   problem. Does not start that workflow.
 ---
 
@@ -9,7 +9,7 @@ description: >-
 Problem: $ARGUMENTS
 
 This is a **router**, not a delivery workflow. Recommend exactly one command.
-Do **not** run the recommended `/cc:` command unless the human confirms.
+Do **not** run the recommended `/cc-` command unless the human confirms.
 
 ---
 
@@ -31,13 +31,13 @@ The catalog is only:
 
 | Slash | When |
 | ----- | ---- |
-| `/cc:feature` | new behavior |
-| `/cc:fix` | bug / regression |
-| `/cc:refactor` | structure, no behavior change |
-| `/cc:review` | inspect a diff/PR |
-| `/cc:tdd-cycle` | red → green → refactor |
-| `/cc:backlog` | create or append BACKLOG.md / objectives |
-| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+| `/cc-feature` | new behavior |
+| `/cc-fix` | bug / regression |
+| `/cc-refactor` | structure, no behavior change |
+| `/cc-review` | inspect a diff/PR |
+| `/cc-tdd-cycle` | red → green → refactor |
+| `/cc-backlog` | create or append BACKLOG.md / objectives |
+| `/cc-openspec` | BACKLOG / BC-xxx delivery |
 
 If the CLI is unavailable, apply the same catalog and the same priority:
 backlog (author) vs openspec (deliver) → tdd-cycle → review → refactor → fix → feature (default).
@@ -53,4 +53,4 @@ Print:
 
 **STOP.** Wait for the human. Do not invoke the recommended workflow.
 
-For a full preset inventory (skills, commands on disk), use `/cc:help` / `cc-help`.
+For a full preset inventory (skills, commands on disk), use `/cc-help` / `cc-help`.

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

@@ -85,3 +85,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/opencode/commands/cc-db-migration.md

@@ -94,3 +94,7 @@ undocumented deployment sequencing, or model/migration drift.
 
 Report migration files changed, model files changed, tests run, lock risk, data
 risk, operational sequencing, rollback/forward-fix notes, and residual risk.
+
+## Next
+
+Run `/cc-review` on the diff before merging.

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

@@ -26,10 +26,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/opencode/commands/cc-feature.md

@@ -8,6 +8,28 @@ description:
 
 Feature request: $ARGUMENTS
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — CCEP Bootstrap
 
 Command: `feature` (fixed for this workflow — do not infer from user text)
@@ -152,3 +174,7 @@ Report the following to the human:
 
 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/opencode/commands/cc-fix.md

@@ -18,6 +18,28 @@ Provide the following information in $ARGUMENTS:
 
 ---
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — CCEP Bootstrap
 
 Command: `fix` (fixed for this workflow — do not infer from user text)
@@ -165,3 +187,7 @@ 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/opencode/commands/cc-handoff.md

@@ -29,7 +29,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/opencode/commands/cc-openspec.md

@@ -10,6 +10,28 @@ Scope: $ARGUMENTS
 
 ---
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — Validate (mandatory gate)
 
 Run `npx cc-codeconductor openspec validate`. If invalid, show errors and recommendations, then **STOP**.

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

@@ -34,4 +34,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/opencode/commands/cc-refactor.md

@@ -28,7 +28,7 @@ behavioral consequences.
 If coverage is insufficient:
 
 1. **STOP**. Report the coverage gap to the human.
-2. Suggest invoking `/cc:test-plan` first to establish coverage.
+2. Suggest invoking `/cc-test-plan` first to establish coverage.
 3. Do not proceed with the refactor until coverage is confirmed.
 
 ---
@@ -158,3 +158,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/opencode/commands/cc-review.md

@@ -17,6 +17,28 @@ Specify what to review. Accepted formats:
 
 ---
 
+## Web interface scope
+
+When the task concerns web layout, component states, feedback, motion, or a
+requested UI audit, apply skill `web-design-engineering` from the installed skill
+library. Use it during intake/discovery, design, test/implement, and review as
+applicable; keep this workflow’s gates and TDD order. Framework presence alone
+does not activate it; backend-only and native mobile work are excluded. Record
+required visual checks as pending when unavailable. Keep findings in the existing
+Review Report: contract failures in Spec Axis, technical issues in existing
+subchecks, and aesthetic preferences as suggestions; do not add an axis.
+
+## Android phone interface scope
+
+When the task concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design`. Use it during design, test/implementation, and review as
+applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
+framework, or dependency presence alone does not activate it; non-UI Android work
+stays with the general `android` skill. Audit-only requests remain read-only, and
+unavailable visual or emulator checks remain pending rather than claimed complete.
+
+
 ## Step 0 — CCEP Bootstrap
 
 Command: `review` (fixed for this workflow — do not infer from user text)
@@ -137,7 +159,7 @@ If any CRITICAL findings exist:
 - The Review Report status is **BLOCKED**
 - Report all CRITICAL findings to the human
 - Do not proceed until each CRITICAL finding is resolved
-- After resolution, invoke `/cc:review` again on the same target
+- After resolution, invoke `/cc-review` again on the same target
 
 If no CRITICAL findings exist:
 
@@ -151,3 +173,7 @@ If no CRITICAL findings exist:
 
 Deliver the complete Review Report. Never summarize or omit findings. Every
 finding must include a location and an actionable description.
+
+## Next
+
+Approved: merge. Blocked: return the findings to `/cc-fix` or `/cc-feature`.

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

@@ -177,3 +177,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/opencode/commands/cc-spec-mutation.md

@@ -188,3 +188,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/opencode/commands/cc-tdd-cycle.md

@@ -259,5 +259,5 @@ The TDD cycle is complete when:
 **Cycle status**: complete | blocked (reason)
 ```
 
-If the behavior requires additional test cases, start a new `/cc:tdd-cycle` with
+If the behavior requires additional test cases, start a new `/cc-tdd-cycle` with
 the next scenario. One cycle = one behavior.