cc-codeconductor 1.2.0 → 1.4.0

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

@@ -42,6 +42,26 @@ Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW`
 → Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
 `IN_PROGRESS`.
 
+## 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 an item concerns concrete Jetpack Compose phone layout, component states,
+interaction, accessibility, visual behavior, or a requested UI audit, apply skill
+`android-ui-design` throughout discover, design, test/implement, and review. Keep
+OpenSpec gates and TDD order. Kotlin, Compose, framework, or dependency presence
+alone does not activate it; non-UI Android work stays with `android`. Keep audit-only
+delivery read-only and record unavailable visual or emulator evidence as pending.
+
 ## Common Rationalizations
 
 | Rationalization | Reality |

package/presets/cursor/skills/pagespeed-perf/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: pagespeed-perf
-version: 1.0.0
 name: PageSpeed Performance Audit
 description: >
   Web Performance Engineering — analyzes Core Web Vitals using the PageSpeed
@@ -32,7 +31,7 @@ inputs:
   - name: url
     type: string
     required: true
-    description: Full URL to audit (must include scheme: https://...)
+    description: "Full URL to audit (must include scheme: https://...)"
   - name: strategy
     type: string
     required: false

package/presets/cursor/skills/python/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: python
-version: 1.0.0
 name: Python
 description: >
   Python development best practices: clean code, patterns,

package/presets/cursor/skills/python-django-stack/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: python-django-stack
-version: 1.0.0
 name: Python Django Stack
 description: >
   Python and Django conventions for multi-tenant SaaS POS projects:

package/presets/cursor/skills/python-fastapi-stack/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: python-fastapi-stack
-version: 1.0.0
 name: Python FastAPI Stack
 description: >
   FastAPI conventions for REST APIs: routers, Pydantic v2 schemas, dependency

package/presets/cursor/skills/security/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: security
-version: 1.0.0
 name: Security
 description: >
   Provides expert knowledge for implementing and reviewing application security following OWASP Top 10 (2021), with stack-specific patterns for Spring Boot, Django, Next.js, and Astro.

package/presets/cursor/skills/seo-analytics-injector/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: seo-analytics-injector
-version: 1.0.0
 name: SEO Analytics Injector
 description: >
   Verifies and injects Google Tag Manager (GTM), GA4 event triggers, and optimized meta tags.

package/presets/cursor/skills/spring-auth-auditor/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: spring-auth-auditor
-version: 1.0.0
 name: Spring Auth Auditor
 description: >
   Secures Spring Security filters, JWT validations, OAuth2 setups, and CORS/CSRF headers.

package/presets/cursor/skills/spring-boot-feature/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: spring-boot-feature
-version: 1.0.0
 name: Spring Boot Feature Creation
 description: >
   Guides the creation of complete Spring Boot features following a structured,

package/presets/cursor/skills/spring-boot-kotlin/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: spring-boot-kotlin
-version: 1.0.0
 name: Spring Boot + Kotlin
 description: >
   Provides expert knowledge of Spring Boot conventions, Kotlin idioms, and MVC

package/presets/cursor/skills/spring-boot-testing-strategy/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: spring-boot-testing-strategy
-version: 1.0.0
 name: Spring Boot Testing Strategy
 description: >
   Provides expert knowledge of the testing pyramid, test design principles, MockK patterns, and integration testing conventions for Spring Boot + Kotlin projects.

package/presets/cursor/skills/sqlalchemy/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: sqlalchemy
-version: 1.0.0
 name: SQLAlchemy
 description: >
   SQLAlchemy 2.x patterns for async FastAPI projects: models, sessions, queries,

package/presets/cursor/skills/tailwind-responsive-auditor/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: tailwind-responsive-auditor
-version: 1.0.0
 name: Tailwind Responsive Auditor
 description: >
   Audits Tailwind CSS usage ensuring mobile-first responsive utilities and clean classes.

package/presets/cursor/skills/tdd-mutation-tester/SKILL.md

@@ -1,6 +1,5 @@
 ---
 id: tdd-mutation-tester
-version: 1.0.0
 name: TDD Mutation Tester
 description: >
   Performs simple mutation testing to verify test coverage and assertions.

package/presets/cursor/skills/using-cc-skills/SKILL.md

@@ -31,6 +31,27 @@ a parallel process.
 Then run the matching CLI (`openspec validate`, `scorecard create --from-diff`,
 `hook pre-tool`, `scorecard suite-run`).
 
+## 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 preserving the current workflow gates. 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 as complete.
+
 ## Common Rationalizations
 
 | Rationalization | Reality |

package/presets/cursor/skills/web-design-engineering/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: web-design-engineering
+description: >-
+  Design, implement, and review web interface layout, component states, feedback,
+  and motion within the current CodeConductor workflow. Use for concrete web UI
+  work or requested UI audits, not backend-only tasks or native mobile apps.
+---
+
+# Web design engineering
+
+Apply this guidance to the web surface in scope. A React or Tailwind dependency
+alone is not a trigger. Keep the existing feature, fix, review, or OpenSpec flow;
+this skill adds contextual criteria, not commands, agents, gates, or score weights.
+
+## Intake and discovery
+
+Translate vague requests into observable behavior: “responsive feedback” might
+mean showing a pending state immediately after submit while preventing duplicate
+submissions. Identify the user objective, affected surface, relevant states, and
+acceptance checks in the Task Card. Ask only about ambiguities that affect scope.
+
+Inspect existing components, design tokens, documented visual decisions, installed
+dependencies and versions, and available browser, component-preview, and test tools.
+Reuse the product's visual language and accessible components. Consult official
+documentation for the installed version when an API is uncertain. Prefer existing
+capabilities and browser primitives; a small transition does not justify a library.
+
+## Design and implementation
+
+Record relevant decisions in the Technical Plan or OpenSpec design.md:
+
+- For static UI: hierarchy, readable content, spacing, responsive layout, overflow,
+  semantics, contrast, and focus visibility. Do not invent motion to fill a checklist.
+- For interactive components: default, pending, success, failure, disabled, and
+  empty states as applicable; pointer, touch, keyboard, focus entry and return.
+  Acknowledge input promptly without implying success before it is known.
+- If motion serves the task, name its purpose and weigh frequency, waiting cost,
+  and context. Specify start/end states, exit, rapid repeated input, cancellation
+  or reversal, and reduced-motion behavior that preserves essential information.
+  Use continuity or direct manipulation when it helps users understand the action.
+- Reuse motion tokens. Choose properties and tools appropriate to the component;
+  inspect layout/paint cost when relevant instead of assuming smoothness from code.
+  No duration, easing curve, animation technique, or visual style is universally
+  forbidden. Explain tradeoffs against the contract and product conventions.
+- When alternatives are explicitly requested, compare scoped options and their
+  tradeoffs before choosing. Do not build a variant selector or prototype framework.
+
+Agree checks before implementation. Preserve the workflow's test-before-implement
+order and use its evidence mechanism when required. Test observable state changes
+and interaction outcomes, not just CSS strings. Implement only the accepted scope.
+Tailwind skills own responsive conventions; framework skills own implementation;
+PageSpeed owns performance measurement; evaluation owns the scorecard.
+
+## Review and delivery
+
+Use the existing Review Report and its severity/verdict rules. Map contract failures
+to Spec Axis and technical issues to existing subchecks such as Correctness,
+Architecture alignment, Performance, or Test coverage. Preserve Standards Axis;
+do not add a design axis or rerank the two axes. Ground each finding in a location,
+reproduction or evidence, user impact, and a proposed resolution. Aesthetic
+preferences alone are suggestions, not blocking defects. Respect documented
+product choices unless evidence demonstrates a contract or technical failure.
+
+For a requested audit, inspect only the agreed surface and prioritize findings by
+impact and evidence. Report out-of-scope opportunities as suggestions. Create
+backlog items through the existing cc-backlog workflow only when requested; deliver
+those items later through OpenSpec. An audit is not permission to implement fixes.
+
+Report checks actually performed, their results, and limitations. Code inspection,
+DOM tests, screenshots, and live interaction checks establish different evidence.
+A screenshot cannot prove interruption or keyboard behavior. If a required visual
+or interaction check cannot run, mark it pending with the surface, steps, expected
+result, and missing tool/environment. Do not claim visual validation from code or
+mark the unmet acceptance criterion complete.
+
+## Example acceptance
+
+For a dismissible web dialog using existing tokens: opening from the keyboard
+places focus inside; Escape during entry closes it without reopening on a stale
+completion callback and returns focus to its trigger. With reduced motion enabled,
+the same actions work without the spatial transition. Check rapid open/close in
+the browser and record the result; if unavailable, keep that check pending.
+For a static pricing page, verify content hierarchy and no horizontal overflow at
+the agreed viewports; no animation is required.
+
+## Provenance and boundaries
+
+Original CodeConductor adaptation informed by Emil Kowalski's
+[design engineering](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md),
+[animation construction](https://github.com/emilkowalski/skills/blob/main/skills/animate/SKILL.md),
+and [interaction principles](https://github.com/emilkowalski/skills/blob/main/skills/apple-design/SKILL.md).
+Additional references: [review](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md),
+[audits](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/SKILL.md),
+[opportunities](https://github.com/emilkowalski/skills/blob/main/skills/find-animation-opportunities/SKILL.md),
+[vocabulary](https://github.com/emilkowalski/skills/blob/main/skills/animation-vocabulary/SKILL.md),
+[library selection](https://github.com/emilkowalski/skills/blob/main/skills/pick-ui-library/SKILL.md),
+[component guidance](https://github.com/emilkowalski/skills/blob/main/skills/ask-sonner/SKILL.md),
+and [alternatives](https://github.com/emilkowalski/skills/blob/main/skills/prototype/SKILL.md).
+These are provenance, not runtime prerequisites. This skill does not install or
+synchronize upstream skills, adopt promotional responses or mandatory author
+formats, prescribe an Apple identity, or cover Expo/Swift native development.

package/presets/gemini/GEMINI.md

@@ -0,0 +1,38 @@
+<!-- CODECONDUCTOR:BEGIN managed -->
+
+# CodeConductor — Gemini CLI Preset
+
+This file configures CodeConductor for **Gemini CLI**. It lives at the project
+root (`GEMINI.md`) so Gemini CLI's hierarchical context loader picks it up
+from the current directory and every ancestor up to the project root.
+
+## 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 slash commands as native Gemini CLI TOML commands
+under `.gemini/commands/cc/`, 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 `.gemini/skills/` (Gemini CLI's native Agent Skills
+discovery path, shared with `.agents/skills/` per the Agent Skills open
+standard). Read `.gemini/skills/using-cc-skills/SKILL.md` first — it maps
+intent to the right slash command.
+
+## 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 Gemini CLI.
+
+<!-- CODECONDUCTOR:END managed -->

package/presets/gemini/commands/cc/api-contract.toml

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # API Contract Workflow
@@ -33,7 +33,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 `.gemini/agents/task-coach.md`.
 
 The Task Card must classify the task as high risk by default and include the
 affected public interface, request/response examples, compatibility notes,
@@ -46,7 +46,7 @@ criteria.
 
 ## Step 2 — Technical Plan (Architect role)
 
-Invoke the `architect` subagent via the Task tool.
+Adopt the `architect` role as defined in `.gemini/agents/architect.md`.
 
 Define the API contract, validation strategy, compatibility behavior, docs or
 OpenAPI changes, and reviewer blocking conditions.
@@ -57,7 +57,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 `.gemini/agents/implementer.md`.
 
 Apply the minimal diff, preserve compatible behavior unless explicitly approved
 as breaking, and update only the planned files.
@@ -66,7 +66,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 `.gemini/agents/tester.md`.
 
 Add or update tests for request shape, response shape, status/error behavior,
 and backward compatibility.
@@ -75,8 +75,12 @@ and backward compatibility.
 
 ## Step 5 — Review (Reviewer role)
 
-Invoke the `reviewer` subagent via the Task tool.
+Adopt the `reviewer` role as defined in `.gemini/agents/reviewer.md`.
 
 Block on missing contract tests, undocumented breaking changes, or docs/OpenAPI
 drift.
+
+## Next
+
+Run `/cc:review` on the diff before merging.
 """

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

@@ -1,4 +1,4 @@
-description = "[cc: alias] Recommend one CodeConductor slash command from a natural-language problem. Does not start that workflow."
+description = "Recommend one CodeConductor slash command from a natural-language problem. Does not start that workflow."
 
 prompt = """
 # Ask — recommend a slash command

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

@@ -1,4 +1,4 @@
-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."
 
 prompt = """
 # Backlog Authoring Workflow

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

@@ -1,4 +1,4 @@
-description = "CodeConductor clarify workflow"
+description = "Re-explain the last deliverable in Task Card vocabulary when it did not land."
 
 prompt = """
 # Clarify Workflow

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

@@ -84,4 +84,8 @@ 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/gemini/commands/cc/db-migration.toml

@@ -1,4 +1,4 @@
-description = "operational sequencing, tests, and review."
+description = "Run the database migration workflow for schema/data changes, operational sequencing, tests, and review."
 
 prompt = """
 # Database Migration Workflow
@@ -34,7 +34,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 `.gemini/agents/task-coach.md`.
 
 The Task Card must classify the task as high risk and include affected schema,
 model, and migration files; data backfill needs; deployment ordering;
@@ -46,7 +46,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 `.gemini/agents/architect.md`.
 
 Define the schema/data plan, operational sequencing, compatibility strategy,
 rollback/forward-fix notes, and test approach.
@@ -57,7 +57,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 `.gemini/agents/tester.md`.
 
 Cover migration-sensitive behavior where the stack supports it, including
 existing-data edge cases and rollback/forward-fix notes when automated rollback
@@ -67,7 +67,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 `.gemini/agents/implementer.md`.
 
 Keep model and migration changes together, avoid unrelated refactors, and
 preserve the deployment order specified by architect.
@@ -76,8 +76,12 @@ 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 `.gemini/agents/reviewer.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/gemini/commands/cc/explore.toml

