UX

Audit or plan a UI the way a product reviewer does: start from what the user is trying to get done, prove what the code does, then add accessibility depth. Read every target file completely before reporting on it.

Modes

Step 0 — Scope

1. Resolve the target: the user's named files, else the changed UI files (git diff --name-only <base>...HEAD), else the current file.
2. Detect the platform: web (<div>, CSS, Tailwind), React Native (View, Pressable, expo-router), or both. Ask when ambiguous.
3. Read the target files, then the handlers, hooks, stores, routes, and API calls they reach — Pass 1 depends on them.

Pass 1 — The user's path (first, always)

Outcome-changing findings (a broken flow, a control that does the wrong thing, a dead end) come from this pass, not from the checklist. Follow rules/user-path.md (why the path comes first: references/path-first.md):

1. Name the page's job and the primary user task in one sentence each.
2. Walk the task end to end in the code, from entry to the next step after success.
3. For each control on the path, read its handler and state changes, and compare what it does with what the UI promises.
4. Cover empty, loading, stale, error, and first-run states.
5. Check the activation / next-step path: can the user actually do what the page tells them to do next?
6. Note what already works — the report keeps it.

Pass 2 — Accessibility and interaction depth

Follow rules/accessibility.md on every interactive element Pass 1 touched:

• Contrast computed from the actual tokens and resolved colors, in every theme.
• Focus management on open, close, delete, and route change.
• Live regions: what is announced, how often, and whether it floods.
• ARIA roles and patterns, keyboard paths, touch targets, reduced motion.

Load the extra rule files only when the code contains the trigger:

A missing companion skill never blocks; log <name> — skipped (not installed) and continue.

Verify before reporting

Every claimed behaviour cites the file:line that proves it. When the code cannot prove it statically, label the finding unverified and say what would confirm it. Details and examples: rules/verify-before-reporting.md.

For a Critical or High finding about motion, timing, focus order, or hover-revealed content, Skill("screencast") may capture evidence (a recording.json whose id is the finding's file-line); append its .mp4 path as a Recording: line.

Report

Use templates/review-report.md.

1. Order findings by impact on the primary task — a broken step outranks a contrast miss.
2. Put a severity label (Critical / High / Medium / Low) on each finding; severity is a label, not the document's section structure.
3. Give every finding file:line, what the user experiences, and a concrete fix (code when the fix is code).
4. Include What works (keep), a Plan (first three moves), and How we'll know it worked (one measurable signal per top item).
5. Report at most ten findings; merge duplicates and drop nitpicks before cutting a real issue.

Hard rules

1. Never recommend a dark pattern; if asked to add one, refuse, name the harm, and give the honest alternative (rules/dark-patterns.md).
2. Never assert behaviour you did not read in the code.
3. Never apply an iOS rule to Android code or the reverse.
4. Match the bar to the context: a prototype gets the path and blockers, a production surface gets AA in full.