ux-audit

Invoke the ux-audit skill with the page or surface name, optionally scoping with --l1, --l2, or --l3. L1 reads the code for missing states and patterns, L2 reviews screenshots of the render, and L3 drives the real user journey with performance instrumentation.

L1 statically reads code to catch missing empty/error branches and absent patterns. L2 inspects screenshots for visual hierarchy, spacing, and responsive issues. L3 automates the user journey via agent-browser CDP to force states and measure CLS, LCP, and INP.

No. The skill's coverage matrix forbids visual verdicts from code alone — a variant prop cannot confirm the dominant control is the primary action. Visual claims must be verified on a rendered screenshot with the Read tool, and metrics like CLS require L3 instrumentation.

It benchmarks the surface's class against comparable mature products before reading code, since an entirely absent feature leaves no code to grep. For example, an OAuth consent screen is checked against GitHub/Google norms like switch-account and scope listing.

Concrete bugs are fixed or filed as Linear sub-issues, generalizable gaps are fed back into the ux checklist skill as new or sharpened rules, exemplary good cases become positive examples, and the audit itself is saved as a worked-example reference.

L1 runs on every audit as the cheap baseline. Add L2 only when findings concern layout, hierarchy, or rendered states, and L3 only when you need to walk a journey, force runtime states, or quantify performance — running all three every time is wasteful.