@@ -1,4 +1,4 @@
-description = "CodeConductor explore workflow"
+description = "Map the repository and recommend the next CodeConductor slash command. Read-only."
 
 prompt = """
 # Explore Workflow

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

@@ -1,4 +1,4 @@
-description = "implementation, testing, review, and documentation."
+description = "Run the full feature workflow — task validation, technical design, implementation, testing, review, and documentation."
 
 prompt = """
 # Feature Workflow
@@ -7,6 +7,28 @@ Feature request: {{args}}
 
 ---
 
+## 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)
@@ -49,7 +71,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 `.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 constraints.
@@ -64,7 +86,7 @@ continuing.**
 
 ## Step 3 — Technical Plan (Architect role)
 
-Invoke the `architect` subagent via the Task tool.
+Adopt the `architect` role as defined in `.gemini/agents/architect.md`.
 
 Produce a Technical Plan that covers:
 
@@ -82,7 +104,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 `.gemini/agents/tester.md`.
 
 Use the Implementation Summary and the Task Card.
 
@@ -95,7 +117,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 `.gemini/agents/implementer.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.
@@ -110,7 +132,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 `.gemini/agents/reviewer.md`.
 
 Use the complete diff and the Task Card.
 
@@ -124,7 +146,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 `.gemini/agents/docs.md`.
 
 Invoke this step only if any of the following changed:
 
