Create three distinct versions of one interface component and compare them at full size on the actual page. Explore a chosen design dimension, review each option's tradeoffs, and integrate the selected version while removing the temporary comparison controls.
中文简介正在准备中。当前显示英语简介。
Builds multiple variants of a component you're working on and helps you iterate and pick one.
安装前可以查看交给 AI 代理的指令内容。
This skill takes one described piece of UI and builds three versions that differ on purpose. They go behind a picker in the real page, so you can flip between them and choose.
It produces candidates and never ranks them. Reviewing existing UI is interface-review and better-interface, stress testing one component is break and working through a component's states is state-machine.
Each variant is a different answer to the same brief, on an axis this collection owns:
| Axis | Owner | What varies |
|---|---|---|
| Structure | better-layout | Grouping, order, column count, what collapses |
| Density | better-layout | Spacing scale, how much fits |
| Emphasis | better-colors | Where filled color goes, what recedes |
| Type | better-typography | Scale steps, weight contrast, measure |
| Voice | better-writing | Labels, tone, how much copy |
Pick one primary axis and give each variant a different position on it. The axis names the picker's group heading. Secondary choices follow from it rather than varying on their own. A dense variant may need a smaller type step, and that is coherence, not a second axis.
Before a variant enters the picker it clears better-interface's escalation triggers, which are:
prefers-reduced-motion.That floor is identical across variants. It is not an axis and never trades against one. Where a direction can only work by breaking it, say so and drop the direction.
One piece of UI per run. "The dashboard" is not a piece; the metric card is. Where the request spans several, list the candidates and ask which one to explore.
Restate the brief in one sentence: what the thing is, where it renders, what it has to do.
Variants have to look like they could ship tomorrow, so read what they stand on:
With no project to read, use neutral grays, one accent and the system font stack, and say that is what you did.
Default to three variants. Go to five only when asked.
Write the set down first, a name and an axis position each. Names say what the direction is, so Quiet, Editorial, Dense, never Option A.
This step is done when no two variants share a position and you can state each one's axis in a phrase.
Host the variants on the page that will actually contain the piece, with the real chrome, the real neighbours and realistic data.
Select with a URL search param such as ?__variant=quiet, so every variant is a link you can send someone. A grouped list beside the piece sets it. Where there is no room beside the piece, it moves above it as a select with the same groups. picker.md holds the spec.
Render one variant at a time, full size. Thumbnails distort spacing and scale, and spacing is usually the thing you are choosing between.
Variant files may import production components. Only the hosting page imports a variant, and nothing else imports from the harness.
Where no page can host it, build one self-contained HTML file and keep the same picker.
Give every variant real content: product-shaped copy, plausible names and the number of items the page will really carry. Lorem ipsum and three rows make every structure look good.
Load the page once in a browser already at hand and flip through every variant. Each one renders, each interaction responds and the console is clean. With no browser at hand, say so and hand the URL over for the user to check.
Then hand the decision over:
| Variant | Axis position | Right when | Costs |
|---|---|---|---|
| Quiet | Lowest visual weight | The page is used daily | Least memorable |
| Editorial | Largest type, most space | The moment deserves weight | Eats vertical space |
Say where the picker is running, which key flips it and which width you judged at. The answer can change between 375px and 1440px.
Never mark a favourite in the table. Asked directly, answer from how often the piece is seen and from the product's personality, not from which one you enjoyed building.
On a choice, build that variant properly where it belongs, following the project's own conventions. Then delete the other variants, the picker and the guarded import. Search for the variant names and the __variant param, and check the diff leaves nothing of the harness behind.
Asked for another round instead, keep the harness and run Name the axis before writing code again, taking new positions around the direction you leaned toward.
| Mistake | Fix |
|---|---|
| Variants differ only in accent color or copy | Move one to a different position on the primary axis, or cut it |
| Every axis varies at once | Vary one; let the rest follow from it |
| Judged on a blank route | Host them on the page that will contain the piece |
| Lorem ipsum, three rows, "Jane Doe" | Real copy and the item count the page will really carry |
| The boldest variant skips keyboard or focus | Clear the floor or drop the direction |
| A favourite marked in the table | State each variant's cost and let the user choose |
| Picker restyled with the project's tokens | Keep it visibly outside the design system |
| One long row of tabs, one per variant | A grouped list beside the piece that scrolls on its own; a select above it where the list does not fit |
| Harness left behind after promotion | Delete it and search for the names and the param |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Review and fix interface accessibility against WCAG 2.2, a web accessibility standard. Check keyboard navigation, focus, screen reader labels, forms, motion, and zoom, then report failures with their criteria and implement fixes using the project's existing styling system.
中文简介正在准备中。当前显示英语简介。
Build and review interface color systems with palettes, format conversions, and semantic tokens that name colors by purpose. Measure foreground and background contrast, and identify inconsistent themes, misused color roles, and colors outside the supported range.
中文简介正在准备中。当前显示英语简介。
Review an interface across accessibility, layout, writing, typography, color, and visual polish. It coordinates specialist skills, combines evidence from code and rendered screens, and produces one report with findings ranked by their impact on users.
中文简介正在准备中。当前显示英语简介。
Review and improve interface grouping, alignment, spacing, and responsive structure. Check whether content and actions remain accessible when screens resize, text grows in translation, zoom increases, or the layout switches to right-to-left reading.
中文简介正在准备中。当前显示英语简介。
Set and review how interface text renders, including font loading, size hierarchy, line spacing, wrapping, truncation, and punctuation. Apply fixes within the existing styling system and check how realistic content behaves across different widths.
中文简介正在准备中。当前显示英语简介。
Refine interface surfaces, icons, and motion with specific values for corners, shadows, alignment, and transitions. Preserve the project's existing design conventions while identifying visual inconsistencies, touch interaction problems, and missing alternatives for reduced motion.
中文简介正在准备中。当前显示英语简介。