prototype-variants
Exploring Several Directions At Once
Take one described piece of UI — a toast, the pricing card, a hold-to-delete button — build several genuinely different answers to it, and put them behind a picker the user can flip through live. The entire value is divergence. Three tints of the same idea waste the picker: the user learns nothing by flipping between them, and you have spent a build to discover something a sentence would have told you. Default to 3 variants, each one a direction you could defend shipping on its own. Then present them and stop — the choice belongs to the user, and pre-picking a favourite converts an exploration back into a recommendation.
This never fires on its own. Its explicit-only sibling is pick-library: that one answers "which dependency", this one answers "which direction", and neither is a fallback for the other. It also does not review existing UI (ui-review), plan fixes for it (motion-audit), or hunt for places motion is missing (motion-opportunities) — those all converge on one answer, and this skill exists to refuse to.
Before designing anything, read the ground the variants must stand on. Framework, styling system (Tailwind, CSS modules, vanilla), motion library if one is installed, and the token set — colors, radii, spacing, fonts, easing and duration variables. Every variant is written in that system, using those tokens, so all of them look like they could ship tomorrow; a variant that invents its own scale is not a bolder direction, it is an unusable one. Sharing tokens is not convergence — divergence happens on layout, density, personality, motion, and interaction model, not on hex values. Read the product's personality too, because it bounds how far the boldest variant may go, and read where the piece renders: against what background, beside what neighbours, at what size. If there is no project at all, take the standalone branch and pick a restrained default — neutral greys, one accent, system font stack.
Quick Reference
| Topic | File |
|---|---|
| The picker's markup, CSS, keyboard wiring, and behaviour contract | references/picker.md |
Load references/picker.md at the moment you start building the harness, before writing any picker markup, and copy it verbatim. It is the only file here, and the only thing in this skill that is not a judgment call.