@@ -150,4 +172,8 @@ 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/gemini/commands/cc/fix.toml

@@ -1,4 +1,4 @@
-description = "validation, implementation, testing, and optional review."
+description = "Run the bug fix workflow — risk-based routing through task validation, implementation, testing, and optional review."
 
 prompt = """
 # Bug Fix Workflow
@@ -15,6 +15,28 @@ Provide the following information in {{args}}:
 
 ---
 
+## 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)
@@ -39,9 +61,6 @@ If `openspec status` reports an active change folder:
 
 Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
 
-Skills: `testing-tdd`, `evaluation`. Record `scorecard create --from-diff`.
-A small fix still needs a Task Card and a failing regression test first.
-
 ---
 
 
@@ -56,7 +75,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 `.gemini/agents/task-coach.md`.
 
 Produce a Task Card that includes:
 
@@ -111,7 +130,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 `.gemini/agents/tester.md`. Apply for all risk levels.
 
 1. Write a regression test that reproduces the original bug and confirm it fails
    before any fix (RED).
@@ -122,7 +141,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 `.gemini/agents/implementer.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.
@@ -134,7 +153,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 `.gemini/agents/implementer.md`. Use the approved
 Technical Plan and the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
@@ -145,7 +164,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 `.gemini/agents/reviewer.md`. Use the diff and Task
 Card.
 
 Produce a Review Report with CRITICAL / WARNING / SUGGESTION findings. If any
@@ -160,4 +179,11 @@ 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.
 """