SKILL.md
UI Audit
Audits the built frontend at the feature level (checkout, onboarding, a dashboard) for a dev with a PR open: "which of these hurt users in production, and which are nice-to-haves?" Reasons about code behavior (React/Next source) and rendered quality (accessibility, layout, performance, type, motion).
- IS: a diff-aware reviewer that detects which feature each changed file implements, runs that feature's playbook across behavior, rendered-quality, and Laws of UX rules, and emits a 3-tier ship verdict with
file:lineevidence and fixes. - IS NOT: the product decision of what should exist (right interaction, action naming, reachable states →
product-design), an agentic-app review (tool parity, trust cues, approval gates →ax-audit), a deep typography or motion pass (→typography-auditorui-animation), or a re-implementation of Lighthouse/axe/Chromatic (→ see "Defer to other tools").
product-design or ui-audit?
The dispatch signal is the artifact, not the topic. Both care about states and interaction, but act at different moments.
| You have... | The question is | Use |
|---|---|---|
| A brief, spec, mockup, intent, or a UI you decide about | What should exist: the right interaction, the action's name, which states should be reachable | product-design |
| Code, a diff, or a running UI you decide on | Is the built result right: states covered, accessible, renders and behaves correctly, ready to ship | ui-audit |
Often both in sequence: product-design decides the states that must exist, ui-audit verifies the built code implements them.