Help us improve
Share bugs, ideas, or general feedback.
From lynx
Deep end-to-end audit of any UI screen — visual defects, interactive element verification, content quality, and UX heuristics — in one protocol. Goes far beyond a screenshot checklist: inventories every action item (button, link, field, gesture), verifies each is discoverable / reachable / functional, audits prose / code-block / diagram / data-viz rendering, and evaluates the experience against Nielsen's 10 heuristics plus affordance theory. Use whenever reviewing a UI screenshot, simulator capture, browser screenshot, or live page on iOS, web, or cross-platform. Trigger even when the user just says "review this screen", "audit this page", "is this UI good", "QA this view", or attaches a UI screenshot. Configurable depth: identify-and-delegate (light, screenshot-only) or drive-interaction (heavy, when tap / click tools available). Complements `visual-inspection`, `functional-validation`, and `full-functional-audit`.
npx claudepluginhub krzemienski/lynx --plugin lynxHow this skill is triggered — by the user, by Claude, or both
Slash command
/lynx:ui-experience-auditThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A complete audit of a UI screen across four dimensions, ending in a single severity-classified report. Designed to catch the failures a checklist-only inspection misses: buttons that *look* tappable but aren't wired up, code blocks that render unreadable, charts that exclude keyboard users, and screens that violate basic usability heuristics even when every pixel is "correct".
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
A complete audit of a UI screen across four dimensions, ending in a single severity-classified report. Designed to catch the failures a checklist-only inspection misses: buttons that look tappable but aren't wired up, code blocks that render unreadable, charts that exclude keyboard users, and screens that violate basic usability heuristics even when every pixel is "correct".
Phase 0 Triage → right-size the audit (skim / standard / deep)
Phase 1 Visual → layout, contrast, typography, platform conformance
Phase 2 Interactive → inventory + affordance + reach + (delegate | drive)
Phase 3 Content quality → prose, code blocks, diagrams, data viz, tables, media, forms
Phase 4 UX heuristics → Nielsen's 10 + affordance/signifier alignment
Phase 5 Synthesis → severity-classified report + hand-offs
For each phase: walk the checklist → record findings → assign severity → continue to next phase. Don't abort on a phase failure. Phase 5 decides go/no-go.
In this skill, a "screen" is a single user-facing UI surface — a page, a modal, a sheet, a major view, or a discrete component with its own context. A whole app is not a screen (use full-functional-audit for app-wide audits). A button is not a screen (it's an element within one). When in doubt, treat each navigable / dismissible UI surface as one screen.
This skill covers:
Out of scope: backend API testing, performance profiling, code review without a UI surface, security audits.
Before starting, decide which mode applies. Both modes run all 5 phases — they differ only in Phase 2 depth.
| Mode | When to use | Phase 2 behaviour |
|---|---|---|
| Identify-and-delegate (light) | Only a screenshot is available; no tools to interact with the live system; reviewing static design artifacts | Build the action-item inventory and assess affordance/discoverability/reach from the image alone. Hand off functional verification to functional-validation / full-functional-audit / ios-validation-runner with a structured task list |
| Drive-interaction (heavy) | Live system reachable via simulator (xcrun simctl, idb), browser automation (agent-browser, Playwright, Chrome DevTools MCP), or a running dev server | Inventory and exercise each action item, capturing follow-up screenshots / DOM snapshots / accessibility-tree dumps as evidence. Still hand off deep flow validation to dedicated functional skills if the audit reveals system-level work |
If unsure, default to identify-and-delegate. Escalate to drive-interaction only when you have a clear tool path and the user has approved interactive actions.
When running in identify-and-delegate mode, if you encounter a finding that only drive-interaction can resolve (e.g., "this button might or might not be wired up — I can't tell from a screenshot"), don't fabricate a verdict. Instead:
The reverse is also valid: in drive mode, if a destructive or auth-gated action would require user approval (delete, submit payment, send message), drop back to delegate for that specific element rather than driving it without consent.
When driving interaction, capture per-element evidence using a consistent path and naming pattern so the receiving skill / human reviewer can correlate findings to artifacts:
evidence/
├── audit-<screen-name>-<YYYYMMDD-HHMM>/
│ ├── 00-pre-audit.png # before any interaction
│ ├── 01-element-<id>-<label>-pre.png # before tap/click
│ ├── 01-element-<id>-<label>-post.png # after tap/click
│ ├── 01-element-<id>-<label>.log # action + outcome
│ ├── 02-element-<id>-<label>-pre.png
│ ├── ...
│ ├── coverage/
│ │ ├── light-desktop.png
│ │ ├── dark-desktop.png
│ │ ├── light-mobile.png
│ │ └── dark-mobile.png
│ └── audit-report.md # the Phase 5 synthesis
The per-element .log is the single source of truth for that interaction:
Element: 01 — "Continue" button (primary CTA)
Coordinates / selector: (200, 720) / button[data-test="continue"]
Pre-tap state: button enabled, no focus
Action: idb ui tap 200 720
Post-tap state: navigated to /onboarding/step-2
Latency: 230ms (subjective — not measured)
Verdict: PASS — affordance matches behaviour, no false positives
Evidence: 01-element-01-continue-pre.png, 01-element-01-continue-post.png
Align with ios-validation-runner conventions when on iOS — same paths feed both skills' downstream consumers without re-naming.
Detect platform from artifacts in context, then load matching references:
| Indicator | Platform | LOAD |
|---|---|---|
.xcodeproj, SwiftUI, simctl, iOS simulator screenshot | iOS / macOS | references/ios-hig-checklist.md |
| HTML / CSS / JSX, Playwright, browser screenshot | Web | references/web-wcag-checklist.md |
| React Native, Flutter, Expo | Cross-platform mobile | BOTH iOS + web references |
Always load:
references/interactive-element-audit.md — Phase 2 methodreferences/content-quality-checklist.md — Phase 3 methodreferences/ux-heuristics-checklist.md — Phase 4 methodreferences/defect-pattern-database.md — known defect → root cause → fix mappingsLoad when relevant:
references/responsive-audit.md — load for any web / cross-platform target; defines the multi-viewport × dark/light × state matrix and capture commandsUse this asset:
assets/audit-report-template.md — copy-paste markdown template for the Phase 5 synthesis. Read it when starting an audit; write your filled report into the user's workspace (or output directory if file outputs are configured).Reference files are read on demand; SKILL.md is the protocol skeleton.
The most common audit failure is deciding "this looks good" before walking the checklist, then confirming that prior. Three rules to prevent it:
A 0-finding audit is suspicious. Real screens, even good ones, have ≥3 LOW-or-above findings. Zero findings means you skipped a phase.
Run phases in order. A phase failure does not abort the audit — it is recorded and the next phase continues. The Phase 5 synthesis decides go / no-go.
Before the full inventory, scan the screen once for show-stoppers. If any of these are present, record them immediately as CRITICAL and continue — don't let later phases bury them:
<img> placeholders, blank-but-bordered containers, "undefined" / "null" / "NaN" rendered as text)Lorem ipsum, Test, [TODO], xxx, hardcoded John Doe, dummy emails / phone numbers visible in production-looking UIThese are CRITICAL by default — none of them should ship. Record them now; the rest of the audit may explain root cause.
After triage, note which states are represented in the evidence:
If any axis is single-coverage, flag it now: "Only light mode in evidence — dark mode audit pending". A PASS verdict with single-axis coverage is at most a PASS for the audited mode — never a global PASS. This is itself a finding worth recording.
Run the universal visual checklist below for every screenshot. Then run the platform-specific checklist from the loaded reference. This is the same protocol the visual-inspection skill uses; the canonical checklists live in the reference files.
Universal visual checklist (every item must pass):
<h1> per page (or equivalent on iOS), no skipped levels (h1→h3 without h2 is a fail), visual size matches semantic levelThen walk the platform-specific checklist from the loaded reference (iOS HIG or WCAG 2.2).
Without devtools, exact contrast ratios are not knowable from an image alone. Use these rules of thumb:
| Visual cue | Likely contrast | Action |
|---|---|---|
| Text legibly distinct from background, full saturation | Probably ≥ 4.5:1 | Pass at this level; flag for tooled verification |
| Text noticeably "soft" or "faded" against background | Probably 3.0–4.5:1 | Suspect — flag as MEDIUM, recommend tooled check |
| Text required squinting or color-pick to read | Probably < 3.0:1 | Flag as HIGH–CRITICAL |
| Pale gray on white, light gray on light gray | Likely fails AA | CRITICAL |
| Comment color in code block noticeably lighter than code | Common Prism/Monokai default failure | Flag as HIGH, recommend WebAIM check |
When evidence is from a live system reachable via tools, prefer Lighthouse / Axe / browser DevTools accessibility panel for exact measurements rather than estimates.
Open references/interactive-element-audit.md and follow the inventory + verification method. The summary:
functional-validation / full-functional-audit / ios-validation-runnerFalse affordances (looks tappable but isn't) and missing signifiers (functional but invisible) are both Phase 2 failures.
Open references/content-quality-checklist.md. Audit every piece of rendered content for fitness-of-purpose:
<title>/<desc> for SVG, color is not the sole channel (patterns / shapes / direct labels), interactive diagrams keyboard-reachable with visible focus, hover-only info has a non-hover equivalenttabindex), tooltips work without mouse, axes labelled, legend present and matched, alternative text or data table available, resizes to 200% without breakingContent failures often hide inside what looks like a "passing" visual layout — a perfectly aligned code block whose syntax highlighting drops contrast to 2.1:1 still fails.
Open references/ux-heuristics-checklist.md. Apply Nielsen's 10 heuristics as an inspection lens, plus the affordance / signifier alignment check:
Plus affordance / signifier alignment: for every interactive element, perceived affordance must match actual affordance, and the signifier must be discoverable without trial-and-error.
For each violation: cite the heuristic, describe what you see, name the offending element, propose a fix.
Combine findings from Phases 0–4 into a single report with this structure:
## UI Experience Audit — <screen name>
Mode: identify-and-delegate | drive-interaction
Platform: iOS | web | cross-platform
Evidence reviewed: <list of screenshots / captures / artifacts>
Coverage: <light/dark, viewports, states represented — any gaps>
### Phase 0 — Triage
- [CRITICAL] [TRIAGE_CATEGORY] — <what you see> — <suggested fix>
(or "No triage-level issues" if clean)
### Phase 1 — Visual Defects
- [SEVERITY] [CHECKLIST_ITEM] — <what you see> — <suggested fix>
### Phase 2 — Interactive Elements
Inventory: <N> action items
- [SEVERITY] [ELEMENT] — <signifier / affordance / reach / functional finding>
### Phase 3 — Content Quality
- [SEVERITY] [CONTENT_TYPE] — <finding>
### Phase 4 — UX Heuristics
- [SEVERITY] [HEURISTIC #N: NAME] — <violation> — <suggested fix>
### Verdict
PASS | PASS WITH ISSUES | FAIL | PASS (LIMITED COVERAGE)
- Critical: <count>
- High: <count>
- Medium: <count>
- Low: <count>
- Coverage gaps: <list, e.g. "dark mode not audited", "mobile viewport not audited">
### Hand-offs
- functional-validation: <task list, if any>
- full-functional-audit: <task list, if any>
- ios-validation-runner: <task list, if any>
Verdict rules:
Severity definitions:
| Severity | Definition | Action |
|---|---|---|
| CRITICAL | Triage-level (broken / missing content, lorem ipsum, crash state), content unreadable, broken interaction (false affordance), unrecoverable error state, accessibility blocker | Fix immediately, blocks completion |
| HIGH | Layout broken, content quality fails (illegible code block), heuristic violation that creates user confusion, undersized or overlapping touch targets | Fix before commit |
| MEDIUM | Inconsistent spacing, weak signifier, redundant content, minor heuristic drift, suspect contrast | Fix in same session |
| LOW | Cosmetic polish, subtle alignment, edge-case content rendering | Log for future pass |
Mark PASS only when zero CRITICAL and zero HIGH issues remain across all phases AND coverage is multi-axis. Otherwise route to PASS WITH ISSUES, PASS (LIMITED COVERAGE), or FAIL per the verdict rules above.
Abbreviated audit output for a hypothetical sales-dashboard screen captured in light-mode desktop only. Use this shape for your own reports.
## UI Experience Audit — Sales Dashboard
Mode: identify-and-delegate
Platform: web
Evidence reviewed: dashboard-light-desktop.png (1024×800)
Coverage: light mode + desktop only — dark mode and mobile not audited
### Phase 0 — Triage
- [CRITICAL] Missing chart content — "Revenue by month" chart container is
rendered but bar elements are absent (empty plot area between legend and
x-axis labels). Likely CSS height-percent on bars without resolved parent
height. — Fix render before continuing.
### Phase 1 — Visual Defects
- [HIGH] Typography contrast — "Last sync: 2 hours ago" muted text appears
~3:1 against white; suspect AA fail. Recommend tooled check (WebAIM /
Lighthouse) and bump to slate-600 minimum if confirmed.
- [LOW] Heading hierarchy — single h1 ("Sales — Q3 2025"), no skip detected.
### Phase 2 — Interactive Elements
Inventory: 11 action items
- [HIGH] "Q3 2025" (in title) — bold blue, looks like a link, not anchored.
False affordance. — Either remove link styling or wire it to a Q3 detail view.
- [HIGH] KPI cards (3) — hover-lift effect implies tappable, no handler.
False affordance. — Either remove hover effect or wire to a drill-down.
- [HIGH] Icon buttons (Edit / Archive / Delete, 6 instances) — 24×24px
with 4px gap. Below 8pt minimum spacing. — Increase gap to 8pt and pad
buttons to ≥32×32 visible tap area.
- [MEDIUM] Delete (×) icon styled identically to Edit and Archive —
destructive action visually undifferentiated. — Apply danger color to
delete only.
Hand-off (delegate mode):
functional-validation:
- Verify "Q3 2025" tap behaviour (expected: nothing, current: nothing) —
confirm intent
- Verify KPI card tap behaviour
- Verify Delete confirmation dialog appears and is dismissible
### Phase 3 — Content Quality
- [HIGH] Chart — color-only series distinction (red Series A vs green
Series B). Fails for ~8% of viewers with red-green color blindness. — Add
patterns / shapes / direct labels or use color-blind-safe palette.
- [HIGH] Chart — no `<title>`/`<desc>` or alt text equivalent; no data table
alternative. — Add accessible name and consider exposing underlying data.
- [MEDIUM] Chart — no direct point labels; values only readable via tooltip
(and tooltip not visible in static screenshot — needs interaction audit).
### Phase 4 — UX Heuristics
- [HIGH] Heuristic 6 (Recognition rather than recall) — filter dropdowns
("All regions", "All products") imply filter state, but no chip / pill
shows what filter is currently active. User must open the dropdown to
recall. — Add active-filter chips with × to clear.
- [MEDIUM] Heuristic 5 (Error prevention) — Delete (×) icon adjacent to
Archive (▤), same size and color. Easy mis-tap. — See Phase 2.
### Verdict
FAIL
- Critical: 1 (missing chart)
- High: 6
- Medium: 2
- Low: 1
- Coverage gaps: dark mode, mobile viewport, populated-data state for chart
### Hand-offs
- functional-validation: 3 tasks (above)
- ios-validation-runner: n/a (web)
This skill identifies findings; some findings need other skills to remediate.
| Finding type | Hand-off to |
|---|---|
| "Element should be tappable but I can't verify" (light mode) | functional-validation, ios-validation-runner |
| "Need to exercise every screen + button + endpoint" | full-functional-audit |
| "Pure visual QA only" | visual-inspection (this skill's lighter sibling) |
| "Pre-completion gate evidence missing" | gate-validation-discipline |
| "Need a screenshot first" (no evidence yet) | ios-validation-runner, agent-browser, Chrome DevTools MCP |
When handing off, include the structured task list from Phase 2 / Phase 5 — don't ask the receiving skill to re-discover what we already know.
When spawning any subagent that captures or reviews UI evidence, include:
MANDATORY: Before marking any UI screen as PASS, invoke the `ui-experience-audit`
skill. Run all phases (0 triage → 1 visual defects → 2 interactive elements →
3 content quality → 4 UX heuristics → 5 synthesis). Decide mode (identify-
and-delegate vs drive-interaction) based on tool availability. Document
findings with severity, affected element, and suggested fix. State coverage
explicitly (which modes / viewports / states were audited). No screen passes
without all phases documented and coverage stated.
| Pattern | Why it's wrong | Do this instead |
|---|---|---|
| Confirming a screenshot exists without reading it | File existence proves nothing — a screenshot of a crash dialog is still a .png | READ every screenshot with the Read / View tool and describe what you see |
| Defining PASS criteria after viewing evidence | Confirmation bias makes you see what you expect | Define observable PASS criteria BEFORE capturing evidence |
| Stopping at Phase 1 because "the layout looks good" | Visual passes are common; functional/content/UX failures are where bugs live | Always run all phases — even pristine layouts hide false affordances and heuristic violations |
| Skipping Phase 0 triage to "save time" | Show-stoppers (broken images, lorem ipsum, missing chart bars) get buried under per-phase findings if not surfaced first | Always run the 30-second triage scan first; CRITICAL findings here gate everything else |
| Skipping Phase 2 because no live system | Identify-and-delegate mode still requires the inventory + reachability assessment from the screenshot alone | Run Phase 2 in light mode and produce a hand-off task list |
| Marking PASS based on a single screenshot | A clean light-mode desktop screen tells you nothing about dark mode, mobile, empty / error / overflow states | Always state coverage; route to PASS (LIMITED COVERAGE) when only one axis is audited |
| Marking LOW severity as "not worth fixing" | Cosmetic debt compounds | Log all severities; fix CRITICAL/HIGH immediately |
| Reviewing only happy-path screens | Empty / overflow / error / dark-mode states contain most defects | Audit empty, overflow, error, and dark-mode states explicitly |
| Treating UX heuristics as opinions | They're 30+ years of derived rules with explanatory power | Cite the specific heuristic number and name when reporting violations |
| Auditing code blocks visually but never trying to read them | Pretty syntax highlighting can fail contrast and still look "good" | Verify code-block contrast, monospace, copy affordance, language label, and mobile-wrap behaviour explicitly |
| Estimating contrast precisely from a screenshot | Without devtools, exact ratios aren't knowable; false confidence misleads | Use the rules-of-thumb in the contrast guidance; flag suspect cases for tooled verification |
| Assuming "expected content is rendering" because layout looks fine | Empty bordered containers, missing chart bars, broken <img> placeholders are common and easy to miss | Phase 0 explicitly checks "is the content that should be here, here?" |
visual-inspection instead (lighter, faster)full-functional-audit (this skill audits one screen at a time, full-functional-audit covers the entire app graph)visual-inspection — same Phase 1 protocol. If you only need visual QA, use that skill (lower overhead). Use this skill when interaction / content / UX matter too.functional-validation — exercises real system features end-to-end. This skill identifies what needs functional verification per screen; functional-validation actually drives the flows. Both are needed for a complete pass.full-functional-audit — app-wide functional inventory + execution. This skill is per-screen; full-functional-audit is per-app. Use full-functional-audit when auditing every screen + endpoint of an entire app.ui-ux-pro-max (if installed) — design-system compliance. This skill is broader (visual + interactive + content + UX); ui-ux-pro-max focuses on tokens and design system patterns.visual-inspection — pure visual QA (Phase 1 only); lighter alternativefunctional-validation — real-system feature exercise after Phase 2 hand-offfull-functional-audit — app-wide functional inventory and executiongate-validation-discipline — evidence-before-completion enforcementios-validation-runner — capture iOS simulator evidence to feed Phase 1–3e2e-validate — broader project validation across CLI, web, mobileverification-before-completion — completion-claim discipline