cc-codeconductor 1.3.0 → 1.4.1

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)

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)

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-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)

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

@@ -35,6 +35,10 @@ quality:
 
 This playbook defines the architecture, UI design system, performance guidelines, and testing strategy for native Android applications.
 
+`android-ui-design` owns specialized Jetpack Compose phone UI/UX design,
+implementation, review, and audit guidance. This skill remains the general guide
+for architecture, Hilt dependency injection, Media3, performance, and testing.
+
 ---
 
 ## 1. Lead Architect & Modularization

package/presets/opencode/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/opencode/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/opencode/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/opencode/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/src/presets/shared-skills.yml

@@ -56,9 +56,13 @@ skills:
     targets: [claude, codex, cursor, opencode, agy]
   - name: workflow-orchestration-patterns
     targets: [claude, codex, cursor, opencode]
+  - name: android-ui-design
+    targets: [claude, codex, cursor, opencode, agy]
   - name: code-review
     targets: [cursor, opencode]
   - name: seo-analytics-injector
     targets: [cursor, opencode]
   - name: tdd-mutation-tester
     targets: [cursor, opencode]
+  - name: web-design-engineering
+    targets: [claude, codex, cursor, opencode, agy]