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 **5 variants**. Honor any other count the user gives. ## Workflow ### 1. Classify & scope Read the request and settle three things before building anything: - **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** — 5 unless the user said otherwise. - **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 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.** Push the widest spread of *form*: layout structure (grid / list / inline / stacked), visual hierarchy, density (airy vs compact), elevation & borders vs flat, with/without imagery or iconography, decorative vs utilitarian. Five display variants should look