/ui-review

name: ui-review
description: "Full UI pass on one screen, dialog or flow: runs /flagrare:ux-audit, /flagrare:design-review and /flagrare:interaction-polish together, in that order, on the same browser session and the same screenshots, then ships ONE findings report (a single severity-ranked list, each finding tagged UX / Design / Interaction, overlaps merged) followed by the fixes it applied and the principle behind each. The first-time-user walk drives the real UI and gathers the evidence; the design lens diagnoses those screenshots (system coverage inventory, squint test, subtraction, ranked top 3); the interaction lens works on the interactions the walk found (press feedback, loading and transition states, frequency-gated motion, reduced motion). When a demo or before/after is part of the output it ships an MP4 recorded in real time with a visible cursor, never a GIF stitched from screenshots. Use when the user says 'UI review', 'review this screen', 'full pass on this page', 'audit and polish this', 'design and UX pass', 'make this screen good', 'run all three UI skills', or names one screen and asks for UX, design and feel in one go. Use a single source skill instead when only one lens is wanted."

UI Review

One target, three lenses, one report. A first-time user walks the screen, a senior product designer reads what the walk captured, an interaction designer tunes how it feels, and the result is a single ranked list with the fixes applied.

> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook. See `/flagrare:write-docs`.

This skill orchestrates three existing skills in sequence. It does not duplicate their logic: each one's rules still apply in full, and this file only says how they share evidence and how their findings merge.

---

When to Use

• The user names one screen, dialog or flow (running locally, or a URL) and wants usability, visual design and feel reviewed together
• After building a non-trivial UI, before handing it to design or review
• "UI review", "review this screen", "full pass on X", "audit and polish this", "make this page good"

Use a single source skill when only one lens is wanted. For a whole app with many routes, run `/flagrare:ux-audit` alone first; this skill is for one target at a time.

---

Rules carried from the source skills

Each of these governs its phase exactly as written in its own skill. Read the section there, do not paraphrase it away.

• **Coverage discipline** (`/flagrare:ux-audit`): the scoped area is walked exhaustively, every state and every visible affordance, no "seen enough". Scoped narrows *what* is covered, never *how thoroughly*.
• **First, respect the design system** and **remove, then demote, then quiet** (`/flagrare:design-review`): every fix uses the project's tokens and components, and quieting competitors comes before adding emphasis.
• **First, do no harm** and the **frequency gate** (`/flagrare:interaction-polish`): nothing on the user's path waits on motion, high-frequency actions get little or no animation, and every animation ships with its `prefers-reduced-motion` path.

---

Workflow

Step 0: Lock the goal (anti-stall)

**Hard requirement.** Before invoking any sub-skill, you (the executing model) MUST call `/goal` yourself. This is a three-skill chain with a long walk in the middle; without a durable goal the model stops after the walk. Phrase it so the evaluator can judge it from your output:

> The target `<target>` has been walked with `/flagrare:ux-audit` (every state and affordance in scope), diagnosed with `/flagrare:design-review` and `/flagrare:interaction-polish` on the same screenshots, merged into `.ui-review/REPORT.md` with one ranked, lens-tagged findings list, the in-scope fixes applied and re-verified by fresh screenshots, and the hand-off message sent. Stop after 40 turns if not met.

**One goal per session.** `/flagrare:ux-audit` normally sets its own goal; the `called by /flagrare:ui-review` argument in Step 2 tells it to skip that. Do not re-set the goal between steps. If `/goal` is unavailable, proceed without it.

Also create a Todo list with one item per step below, plus one item per state of the target once Step 2 enumerates them.

Step 1: Pin the target and the session

1. **Name the target** in one line: the route or URL, the screen or dialog, and for a flow, its start and end. Find its source files (the route file, the components it renders, the styles and tokens they use). A URL with no source in the repo is a report-only run: say so up front, the fixes become recommendations. 2. **Open one browser session** following `/flagrare:ux-audit`'s Prerequisites and Step 3 (Chrome DevTools MCP, one dedicated tab the user can watch, mobile-first viewport unless the target is desktop-only). This tab is the only one the three lenses use. 3. **Create `.ui-review/`** for all output: numbered screenshots, the UX lens's table, the merged report, and any video.

Step 2: Walk it with `/flagrare:ux-audit`

Invoke `/flagrare:ux-audit` with arguments starting `called by /flagrare:ui-review`, then the target, the output folder, and the extra captures the other two lenses need:

called by /flagrare:ui-review, scope: <target>, out: .ui-review/,
also capture: every data state (empty, partial, full, error), hover, focus and pressed
on each control, loading states under a throttled network, the target with
prefers-reduced-motion: reduce emulated, and an interaction inventory
(each interaction: trigger, what feedback it gives now, how often a real user hits it)

The walk is the one and only pass through the UI. Every screenshot the later lenses look at comes from it. If a later lens needs a state the walk missed, go back in the **same tab** and capture that one state, numbered after the last shot, then note it in coverage.

**Wait for the walk to finish.** It returns its findings table, its cov