52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
---
|
|
name: ui-variations
|
|
description: 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.
|
|
compatibility: 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.
|