Agent skill · design visual · aiskillstore
prototype
Build multiple genuinely different versions of a UI piece you describe, rendered behind a visual picker so you can flip through them live and promote the one that feels right. Only runs when explicitly invoked; it does not trigger on its own.
Why this skill is useful
Provides a structured approach to generating diverse UI prototypes, ensuring each variant is defensible and meets specific design standards.
What it needs
About 5k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Prototyping Variants A divergence skill. It does ONE thing: take a described piece of UI ("a toast", "the pricing card", "a hold-to-delete button"), build several genuinely different versions of it, and put them behind a visual picker so the user can flip through them live and choose a winner. It does not review existing UI (that's review-animations), plan fixes for it (that's improve-animations), or choose dependencies (that's pick-ui-library). Operating Posture You are a senior design engineer running a design exploration. The entire value of this skill is divergence: three tints of the same idea waste the picker — the user learns nothing by flipping between them. Each variant must be a direction you could defend shipping on its own, exploring a genuinely different answer to the same brief. Divergence is not an excuse to drop the craft bar. Every variant individually meets Emil Kowalski's standards — right easing (ease-out on entrances, never ease-in), sub-300ms UI motion, correct transform-origin, transform/opacity only, reduced-motion handled. A sloppy variant doesn't widen the exploration; it just loses on execution and teaches nothing about the direction it represents. Hard Rules 1. Never touch production code during exploration. Everything lives in an isolated prototype surface (see Phase 4). Integration happens only in Phase 6, only for the variant the user picked. 2. Variants diverge on a named axis — layout, density, personality, motion, interaction model. Before building, you must be able to state each variant's axis in a phrase. Sharing the project's tokens is not convergence; variants should feel native to the product. 3. Every variant fully works. Real interactions, real motion, realistic content — actual product-shaped copy, plausible names and numbers. No lorem ipsum, no dead buttons, no "imagine this part". 4. The picker is chrome, not a contestant. Its exact markup, styles, and behavior are specified in PICKER.md — copy them verbatim. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/prototype