skills/ui-variations/SKILL.md

name, description, compatibility

name	description	compatibility
ui-variations	Create 3-5 materially different UI variations inside a web app, present them on a single preview page with a bottom-centered floating switcher, and after the user chooses a winner, fully integrate it and clean up the temporary variants.	opencode

UI Variations

Use when the user wants real coded UI directions for a web UI surface, not static mockups.

Defaults

• Ask at most one clarification if the target surface is unclear.
• Inspect repo docs, routing, components, styling, and design-system primitives before editing.
• Generate 3-5 materially different variations of only the requested surface.
• Present one active variation at a time with a floating bottom-centered switcher.
• Keep the previewed UI production-ready; do not render rationale or experiment notes inside it.
• Stop at preview by default. If the user picks a winner, integrate it and remove preview-only artifacts.

Preview Mode

1. Discover local UI language using references/discovery-checklist.md.
2. Choose the smallest honest preview surface: real feature/page, internal preview route, then isolated sandbox as fallback.
3. Build variations that differ in hierarchy, density, framing, action emphasis, typography, navigation, or control presentation.
4. Reuse the same content/data across variants and preserve surrounding page behavior.
5. Add a bottom-centered switcher with labels like A, B, C, visible active state, pointer-friendly controls, and mobile-safe placement.
6. Keep preview-only code grouped and easy to delete.
7. Run focused lint/typecheck/test/build checks available in the repo.
8. If the app can run and agent-browser is available, inspect desktop and mobile rendering and refine obvious visual issues.
9. Report preview route, files changed, variant labels with one-line rationale, and known gaps. Use templates/preview-summary-template.md when useful.

Promotion Mode

When the user selects a winner:

1. Move the winning variation into the real production surface.
2. Rename experiment code so it reads like normal app code.
3. Update imports, tests, stories, snapshots, and callers as needed.
4. Remove preview route, switcher, losing variants, temporary helpers/fixtures, dead styles, and orphaned assets.
5. Verify the final integrated surface, not just the preview.
6. Report winner, integration location, removed artifacts, and checks run.

Use references/promotion-checklist.md for cleanup.

Guardrails

• Favor the app's real primitives, tokens, spacing, layout, and interaction patterns.
• Do not broaden scope beyond the requested surface unless explicitly asked.
• Do not create a permanent preview framework unless the repo already has one.
• Do not overwrite unrelated work or refactor broadly to host the preview.
• Make each variation shippable enough that the winner can be promoted with minimal cleanup.