design-review

Review UX flows, component specs, and design-system token conformance against user goals.

Updated Feb 10, 2026
One-click install
npx skills add https://github.com/vesviet/agent-skills --skill design-review-vesviet
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: design-review
Source: https://github.com/vesviet/agent-skills/tree/main/core/skills/foundation/design-review
Command: npx skills add https://github.com/vesviet/agent-skills --skill design-review-vesviet

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design specs often reach engineering with missing UI states, hardcoded style values, or accessibility gaps that cause rework. This Skill validates ux-flow-spec and ui-component-spec artifacts against user goals, design-system tokens, and accessibility requirements before Frontend implementation begins. ## Core Features & Use Cases - Spec Completeness Validation: Enforces the five critical UI states (Empty, Loading, Populated, Error, Unauthorized) on every screen spec and classifies findings as blocking, should-fix, or suggestion. - Token & AI-Generated UI Conformance: Checks Figma variable mappings, rejects hardcoded hex colors and magic spacing, and runs axe-core plus namespace-pollution checks on outputs from v0.dev, Galileo, or Builder.io. - Use Case: Before handing a checkout redesign to Frontend, run this Skill to verify the flow spec covers all error and permission states, confirm dark-mode token contrast, and emit a severity-classified findings report for the UI/UX Designer. ## Quick Start Use the design-review skill to critique this ux-flow-spec and ui-component-spec against our design-system tokens and list any blocking findings before implementation.

Frequently Asked Questions about design-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a UX flow spec before frontend implementation?▼

Validate the ux-flow-spec against declared user goals, confirm every screen defines the five critical states (Empty, Loading, Populated, Error, Unauthorized), and classify findings as blocking, should-fix, or suggestion. Blocking items return to the UI/UX Designer before Frontend starts.

How to check AI-generated UI for design-system conformance?▼

Run a token conformance check to reject hardcoded hex colors, magic spacing, and raw typography, then run an axe-core accessibility scan and a style namespace pollution check. Treat outputs from v0.dev, Galileo, Builder.io, or Copilot as untrusted until all three checks pass.

What UI states must every screen spec define?▼

Every screen spec must define five critical states: Empty, Loading/Skeleton, Populated, Error with actionable recovery, and Unauthorized/Permission. A spec missing any of these states is incomplete and should be rejected during review.

Does design review cover accessibility conformance?▼

It runs axe-core scans on generated components and flags contrast or focus issues as blocking, but deep WCAG conformance work is routed to the accessibility-review skill. Code-level bugs are routed to review-code instead.

When is an interactive Figma prototype required for review?▼

An interactive Figma prototype link is required for any flow with more than two screens before Frontend implementation begins. The reviewer refuses the review until the prototype is provided, then checks transitions, timing, and edge-case state responses.