Back to Skills

ux-audit

Walk through a live web app AS a real user to find usability + behavioural bugs that static reviews miss. REQUIRES proof of interaction (typing, clicking, sending, observing) before any verdict — a sweep that didn't interact terminates with verdict 'Incomplete'. Walks threads, exercises every element, runs the multi-pane stress matrix, visual polish sweep, component perfection checklist, automated a11y (axe-core), pragmatic performance budget (LCP/CLS/INP), scenario battery (11 scenarios), and s

889stars91forksUpdated 7/1/2026

Security Assessment

Low Risk(80/100)

Detected risks:

Sensitive File Access([SKILL.md] .env, [references/project-adaptation.md] .env, [references/playwright-killer-flows.md] .env)
Security Score80/100

About ux-audit

An interaction-first audit that walks through a live web app as a real user to find usability and behavioural bugs that static reviews miss. It requires proof of interaction — typing, clicking, sending, observing, and screenshotting — before any verdict, and a sweep that did not actually interact terminates with the verdict Incomplete. The audit exercises threads and every element, runs a multi-pane stress matrix, a visual polish sweep, a component perfection checklist, automated accessibility via axe-core, a pragmatic performance budget (LCP, CLS, INP), a scenario battery of eleven scenarios, and stress recipes including a real-flavour data battery.

Verdicts resolve to exactly one of Pass, Conditional Pass, Fail, or Incomplete, gated by a set of hard gates that auto-fail and cannot be downgraded: zero console errors and warnings during the walkthrough, zero network 5xx, no 403/404 on authenticated pages, no layout collapse at any tested viewport or pane combination, zero axe-core Critical or Serious violations per page, and performance thresholds such as LCP under 4.0s, CLS under 0.25, and INP under 500ms on a representative route. An audit-the-audit meta-check rejects rushed reports, for example when manifest timestamps cluster under half a second apart, screenshots number fewer than twice the routes, or a phase was skipped, and such reports cannot be upgraded to Pass even if everything observed looked fine. A configurable allowlist can suppress known-noisy console or network categories from findings while keeping them in the manifest.

The work proceeds through ordered phases: pre-flight (persona lock, browser tool selection, URL, viewport, and capability tests), discovery, walkthrough, polish, stress, verdict, and fix-and-verify. Pre-flight locks a persona so findings do not drift toward generic impressions, and it mandates the first-time-user lens on every multi-page feature. Browser tooling uses Chrome MCP for authenticated apps to reuse a real logged-in session and Playwright MCP for public sites, with instructions to stop rather than silently fall back if login is impossible. Each finding carries reproduction steps, an evidence path, and a suspected code location, and deeper detail lives in reference files for the performance budget, a11y automation, personas, browser tools, audit config, and project adaptation.

FAQ

What happens if the audit doesn't actually interact with the app?

The only legal verdict is Incomplete. The audit is interaction-first and requires a complete Interaction Manifest; 'it looked OK' is not a Pass, and a static DOM sweep cannot produce a verdict.

What are the possible verdicts?

Exactly one of Pass, Conditional Pass, Fail, or Incomplete. Pass and Conditional Pass require zero Critical and High findings with all hard gates green; Fail means at least one Critical or High finding or a red hard gate.

Which conditions automatically fail the audit?

Hard gates that cannot be downgraded, including any console errors or warnings, any network 5xx, 403/404 on authenticated pages, layout collapse, axe-core Critical or Serious violations per page, and performance breaches like LCP over 4.0s, CLS over 0.25, or INP over 500ms.

Which browser tool does it use?

Chrome MCP for authenticated apps because it reuses your real logged-in session so OAuth, cookies, and RBAC work, and Playwright MCP for public sites. If neither is available it stops rather than silently using a fresh session.

Why does it lock a persona before starting?

Without a locked persona, findings drift toward generic 'looks fine' judgments. The persona is written at the top of the report and every finding must be defensible from its perspective, and the first-time-user lens is always run on multi-page features.

All Files

23 files
references/audit-config.md7.1 KB
View
references/interaction-manifest.md9.7 KB
View
references/performance-budget.md5.5 KB
View
references/round-trip-workflows.md10.0 KB
View
references/workflow-comprehension.md8.3 KB
View
references/audit-output-discipline.md10.1 KB
View
references/live-interaction-smoke.md9.7 KB
View
references/persona-lock.md7.9 KB
View
references/scenario-tests.md30.3 KB
View
SKILL.md33.7 KB
View
references/browser-tools.md6.5 KB
View
references/multi-pane-stress.md9.0 KB
View
references/project-adaptation.md14.6 KB
View
references/visual-polish.md16.7 KB
View
references/a11y-automation.md5.2 KB
View
references/data-seasoning.md9.7 KB
View
references/perfection-checklist.md11.3 KB
View
references/report-template.md19.4 KB
View
references/walkthrough-checklist.md17.0 KB
View
references/auth-expired-handling.md3.9 KB
View
references/long-running-check-in-pattern.md3.3 KB
View
references/playwright-killer-flows.md10.7 KB
View
references/stress-test-recipes.md14.0 KB
View

Install ux-audit

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill