cc-codeconductor 1.3.0 → 1.4.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +21 -16
- package/dist/index.js +7240 -6446
- package/dist/library.js +196 -164
- package/dist/utils/cli-bin.d.ts +16 -0
- package/docs/generated/cli.md +202 -0
- package/package.json +3 -1
- package/presets/agy/skills/android-ui-design/SKILL.md +119 -0
- package/presets/agy/skills/cc-feature/SKILL.md +22 -0
- package/presets/agy/skills/cc-fix/SKILL.md +22 -0
- package/presets/agy/skills/cc-review/SKILL.md +22 -0
- package/presets/agy/skills/openspec/SKILL.md +20 -0
- package/presets/agy/skills/using-cc-skills/SKILL.md +21 -0
- package/presets/agy/skills/web-design-engineering/SKILL.md +101 -0
- package/presets/agy/workflows/cc-feature.md +22 -0
- package/presets/agy/workflows/cc-fix.md +22 -0
- package/presets/agy/workflows/cc-openspec.md +22 -0
- package/presets/agy/workflows/cc-review.md +22 -0
- package/presets/claude/commands/cc/feature.md +22 -0
- package/presets/claude/commands/cc/fix.md +22 -0
- package/presets/claude/commands/cc/openspec.md +22 -0
- package/presets/claude/commands/cc/review.md +22 -0
- package/presets/claude/skills/android/SKILL.md +4 -0
- package/presets/claude/skills/android-ui-design/SKILL.md +119 -0
- package/presets/claude/skills/openspec/SKILL.md +20 -0
- package/presets/claude/skills/using-cc-skills/SKILL.md +21 -0
- package/presets/claude/skills/web-design-engineering/SKILL.md +101 -0
- package/presets/codex/skills/android/SKILL.md +4 -0
- package/presets/codex/skills/android-ui-design/SKILL.md +119 -0
- package/presets/codex/skills/cc-feature/SKILL.md +22 -0
- package/presets/codex/skills/cc-fix/SKILL.md +22 -0
- package/presets/codex/skills/cc-openspec/SKILL.md +22 -0
- package/presets/codex/skills/cc-review/SKILL.md +22 -0
- package/presets/codex/skills/openspec/SKILL.md +20 -0
- package/presets/codex/skills/using-cc-skills/SKILL.md +21 -0
- package/presets/codex/skills/web-design-engineering/SKILL.md +101 -0
- package/presets/cursor/commands/cc/feature.md +22 -0
- package/presets/cursor/commands/cc/fix.md +22 -0
- package/presets/cursor/commands/cc/openspec.md +22 -0
- package/presets/cursor/commands/cc/review.md +22 -0
- package/presets/cursor/skills/android/SKILL.md +4 -0
- package/presets/cursor/skills/android-ui-design/SKILL.md +119 -0
- package/presets/cursor/skills/openspec/SKILL.md +20 -0
- package/presets/cursor/skills/using-cc-skills/SKILL.md +21 -0
- package/presets/cursor/skills/web-design-engineering/SKILL.md +101 -0
- package/presets/gemini/commands/cc/feature.toml +22 -0
- package/presets/gemini/commands/cc/fix.toml +22 -0
- package/presets/gemini/commands/cc/openspec.toml +22 -0
- package/presets/gemini/commands/cc/review.toml +22 -0
- package/presets/opencode/commands/cc-feature.md +22 -0
- package/presets/opencode/commands/cc-fix.md +22 -0
- package/presets/opencode/commands/cc-openspec.md +22 -0
- package/presets/opencode/commands/cc-review.md +22 -0
- package/presets/opencode/skills/android/SKILL.md +4 -0
- package/presets/opencode/skills/android-ui-design/SKILL.md +119 -0
- package/presets/opencode/skills/openspec/SKILL.md +20 -0
- package/presets/opencode/skills/using-cc-skills/SKILL.md +21 -0
- package/presets/opencode/skills/web-design-engineering/SKILL.md +101 -0
- package/src/presets/shared-skills.yml +4 -0
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: android-ui-design
|
|
3
|
+
description: >-
|
|
4
|
+
Design, implement, review, and audit Android Jetpack Compose UI/UX for phone
|
|
5
|
+
interfaces. Use when a request concerns concrete Compose layout, components,
|
|
6
|
+
interaction, accessibility, or visual behavior. Do not activate for framework
|
|
7
|
+
or dependency presence alone; non-UI Android work is excluded.
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Android UI design
|
|
11
|
+
|
|
12
|
+
Apply this specialized guidance to Android phone interfaces built with Jetpack
|
|
13
|
+
Compose. Keep the active `cc-feature`, `cc-fix`, `cc-review`, or `cc-openspec`
|
|
14
|
+
workflow and its gates; this skill contributes UI/UX criteria, not a separate
|
|
15
|
+
workflow. Use the general `android` skill for architecture, dependency injection,
|
|
16
|
+
Media3, performance, testing, and other non-UI Android engineering.
|
|
17
|
+
|
|
18
|
+
## Intake and boundaries
|
|
19
|
+
|
|
20
|
+
Identify the user goal, phone surface, affected interaction, supported Android
|
|
21
|
+
versions, and observable outcomes. Inspect the existing Compose components,
|
|
22
|
+
design tokens, navigation conventions, installed versions, tests, previews, and
|
|
23
|
+
available emulator or device tooling before proposing changes.
|
|
24
|
+
|
|
25
|
+
Preserve the established product visual system, including its components, color,
|
|
26
|
+
type, shape, spacing, and motion tokens. Material 3 is advisory guidance, not a
|
|
27
|
+
mandate to replace a deliberate product language. Suggest Material 3 changes with
|
|
28
|
+
their accessibility or usability benefit and wait for scope approval when they
|
|
29
|
+
would alter the visual direction.
|
|
30
|
+
|
|
31
|
+
The initial scope is phones. Do not invent tablet, foldable, desktop, or wearable
|
|
32
|
+
layouts. Still account for phone portrait and landscape orientation, window size
|
|
33
|
+
changes, display cutouts, system bars, and the soft keyboard or IME.
|
|
34
|
+
|
|
35
|
+
## Design mode
|
|
36
|
+
|
|
37
|
+
Turn the request into a small interaction contract before implementation:
|
|
38
|
+
|
|
39
|
+
- Define hierarchy, content, spacing, phone layout, scroll and overflow behavior,
|
|
40
|
+
navigation, focus entry and return, gestures, and predictive back behavior.
|
|
41
|
+
- Specify applicable default, pressed, focused, disabled, pending or loading,
|
|
42
|
+
empty, success, error or failure, and offline states. State what changes and
|
|
43
|
+
what the user can do next; never imply success before it is known.
|
|
44
|
+
- Name the state owner. Prefer state hoisting, a single source of truth, and
|
|
45
|
+
unidirectional data flow (UDF); keep transient visual state local only when no
|
|
46
|
+
external owner needs to observe or control it.
|
|
47
|
+
- Design edge-to-edge intentionally with WindowInsets and system bars. Define IME
|
|
48
|
+
resize, pan, focus, dismissal, and restoration behavior for editable surfaces.
|
|
49
|
+
- Require at least 48dp touch targets, meaningful semantics, TalkBack labels and
|
|
50
|
+
actions, logical traversal or focus order, sufficient contrast, and usable font
|
|
51
|
+
scaling without clipped or hidden actions.
|
|
52
|
+
- Add motion only when it has a purpose such as continuity, spatial orientation,
|
|
53
|
+
feedback, or state change. Define start/end state, interruption, cancellation
|
|
54
|
+
or reversal, repeated or rapid input, and reduced-motion or reduced-animation
|
|
55
|
+
behavior that preserves essential information.
|
|
56
|
+
|
|
57
|
+
Use existing components and platform/Compose primitives before adding code or a
|
|
58
|
+
dependency. When alternatives are requested, compare only scoped options and make
|
|
59
|
+
the product-system and Material 3 tradeoffs explicit.
|
|
60
|
+
|
|
61
|
+
## Implementation mode
|
|
62
|
+
|
|
63
|
+
Implement the accepted contract without expanding the visual language. Keep
|
|
64
|
+
composables focused, pass immutable UI state and event callbacks, and preserve
|
|
65
|
+
unidirectional data flow. Hoist state to the lowest common owner that needs to
|
|
66
|
+
read or write it. Do not duplicate navigation, loading, or failure truth across
|
|
67
|
+
the composition.
|
|
68
|
+
|
|
69
|
+
Prefer semantic Material/Compose controls over raw pointer input. When a custom
|
|
70
|
+
gesture is necessary, preserve accessible actions, minimum touch targets, visual
|
|
71
|
+
feedback, cancellation, and interoperability with scrolling. Consume insets once
|
|
72
|
+
at the correct boundary and verify that edge-to-edge content and IME transitions
|
|
73
|
+
do not obscure controls.
|
|
74
|
+
|
|
75
|
+
Write tests for observable behavior and state outcomes rather than modifier or
|
|
76
|
+
implementation details. Cover the relevant state transition, duplicate or rapid
|
|
77
|
+
input, disabled behavior, semantics, navigation/back behavior, and state
|
|
78
|
+
restoration. Use previews as design aids, not as proof of runtime interaction.
|
|
79
|
+
|
|
80
|
+
## Review mode
|
|
81
|
+
|
|
82
|
+
Review the agreed surface against the interaction contract and existing Review
|
|
83
|
+
Report rules. Each finding needs a location, reproduction or evidence, user
|
|
84
|
+
impact, and proposed resolution. Treat contract and accessibility failures as
|
|
85
|
+
defects; classify unsupported aesthetic preferences as suggestions. Do not create
|
|
86
|
+
a new review axis or elevate a Material 3 preference over the product system.
|
|
87
|
+
|
|
88
|
+
Check state completeness, TalkBack semantics and traversal, 48dp touch targets,
|
|
89
|
+
contrast and font scaling, focus/IME behavior, edge-to-edge insets, gestures,
|
|
90
|
+
predictive back, orientation changes, state ownership/UDF, motion interruption,
|
|
91
|
+
reduced animation, and rapid repeated interaction as applicable.
|
|
92
|
+
|
|
93
|
+
## Audit mode
|
|
94
|
+
|
|
95
|
+
A requested audit is read-only. Inspect only the agreed Compose phone surface and
|
|
96
|
+
report prioritized, evidence-backed findings; an audit is not permission to edit,
|
|
97
|
+
implement, modify, or automatically fix the UI. Keep out-of-scope improvements as
|
|
98
|
+
suggestions and create backlog work only when requested through the existing
|
|
99
|
+
workflow.
|
|
100
|
+
|
|
101
|
+
Distinguish code inspection, semantics tests, screenshots, and live emulator or
|
|
102
|
+
device interaction because they prove different things. If required visual,
|
|
103
|
+
emulator, or device evidence is unavailable, mark that validation pending with
|
|
104
|
+
the surface, steps, expected result, and limitation. Do not claim visual
|
|
105
|
+
validation or a completed acceptance criterion without executing the check.
|
|
106
|
+
|
|
107
|
+
## Evidence and delivery
|
|
108
|
+
|
|
109
|
+
Report the observable outcomes checked, commands or tools used, results, and
|
|
110
|
+
limitations. A screenshot cannot prove TalkBack traversal, gesture interruption,
|
|
111
|
+
IME recovery, predictive back, or repeated-input behavior. Prefer a real phone or
|
|
112
|
+
phone emulator for those checks; otherwise leave precise pending verification.
|
|
113
|
+
|
|
114
|
+
Primary Android references: [Compose semantics](https://developer.android.com/develop/ui/compose/accessibility/semantics),
|
|
115
|
+
[accessibility defaults](https://developer.android.com/develop/ui/compose/accessibility/api-defaults),
|
|
116
|
+
[state and hoisting](https://developer.android.com/develop/ui/compose/state),
|
|
117
|
+
[window insets](https://developer.android.com/develop/ui/compose/system/insets),
|
|
118
|
+
[predictive back](https://developer.android.com/develop/ui/compose/system/predictive-back),
|
|
119
|
+
and [Compose accessibility testing](https://developer.android.com/develop/ui/compose/accessibility/testing).
|
|
@@ -9,6 +9,28 @@ description:
|
|
|
9
9
|
|
|
10
10
|
Feature request: $ARGUMENTS
|
|
11
11
|
|
|
12
|
+
## Web interface scope
|
|
13
|
+
|
|
14
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
15
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
16
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
17
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
18
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
19
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
20
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
21
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
22
|
+
|
|
23
|
+
## Android phone interface scope
|
|
24
|
+
|
|
25
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
26
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
27
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
28
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
29
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
30
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
31
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
32
|
+
|
|
33
|
+
|
|
12
34
|
## Step 1 — Task Card validation (task-coach)
|
|
13
35
|
|
|
14
36
|
Invoke `task-coach` with the feature description above.
|
|
@@ -19,6 +19,28 @@ Provide the following information in $ARGUMENTS:
|
|
|
19
19
|
|
|
20
20
|
---
|
|
21
21
|
|
|
22
|
+
## Web interface scope
|
|
23
|
+
|
|
24
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
25
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
26
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
27
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
28
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
29
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
30
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
31
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
32
|
+
|
|
33
|
+
## Android phone interface scope
|
|
34
|
+
|
|
35
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
36
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
37
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
38
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
39
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
40
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
41
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
42
|
+
|
|
43
|
+
|
|
22
44
|
## Step 1 — Task Card validation (task-coach)
|
|
23
45
|
|
|
24
46
|
Invoke `task-coach` with the bug description above.
|
|
@@ -18,6 +18,28 @@ Specify what to review. Accepted formats:
|
|
|
18
18
|
|
|
19
19
|
---
|
|
20
20
|
|
|
21
|
+
## Web interface scope
|
|
22
|
+
|
|
23
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
24
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
25
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
26
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
27
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
28
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
29
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
30
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
31
|
+
|
|
32
|
+
## Android phone interface scope
|
|
33
|
+
|
|
34
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
35
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
36
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
37
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
38
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
39
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
40
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
41
|
+
|
|
42
|
+
|
|
21
43
|
## Step 1 — Diff collection
|
|
22
44
|
|
|
23
45
|
Before invoking `reviewer`, collect the diff for the specified target.
|
|
@@ -42,6 +42,26 @@ Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW`
|
|
|
42
42
|
→ Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
|
|
43
43
|
`IN_PROGRESS`.
|
|
44
44
|
|
|
45
|
+
## Web interface scope
|
|
46
|
+
|
|
47
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
48
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
49
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
50
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
51
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
52
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
53
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
54
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
55
|
+
|
|
56
|
+
## Android phone interface scope
|
|
57
|
+
|
|
58
|
+
When an item concerns concrete Jetpack Compose phone layout, component states,
|
|
59
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
60
|
+
`android-ui-design` throughout discover, design, test/implement, and review. Keep
|
|
61
|
+
OpenSpec gates and TDD order. Kotlin, Compose, framework, or dependency presence
|
|
62
|
+
alone does not activate it; non-UI Android work stays with `android`. Keep audit-only
|
|
63
|
+
delivery read-only and record unavailable visual or emulator evidence as pending.
|
|
64
|
+
|
|
45
65
|
## Common Rationalizations
|
|
46
66
|
|
|
47
67
|
| Rationalization | Reality |
|
|
@@ -31,6 +31,27 @@ a parallel process.
|
|
|
31
31
|
Then run the matching CLI (`openspec validate`, `scorecard create --from-diff`,
|
|
32
32
|
`hook pre-tool`, `scorecard suite-run`).
|
|
33
33
|
|
|
34
|
+
## Web interface scope
|
|
35
|
+
|
|
36
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
37
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
38
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
39
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
40
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
41
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
42
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
43
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
44
|
+
|
|
45
|
+
## Android phone interface scope
|
|
46
|
+
|
|
47
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
48
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
49
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
50
|
+
applicable while preserving the current workflow gates. Kotlin, Compose, framework,
|
|
51
|
+
or dependency presence alone does not activate it; non-UI Android work stays with
|
|
52
|
+
the general `android` skill. Audit-only requests remain read-only, and unavailable
|
|
53
|
+
visual or emulator checks remain pending rather than claimed as complete.
|
|
54
|
+
|
|
34
55
|
## Common Rationalizations
|
|
35
56
|
|
|
36
57
|
| Rationalization | Reality |
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: web-design-engineering
|
|
3
|
+
description: >-
|
|
4
|
+
Design, implement, and review web interface layout, component states, feedback,
|
|
5
|
+
and motion within the current CodeConductor workflow. Use for concrete web UI
|
|
6
|
+
work or requested UI audits, not backend-only tasks or native mobile apps.
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Web design engineering
|
|
10
|
+
|
|
11
|
+
Apply this guidance to the web surface in scope. A React or Tailwind dependency
|
|
12
|
+
alone is not a trigger. Keep the existing feature, fix, review, or OpenSpec flow;
|
|
13
|
+
this skill adds contextual criteria, not commands, agents, gates, or score weights.
|
|
14
|
+
|
|
15
|
+
## Intake and discovery
|
|
16
|
+
|
|
17
|
+
Translate vague requests into observable behavior: “responsive feedback” might
|
|
18
|
+
mean showing a pending state immediately after submit while preventing duplicate
|
|
19
|
+
submissions. Identify the user objective, affected surface, relevant states, and
|
|
20
|
+
acceptance checks in the Task Card. Ask only about ambiguities that affect scope.
|
|
21
|
+
|
|
22
|
+
Inspect existing components, design tokens, documented visual decisions, installed
|
|
23
|
+
dependencies and versions, and available browser, component-preview, and test tools.
|
|
24
|
+
Reuse the product's visual language and accessible components. Consult official
|
|
25
|
+
documentation for the installed version when an API is uncertain. Prefer existing
|
|
26
|
+
capabilities and browser primitives; a small transition does not justify a library.
|
|
27
|
+
|
|
28
|
+
## Design and implementation
|
|
29
|
+
|
|
30
|
+
Record relevant decisions in the Technical Plan or OpenSpec design.md:
|
|
31
|
+
|
|
32
|
+
- For static UI: hierarchy, readable content, spacing, responsive layout, overflow,
|
|
33
|
+
semantics, contrast, and focus visibility. Do not invent motion to fill a checklist.
|
|
34
|
+
- For interactive components: default, pending, success, failure, disabled, and
|
|
35
|
+
empty states as applicable; pointer, touch, keyboard, focus entry and return.
|
|
36
|
+
Acknowledge input promptly without implying success before it is known.
|
|
37
|
+
- If motion serves the task, name its purpose and weigh frequency, waiting cost,
|
|
38
|
+
and context. Specify start/end states, exit, rapid repeated input, cancellation
|
|
39
|
+
or reversal, and reduced-motion behavior that preserves essential information.
|
|
40
|
+
Use continuity or direct manipulation when it helps users understand the action.
|
|
41
|
+
- Reuse motion tokens. Choose properties and tools appropriate to the component;
|
|
42
|
+
inspect layout/paint cost when relevant instead of assuming smoothness from code.
|
|
43
|
+
No duration, easing curve, animation technique, or visual style is universally
|
|
44
|
+
forbidden. Explain tradeoffs against the contract and product conventions.
|
|
45
|
+
- When alternatives are explicitly requested, compare scoped options and their
|
|
46
|
+
tradeoffs before choosing. Do not build a variant selector or prototype framework.
|
|
47
|
+
|
|
48
|
+
Agree checks before implementation. Preserve the workflow's test-before-implement
|
|
49
|
+
order and use its evidence mechanism when required. Test observable state changes
|
|
50
|
+
and interaction outcomes, not just CSS strings. Implement only the accepted scope.
|
|
51
|
+
Tailwind skills own responsive conventions; framework skills own implementation;
|
|
52
|
+
PageSpeed owns performance measurement; evaluation owns the scorecard.
|
|
53
|
+
|
|
54
|
+
## Review and delivery
|
|
55
|
+
|
|
56
|
+
Use the existing Review Report and its severity/verdict rules. Map contract failures
|
|
57
|
+
to Spec Axis and technical issues to existing subchecks such as Correctness,
|
|
58
|
+
Architecture alignment, Performance, or Test coverage. Preserve Standards Axis;
|
|
59
|
+
do not add a design axis or rerank the two axes. Ground each finding in a location,
|
|
60
|
+
reproduction or evidence, user impact, and a proposed resolution. Aesthetic
|
|
61
|
+
preferences alone are suggestions, not blocking defects. Respect documented
|
|
62
|
+
product choices unless evidence demonstrates a contract or technical failure.
|
|
63
|
+
|
|
64
|
+
For a requested audit, inspect only the agreed surface and prioritize findings by
|
|
65
|
+
impact and evidence. Report out-of-scope opportunities as suggestions. Create
|
|
66
|
+
backlog items through the existing cc-backlog workflow only when requested; deliver
|
|
67
|
+
those items later through OpenSpec. An audit is not permission to implement fixes.
|
|
68
|
+
|
|
69
|
+
Report checks actually performed, their results, and limitations. Code inspection,
|
|
70
|
+
DOM tests, screenshots, and live interaction checks establish different evidence.
|
|
71
|
+
A screenshot cannot prove interruption or keyboard behavior. If a required visual
|
|
72
|
+
or interaction check cannot run, mark it pending with the surface, steps, expected
|
|
73
|
+
result, and missing tool/environment. Do not claim visual validation from code or
|
|
74
|
+
mark the unmet acceptance criterion complete.
|
|
75
|
+
|
|
76
|
+
## Example acceptance
|
|
77
|
+
|
|
78
|
+
For a dismissible web dialog using existing tokens: opening from the keyboard
|
|
79
|
+
places focus inside; Escape during entry closes it without reopening on a stale
|
|
80
|
+
completion callback and returns focus to its trigger. With reduced motion enabled,
|
|
81
|
+
the same actions work without the spatial transition. Check rapid open/close in
|
|
82
|
+
the browser and record the result; if unavailable, keep that check pending.
|
|
83
|
+
For a static pricing page, verify content hierarchy and no horizontal overflow at
|
|
84
|
+
the agreed viewports; no animation is required.
|
|
85
|
+
|
|
86
|
+
## Provenance and boundaries
|
|
87
|
+
|
|
88
|
+
Original CodeConductor adaptation informed by Emil Kowalski's
|
|
89
|
+
[design engineering](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md),
|
|
90
|
+
[animation construction](https://github.com/emilkowalski/skills/blob/main/skills/animate/SKILL.md),
|
|
91
|
+
and [interaction principles](https://github.com/emilkowalski/skills/blob/main/skills/apple-design/SKILL.md).
|
|
92
|
+
Additional references: [review](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md),
|
|
93
|
+
[audits](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/SKILL.md),
|
|
94
|
+
[opportunities](https://github.com/emilkowalski/skills/blob/main/skills/find-animation-opportunities/SKILL.md),
|
|
95
|
+
[vocabulary](https://github.com/emilkowalski/skills/blob/main/skills/animation-vocabulary/SKILL.md),
|
|
96
|
+
[library selection](https://github.com/emilkowalski/skills/blob/main/skills/pick-ui-library/SKILL.md),
|
|
97
|
+
[component guidance](https://github.com/emilkowalski/skills/blob/main/skills/ask-sonner/SKILL.md),
|
|
98
|
+
and [alternatives](https://github.com/emilkowalski/skills/blob/main/skills/prototype/SKILL.md).
|
|
99
|
+
These are provenance, not runtime prerequisites. This skill does not install or
|
|
100
|
+
synchronize upstream skills, adopt promotional responses or mandatory author
|
|
101
|
+
formats, prescribe an Apple identity, or cover Expo/Swift native development.
|
|
@@ -9,6 +9,28 @@ description:
|
|
|
9
9
|
|
|
10
10
|
Feature request: $ARGUMENTS
|
|
11
11
|
|
|
12
|
+
## Web interface scope
|
|
13
|
+
|
|
14
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
15
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
16
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
17
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
18
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
19
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
20
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
21
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
22
|
+
|
|
23
|
+
## Android phone interface scope
|
|
24
|
+
|
|
25
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
26
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
27
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
28
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
29
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
30
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
31
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
32
|
+
|
|
33
|
+
|
|
12
34
|
## Step 0 — CCEP Bootstrap
|
|
13
35
|
|
|
14
36
|
Command: `feature` (fixed for this workflow — do not infer from user text)
|
|
@@ -19,6 +19,28 @@ Provide the following information in $ARGUMENTS:
|
|
|
19
19
|
|
|
20
20
|
---
|
|
21
21
|
|
|
22
|
+
## Web interface scope
|
|
23
|
+
|
|
24
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
25
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
26
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
27
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
28
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
29
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
30
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
31
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
32
|
+
|
|
33
|
+
## Android phone interface scope
|
|
34
|
+
|
|
35
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
36
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
37
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
38
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
39
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
40
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
41
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
42
|
+
|
|
43
|
+
|
|
22
44
|
## Step 0 — CCEP Bootstrap
|
|
23
45
|
|
|
24
46
|
Command: `fix` (fixed for this workflow — do not infer from user text)
|
|
@@ -11,6 +11,28 @@ Scope: $ARGUMENTS
|
|
|
11
11
|
|
|
12
12
|
---
|
|
13
13
|
|
|
14
|
+
## Web interface scope
|
|
15
|
+
|
|
16
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
17
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
18
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
19
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
20
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
21
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
22
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
23
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
24
|
+
|
|
25
|
+
## Android phone interface scope
|
|
26
|
+
|
|
27
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
28
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
29
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
30
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
31
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
32
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
33
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
34
|
+
|
|
35
|
+
|
|
14
36
|
## Step 0 — Validate (mandatory gate)
|
|
15
37
|
|
|
16
38
|
Run `npx cc-codeconductor openspec validate`. If invalid, show errors and recommendations, then **STOP**.
|
|
@@ -18,6 +18,28 @@ Specify what to review. Accepted formats:
|
|
|
18
18
|
|
|
19
19
|
---
|
|
20
20
|
|
|
21
|
+
## Web interface scope
|
|
22
|
+
|
|
23
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
24
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
25
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
26
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
27
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
28
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
29
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
30
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
31
|
+
|
|
32
|
+
## Android phone interface scope
|
|
33
|
+
|
|
34
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
35
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
36
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
37
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
38
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
39
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
40
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
41
|
+
|
|
42
|
+
|
|
21
43
|
## Step 0 — CCEP Bootstrap
|
|
22
44
|
|
|
23
45
|
Command: `review` (fixed for this workflow — do not infer from user text)
|
|
@@ -10,6 +10,28 @@ Feature request: $ARGUMENTS
|
|
|
10
10
|
|
|
11
11
|
---
|
|
12
12
|
|
|
13
|
+
## Web interface scope
|
|
14
|
+
|
|
15
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
16
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
17
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
18
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
19
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
20
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
21
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
22
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
23
|
+
|
|
24
|
+
## Android phone interface scope
|
|
25
|
+
|
|
26
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
27
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
28
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
29
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
30
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
31
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
32
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
33
|
+
|
|
34
|
+
|
|
13
35
|
## Step 0 — CCEP Bootstrap
|
|
14
36
|
|
|
15
37
|
Command: `feature` (fixed for this workflow — do not infer from user text)
|
|
@@ -18,6 +18,28 @@ Provide the following information in $ARGUMENTS:
|
|
|
18
18
|
|
|
19
19
|
---
|
|
20
20
|
|
|
21
|
+
## Web interface scope
|
|
22
|
+
|
|
23
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
24
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
25
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
26
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
27
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
28
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
29
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
30
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
31
|
+
|
|
32
|
+
## Android phone interface scope
|
|
33
|
+
|
|
34
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
35
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
36
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
37
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
38
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
39
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
40
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
41
|
+
|
|
42
|
+
|
|
21
43
|
## Step 0 — CCEP Bootstrap
|
|
22
44
|
|
|
23
45
|
Command: `fix` (fixed for this workflow — do not infer from user text)
|
|
@@ -12,6 +12,28 @@ Orchestrate FIFO delivery from `BACKLOG.md`. CodeConductor owns planning; agents
|
|
|
12
12
|
|
|
13
13
|
---
|
|
14
14
|
|
|
15
|
+
## Web interface scope
|
|
16
|
+
|
|
17
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
18
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
19
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
20
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
21
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
22
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
23
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
24
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
25
|
+
|
|
26
|
+
## Android phone interface scope
|
|
27
|
+
|
|
28
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
29
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
30
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
31
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
32
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
33
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
34
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
35
|
+
|
|
36
|
+
|
|
15
37
|
## Planning Principles — tracer bullet and blocking edges
|
|
16
38
|
|
|
17
39
|
A **tracer bullet** is a vertical slice of work: one `BC-NNN` backlog item that goes discover → design → test → implement → review and produces a demoable result, sized to fit inside a single agent's context window without needing an intermediate `/clear`.
|
|
@@ -17,6 +17,28 @@ Specify what to review. Accepted formats:
|
|
|
17
17
|
|
|
18
18
|
---
|
|
19
19
|
|
|
20
|
+
## Web interface scope
|
|
21
|
+
|
|
22
|
+
When the task concerns web layout, component states, feedback, motion, or a
|
|
23
|
+
requested UI audit, apply skill `web-design-engineering` from the installed skill
|
|
24
|
+
library. Use it during intake/discovery, design, test/implement, and review as
|
|
25
|
+
applicable; keep this workflow’s gates and TDD order. Framework presence alone
|
|
26
|
+
does not activate it; backend-only and native mobile work are excluded. Record
|
|
27
|
+
required visual checks as pending when unavailable. Keep findings in the existing
|
|
28
|
+
Review Report: contract failures in Spec Axis, technical issues in existing
|
|
29
|
+
subchecks, and aesthetic preferences as suggestions; do not add an axis.
|
|
30
|
+
|
|
31
|
+
## Android phone interface scope
|
|
32
|
+
|
|
33
|
+
When the task concerns concrete Jetpack Compose phone layout, component states,
|
|
34
|
+
interaction, accessibility, visual behavior, or a requested UI audit, apply skill
|
|
35
|
+
`android-ui-design`. Use it during design, test/implementation, and review as
|
|
36
|
+
applicable while keeping this workflow's gates and TDD order. Kotlin, Compose,
|
|
37
|
+
framework, or dependency presence alone does not activate it; non-UI Android work
|
|
38
|
+
stays with the general `android` skill. Audit-only requests remain read-only, and
|
|
39
|
+
unavailable visual or emulator checks remain pending rather than claimed complete.
|
|
40
|
+
|
|
41
|
+
|
|
20
42
|
## Step 0 — CCEP Bootstrap
|
|
21
43
|
|
|
22
44
|
Command: `review` (fixed for this workflow — do not infer from user text)
|
|
@@ -35,6 +35,10 @@ quality:
|
|
|
35
35
|
|
|
36
36
|
This playbook defines the architecture, UI design system, performance guidelines, and testing strategy for native Android applications.
|
|
37
37
|
|
|
38
|
+
`android-ui-design` owns specialized Jetpack Compose phone UI/UX design,
|
|
39
|
+
implementation, review, and audit guidance. This skill remains the general guide
|
|
40
|
+
for architecture, Hilt dependency injection, Media3, performance, and testing.
|
|
41
|
+
|
|
38
42
|
---
|
|
39
43
|
|
|
40
44
|
## 1. Lead Architect & Modularization
|