ui-review

ui-review critiques a screen, flow, prototype or running build, accessibility included, and ranks what is broken. The render is the evidence: it captures the screen at each width and probes the states a screenshot misses.

Use to critique a screen, flow, prototype or running build, accessibility included, and rank what is broken, such as "check this page before I ship", "is this flow ready", "is it accessible", keyboard or screen-reader checks, "it feels off on my phone" or "it feels janky". Not for token compliance, which is token-mapping.

1. Scopes the review: what you named, else the branch's changed screens, else the five top routes.
2. Runs the project's own lint and records the command and exit code.
3. Captures each screen at 390 and 1280 wide, one fresh navigation per width, with every write blocked.
4. Probes the traps on a local build: the keyboard path, focus after close, loading and error states, a throttled tab, reduced motion and a touch width. Press feedback is measured with the Event Timing API, under 100 ms.
5. Walks 13 criteria at each width, citing each finding by number or by the installed design system's rule id.
6. Sorts findings into blocking, should-fix, note or dismissed, with surfaces that write data first.

A first line that answers the ask, then a ship line such as "Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2)". Then the review record, findings by bucket, edge cases not shown, questions for a person, and what was dismissed and why.

• Keep a finding that rests on taste. "The spacing feels tight" is dropped; "Label sits 24 px from its own field and 8 px from the next one" stays.
• Judge responsiveness from a screenshot. It needs a measured probe.
• Click anything that writes to shared data.

ui-review installs with the other five design.how skills, for Claude Code, Cursor, Codex and any agent that reads Agent Skills. The install command and the .zip are on Skills, free after an email signup.

• design-system-boss: Say what is wrong with your UI in plain words; it picks a playbook and runs the other design.how skills in order.
• build-design-system: Builds a design system from the UI your app already ships: tokens, components, docs and checks, proved on one flow.
• migrate-design-system: Moves every screen of an app onto an existing design system with many agents, each screen checked against its before screenshot.
• token-mapping: Reports how the hardcoded colors and sizes in your code map onto your design tokens, by purpose. It never edits.
• component-docs: Writes one component's documentation from its code and two real uses, with rules next to the examples.