ui-variantslisted

# UI Variants Turn one component request into several genuinely different variants, laid out side by side for the user to pick from, then wire the winner in. **Diverge** wide, then **converge** on one. Default to **3 variants**, never more than **5**. Honor any lower count the user gives. ## Workflow ### 1. Classify & scope Read the request and settle four things before building anything: - **Scope** - one component per run. If the request spans several ("the dashboard"), pick the single highest-leverage piece, say which and why, and offer the rest as follow-up runs. - **Type** - is this **display-only** (renders data: cards, tables, badges, stats, empty states, nav) or **interactive** (takes input: inputs, forms, filters, pickers, wizards)? This decides the axis of variety in step 2. - **Count** - 3 unless the user said otherwise, capped at 5. - **Stack** - find how components are built in this codebase (framework, styling system, existing primitives) so variants match it and can drop in. Reuse existing tokens/components; don't invent a parallel design system. **Done when** you can restate the brief in one sentence and name the type, the count, and the file(s) you'll add variants to. ### 2. Diverge Build the variants. Each must differ from the others on a **real axis**, not by tweaked padding or swapped colors - a stranger should be able to say _why_ two variants are different in one sentence. The axis depends on type: **Display-only → maximize visual variety.** Pu