cc-codeconductor 1.2.0 → 1.4.0

package/presets/codex/skills/android-ui-design/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: android-ui-design
+description: >-
+  Design, implement, review, and audit Android Jetpack Compose UI/UX for phone
+  interfaces. Use when a request concerns concrete Compose layout, components,
+  interaction, accessibility, or visual behavior. Do not activate for framework
+  or dependency presence alone; non-UI Android work is excluded.
+---
+
+# Android UI design
+
+Apply this specialized guidance to Android phone interfaces built with Jetpack
+Compose. Keep the active `cc-feature`, `cc-fix`, `cc-review`, or `cc-openspec`
+workflow and its gates; this skill contributes UI/UX criteria, not a separate
+workflow. Use the general `android` skill for architecture, dependency injection,
+Media3, performance, testing, and other non-UI Android engineering.
+
+## Intake and boundaries
+
+Identify the user goal, phone surface, affected interaction, supported Android
+versions, and observable outcomes. Inspect the existing Compose components,
+design tokens, navigation conventions, installed versions, tests, previews, and
+available emulator or device tooling before proposing changes.
+
+Preserve the established product visual system, including its components, color,
+type, shape, spacing, and motion tokens. Material 3 is advisory guidance, not a
+mandate to replace a deliberate product language. Suggest Material 3 changes with
+their accessibility or usability benefit and wait for scope approval when they
+would alter the visual direction.
+
+The initial scope is phones. Do not invent tablet, foldable, desktop, or wearable
+layouts. Still account for phone portrait and landscape orientation, window size
+changes, display cutouts, system bars, and the soft keyboard or IME.
+
+## Design mode
+
+Turn the request into a small interaction contract before implementation:
+
+- Define hierarchy, content, spacing, phone layout, scroll and overflow behavior,
+  navigation, focus entry and return, gestures, and predictive back behavior.
+- Specify applicable default, pressed, focused, disabled, pending or loading,
+  empty, success, error or failure, and offline states. State what changes and
+  what the user can do next; never imply success before it is known.
+- Name the state owner. Prefer state hoisting, a single source of truth, and
+  unidirectional data flow (UDF); keep transient visual state local only when no
+  external owner needs to observe or control it.
+- Design edge-to-edge intentionally with WindowInsets and system bars. Define IME
+  resize, pan, focus, dismissal, and restoration behavior for editable surfaces.
+- Require at least 48dp touch targets, meaningful semantics, TalkBack labels and
+  actions, logical traversal or focus order, sufficient contrast, and usable font
+  scaling without clipped or hidden actions.
+- Add motion only when it has a purpose such as continuity, spatial orientation,
+  feedback, or state change. Define start/end state, interruption, cancellation
+  or reversal, repeated or rapid input, and reduced-motion or reduced-animation
+  behavior that preserves essential information.
+
+Use existing components and platform/Compose primitives before adding code or a
+dependency. When alternatives are requested, compare only scoped options and make
+the product-system and Material 3 tradeoffs explicit.
+
+## Implementation mode
+
+Implement the accepted contract without expanding the visual language. Keep
+composables focused, pass immutable UI state and event callbacks, and preserve
+unidirectional data flow. Hoist state to the lowest common owner that needs to
+read or write it. Do not duplicate navigation, loading, or failure truth across
+the composition.
+
+Prefer semantic Material/Compose controls over raw pointer input. When a custom
+gesture is necessary, preserve accessible actions, minimum touch targets, visual
+feedback, cancellation, and interoperability with scrolling. Consume insets once
+at the correct boundary and verify that edge-to-edge content and IME transitions
+do not obscure controls.
+
+Write tests for observable behavior and state outcomes rather than modifier or
+implementation details. Cover the relevant state transition, duplicate or rapid
+input, disabled behavior, semantics, navigation/back behavior, and state
+restoration. Use previews as design aids, not as proof of runtime interaction.
+
+## Review mode
+
+Review the agreed surface against the interaction contract and existing Review
+Report rules. Each finding needs a location, reproduction or evidence, user
+impact, and proposed resolution. Treat contract and accessibility failures as
+defects; classify unsupported aesthetic preferences as suggestions. Do not create
+a new review axis or elevate a Material 3 preference over the product system.
+
+Check state completeness, TalkBack semantics and traversal, 48dp touch targets,
+contrast and font scaling, focus/IME behavior, edge-to-edge insets, gestures,
+predictive back, orientation changes, state ownership/UDF, motion interruption,
+reduced animation, and rapid repeated interaction as applicable.
+
+## Audit mode
+
+A requested audit is read-only. Inspect only the agreed Compose phone surface and
+report prioritized, evidence-backed findings; an audit is not permission to edit,
+implement, modify, or automatically fix the UI. Keep out-of-scope improvements as
+suggestions and create backlog work only when requested through the existing
+workflow.
+
+Distinguish code inspection, semantics tests, screenshots, and live emulator or
+device interaction because they prove different things. If required visual,
+emulator, or device evidence is unavailable, mark that validation pending with
+the surface, steps, expected result, and limitation. Do not claim visual
+validation or a completed acceptance criterion without executing the check.
+
+## Evidence and delivery
+
+Report the observable outcomes checked, commands or tools used, results, and
+limitations. A screenshot cannot prove TalkBack traversal, gesture interruption,
+IME recovery, predictive back, or repeated-input behavior. Prefer a real phone or
+phone emulator for those checks; otherwise leave precise pending verification.
+
+Primary Android references: [Compose semantics](https://developer.android.com/develop/ui/compose/accessibility/semantics),
+[accessibility defaults](https://developer.android.com/develop/ui/compose/accessibility/api-defaults),
+[state and hoisting](https://developer.android.com/develop/ui/compose/state),
+[window insets](https://developer.android.com/develop/ui/compose/system/insets),
+[predictive back](https://developer.android.com/develop/ui/compose/system/predictive-back),
+and [Compose accessibility testing](https://developer.android.com/develop/ui/compose/accessibility/testing).

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
@@ -13,6 +13,28 @@ 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)
@@ -33,10 +55,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 +77,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 +92,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 +110,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 +123,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 +138,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 +152,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 +178,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
@@ -21,6 +21,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)
@@ -41,7 +63,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 +81,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 +136,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 +147,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 +159,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 +170,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 +185,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
@@ -17,6 +17,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)
@@ -37,7 +59,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`.