skills/ui-audit/SKILL.md
Audits built React and Next.js frontends for user-facing defects in code and rendered UI: state gaps, data loss, double submits, focus and keyboard failures, rollback gaps, stale async, accessibility markup, layout resilience, performance setup, typography, motion hazards, and microcopy. Returns file:line findings and a ship verdict. Use when asked to "review this PR for UX bugs", "audit this component", "check my UI", "is this accessible", "design QA this page", or "is this ready to ship". For product decisions use product-design; for agentic apps use ax-audit; for deep type or motion use typography-audit or ui-animation; for the wording of a string rather than whether it is missing or leaky, use copywriting.
npx skillsauth add mblode/agent-skills ui-auditInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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).
file:line evidence and fixes.product-design), an agentic-app review (tool parity, trust cues, approval gates → ax-audit), a deep typography or motion pass (→ typography-audit or ui-animation), or a re-implementation of Lighthouse/axe/Chromatic (→ see "Defer to other tools").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.
Copy and track this checklist:
UI Audit progress:
- [ ] Step 1: Determine scope (PR diff via `git diff --name-only main` OR explicit file/folder)
- [ ] Step 2: Detect features in scope (sign-in / checkout / form / modal / list / dashboard / ...)
- [ ] Step 3: For each feature, run its playbook from references/feature-playbooks.md in order
- [ ] Step 4: For each check, load the named rule file (rules-modern/, rules-surface/, or rules/) and run its detection
- [ ] Step 5: Assign each finding a ship tier per references/ship-readiness.md (surface can bump tiers)
- [ ] Step 6: Build the JSON document, then render with the chosen output adapter
- [ ] Step 7: Run the audit-self-check; report INCOMPLETE if it fails
Step notes:
<form> with email + password is sign-in; role="dialog" is a modal; /checkout is checkout. Table: references/feature-playbooks.md.rulesRun count.release-blocker | fix-this-sprint | backlog; surface context bumps the default tier (sign-in/checkout up; marketing/internal-admin down).Four layers, each with its own loading condition. Load rule files individually, on demand:
| Layer | Location | Load when | Size |
|---|---|---|---|
| 1: Feature playbooks | references/feature-playbooks.md | Always, at Step 2, since it is the entry point that names which Layer 2/3/4 rules to run | 12 playbooks |
| 2: Modern failure modes (behavior) | rules-modern/<category>-<slug>.md | A playbook check names the rule, or a changed file matches the rule's category (forms, states, async, focus, mobile, dark-i18n, microcopy) | 28 rules |
| 3: Rendered quality (surface) | rules-surface/<prefix>-<slug>.md | A playbook check names the rule, or a surface needs a rendered-quality check (a11y, interaction, forms, type, nav, layout, perf, motion, copy) | 33 rules |
| 4: Laws of UX | rules/<prefix>-<slug>.md | A playbook explicitly names a Laws rule, or a finding needs cognitive/perceptual reasoning no Layer 2/3 rule covers | 21 rules (19 programmatic, 2 rubric) |
Layer-specific notes:
rules-modern/_sections.md. Each rule file: detection greps, false-positive guards, surface-tier overrides, before/after fix.rules-surface/_sections.md. A rule's frontmatter impact wins over its category default (e.g. perf-image-dimensions-and-priority is CRITICAL inside the HIGH perf- category).rules/_sections.md. The 2 rubric-kind rules score 1-5 against anchor tables in references/observational-rubrics.md: emit the score plus the verbatim anchor text. Pure design-decision scoring (choice architecture, information hierarchy, mental-model fit, dark-pattern framing, aesthetic polish) is out of lane: route it to product-design (and ui-design for visual direction), not a Laws finding here.git diff --name-only main -- '*.tsx' '*.jsx' '*.ts' '*.js' '*.css' '*.module.css'
Audit only those files; surface the base in output: Auditing: 8 files changed vs main.
git diff --name-only HEAD -- src/Component.tsx--full src/), e.g. introducing the skill to a codebase. A default full sweep buries the 3 findings that matter under 60 that don't.Every audit opens with a verdict block before per-finding detail:
═══════════════════════════════════════════════════════════
SHIP VERDICT: ❌ NOT READY (1 release-blocker)
Surface count: 3 (CheckoutForm, PaymentStep, ConfirmStep)
Findings: 7
Release blockers: 1 ⛔ Form data loss on validation (PaymentStep.tsx:42)
Fix this sprint: 3 ⚠️
Backlog: 3 📋
Defer-to (not audited here):
Measured CWV (lab): Run Lighthouse
Bundle size: Run size-limit
Full WCAG conformance: Run axe-core
═══════════════════════════════════════════════════════════
Verdict computation: ✅ READY (0 blockers, ≤3 sprint) · ⚠️ READY WITH FOLLOW-UP (0 blockers, ≥4 sprint) · ❌ NOT READY (≥1 blocker) · 🚫 INCOMPLETE (self-check failed). Tier definitions, surface bump rules, and worked examples: references/ship-readiness.md.
All three formats render from the same JSON document. Templates and field mappings: references/output-adapters.md; strict schema: references/output-schema.md.
| Adapter | When | Format |
|---|---|---|
| Terminal table | Local dev, agent chat | Tight table grouped by surface, tier-sorted |
| PR comment | GitHub / Vercel review | Markdown summary + inline comments with suggestion blocks |
| CI JSON | Pipelines, merge gates | Strict JSON; gate with jq -e '.summary.releaseBlockers == 0' |
A finding is suppressed with an inline comment whose slug matches the rule:
{/* ui-audit-ignore:focus-not-restored, intentional: parent owns focus */}
<Dialog open={open} onClose={onClose}>
Suppressed findings still appear in the summary (summary.suppressed) so reviewers can verify intent.
ui-audit reasons statically; it does not measure runtime metrics or replace conformance scanners. It does surface-level a11y and performance checks (alt text, labels, contrast cues, image dimensions, font loading) but defers comprehensive measurement. When a finding belongs to another tool, link out, don't restate:
| Concern | Use instead |
|---|---|
| Measured Core Web Vitals (LCP, CLS, INP) | Lighthouse + web-vitals |
| Full WCAG conformance scan | axe-core / eslint-plugin-jsx-a11y |
| Visual regression | Chromatic / Percy |
| Bundle size budgets | size-limit / bundle-analyzer |
| Generic correctness bugs | CodeRabbit / Vercel Agent / pr-reviewer |
Full coverage map plus the gaps only ui-audit catches: references/defer-to-other-tools.md.
| File | Read when |
|------|-----------|
| references/feature-playbooks.md | Steps 2-3: feature detection table + per-feature ordered checks |
| references/states-coverage.md | Validating loading/empty/error/disabled coverage; the state matrix and mandatory state pairings |
| references/ship-readiness.md | Step 5: tier definitions, surface bump table, verdict logic |
| references/output-adapters.md | Step 6: verbatim terminal / PR-comment / JSON templates |
| references/output-schema.md | Step 6: strict JSON schema and validation rules |
| references/observational-rubrics.md | Scoring either Layer 4 rubric-kind rule (1-5 anchors) |
| references/defer-to-other-tools.md | Deciding whether a concern is another tool's job |
| references/craft-checklist.md | Optional polish sweep for details no rule encodes (hover affordances, pointer corridors, preserved scroll and object position, chrome hierarchy, theme-switch behavior) when polish or pre-release sign-off is in scope |
| references/typography-checklist.md | Optional typography sweep (punctuation, measure, leading, OpenType basics, link styling, table numerals) when typography is named |
| rules-modern/_sections.md | Layer 2 category index (behavior failure modes) |
| rules-modern/<category>-<slug>.md | Step 4: running a named Layer 2 behavior check |
| rules-surface/_sections.md | Layer 3 category index (rendered-quality, 9 prefixes) |
| rules-surface/<prefix>-<slug>.md | Step 4: running a named Layer 3 rendered-quality check |
| rules/_sections.md | Layer 4 category index (Laws of UX, 5 prefixes) |
| rules/<prefix>-<slug>.md | Step 4: running a named Layer 4 Laws check |
product-design: the product decision, not the build. Route there when the question is "is this the right interaction or set of states", on a brief, spec, mockup, or intent.ax-audit: agentic-feature PRs (agent dashboards, tool-use UIs, trust patterns). Run both on an agentic feature: ax-audit for the agent layer, ui-audit for the surfaces around it.pr-reviewer: correctness bugs and code quality in the same diff; ui-audit covers only user-facing quality and behavior.typography-audit: deep typography (pairing, OpenType systems, brand and display type); ui-audit's type- rules and typography sweep are the shallower check.ui-animation: motion implementation and review (springs, easing, gestures); ui-audit's motion- findings route here for the fix.rules-modern/, rules-surface/, rules/ files the playbook names.release-blocker liberally. Reserve it for data loss, broken critical paths, and dark patterns. If everything is a blocker, the verdict stops gating merges.<Suspense fallback={<InvoiceListSkeleton />}>" gets applied.defaultTier/assignedTier/tierReason and makes runs incomparable.perf-image-dimensions-and-priority is CRITICAL (CLS) even though perf- is a HIGH category.result: "unknown" with a reason, never a fail. The self-check flags audits with >30% unknowns.Self-flag the audit INCOMPLETE if any are true:
rulesRun < rulesPlanned)unknownfile:line citationfix (and, where mechanical, a fixSnippet)development
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.