StyleKit

Use StyleKit to give frontend UI a recognizable visual direction. Begin with the user's goal and the target project's existing structure; a style spec guides the design but does not replace product decisions.

Start with the installed copy

<skill-root> is the directory containing this file, not the target project's scripts/ directory. Scripts require Python 3.10+. Replace placeholders with real paths and keep paths quoted. Save task artifacts in a new task-specific directory (<work-dir> below); do not reuse another task's spec file.

For a pinned tag/commit installation, disable updates before the first check. Otherwise run:

python3 "<skill-root>/scripts/update-skill.py" --auto

On UPDATED, reread this file. Other statuses continue with the installed instructions; offline checks do not block work. Updates follow GitHub main at most once per 24 hours and skip the entire update when managed files have local changes or path collisions. See updates for pinning, controls, migration, and recovery; do not remove local protections to make a check pass.

Route the actual task

Request	Approach
Build new UI	Choose a direction, load its spec, implement the actual content and states.
Restyle or fix existing UI	Preserve behavior, routing, and data; change the relevant visual decisions.
Compare or recommend libraries	Identify the platform, compare suitable candidates with official sources; implement only if requested.
Review consistency	Inspect the existing result against the saved spec; report concrete findings.
Retrieve an asset or template	Follow assets; use exact returned kind/id, availability, and license.

For mobile screens, responsive interactions, or libraries such as ChunUI, read mobile UI. Establish Web/H5, React Native/Expo, SwiftUI, or Flutter before choosing components. A mobile-looking browser page is still a web implementation.

Understand and select

Inspect the target app and reuse its installed primitives. If the stack is unclear:

python3 "<skill-root>/scripts/detect-project.py" "<project-root>"

Detection is evidence, not a compatibility guarantee. Dependencies are declared ranges; inspect the lockfile and app subdirectory when versions or workspace boundaries matter. Do not migrate frameworks to match a suggested library.

For an explicit style, use its exact slug. Otherwise search and choose a fitting direction from the user's context; ask only when an unresolved choice materially changes the outcome. Library recommendations alone do not require fetching a style spec.

python3 "<skill-root>/scripts/fetch-style.py" --search "frosted glass"
python3 "<skill-root>/scripts/fetch-style.py" "<slug>" --json > "<work-dir>/spec.json"

Use the same saved spec for implementation and evaluation. _stylekitSource.degraded marks legacy data that may lack curated lint rules; explain that limit. If fetching fails, reuse an identified saved spec or state that the current catalog could not be verified; do not invent a successful fetch, slug, or rule.

For saved CLI/API/MCP inputs or a local API, read spec sources and checks. The Skill does not install MCP packages or edit client configuration.

Implement in context

Use philosophy, tokens, signature elements, and recipes where they fit the product. Preserve explicit user choices, existing interactions, and accessibility when they conflict with a style rule. Recipes are starting points. For native targets, translate the visual intent into platform components; DOM markup and Tailwind classes are not native APIs.

Keep focused changes focused. For new UI, include its required loading, empty, error, and success states. Use design principles for visual review and style signatures only for the styles it covers.

Integrate globalCss with the existing cascade. In Tailwind v4, put generic resets that should yield to utilities in @layer base or scope them deliberately; unlayered selectors can override utility styles.

Verify what was built

For compatible web class rules, check isolated controls against the saved spec:

python3 "<skill-root>/scripts/eval-check.py" "<slug>" "<component-file>" --spec "<work-dir>/spec.json" --component button --strict

Required classes are matched across the entire input file, not per element. A full-page strict pass cannot prove every control passed. Missing rules or dynamic classes can be inconclusive; inspect them. This evaluator is not a SwiftUI, React Native, Flutter, asset, or accessibility validator. For scan modes and conflicting spec rules, read spec sources and checks.

Run the target project's relevant checks, render at appropriate sizes, and exercise the changed states. Inspect computed colors and focus behavior, not just class names. For native work, distinguish source review, build, simulator, and device checks. Report the implementation and actual verification separately, including any unavailable runtime. See forward testing for repeatable agent evaluation.