Ui Review

ui-review — judge the pixels users actually see

Composes existing machinery: /ios-simulator or Playwright (capture), ios-design/TASTE.md (the 15 beauty laws), web-design/WEB.md (the web delta), ios-design/VERIFY.md (fresh-eyes protocol), /swiftui-craft or /web-craft (source checklist). This skill orchestrates and reports; it never fixes.

Named for the UI/UX split everyone already knows: this skill judges what the app LOOKS like, /ux-review judges how it WORKS, /journey-qa proves it runs. "Review the design" routes here; if the complaint is about flows, taps, or confusion rather than appearance, route to /ux-review instead.

Step 0 — Read first

1. Resolve the target repo (~/.claude/repo-map.md if named). Locate the

app target, its core screens (tab roots + the 2-3 deepest common flows), and any design system: docs/design/*/DESIGN.md, Theme/token files, project design skills. A system's own laws JOIN the TASTE.md laws as the rubric; no system → TASTE.md alone, and say so.

1. Read ~/.claude/skills/ios-design/TASTE.md (the rubric) and skim the

target's DESIGN.md laws if present.

1. Pick the lane and confirm the app runs.

• iOS lane: simulator available, scheme known (project run skill or

/run conventions).

• Web lane: a dev server, a production build, or a deployed URL, plus

Playwright (reuse the repo's if present — see web-design/RENDERER.md). The rubric gains web-design/WEB.md, and the source checklist becomes /web-craft rather than /swiftui-craft. If it cannot run, degrade honestly: source-only review plus any committed screenshots, and mark every pixel-law "NOT ASSESSED".

Step 1 — Capture evidence (the ground truth)

1. iOS: boot a simulator (/ios-simulator), consistent device (iPhone

Pro), simctl status_bar override (9:41, full battery). Launch the app. Web: start the server (or use the deployed URL) and drive Playwright with colorScheme set — that exercises prefers-color-scheme, the real mechanism, not a class toggle.

1. Screenshot every core screen in BOTH appearances. iOS: plus one

Dynamic Type stress pass on the 2 densest screens. Web: capture the THREE-viewport matrix (390 / 1024 / 1440) x both schemes — responsive failure is invisible at a single width — plus a 400ms and 1500ms capture on the 2 heaviest screens to catch post-load layout shift. Name files [-]-{light,dark}.png in a scratch dir.

1. Real data beats empty accounts: if a seeded/demo state exists, use it;

an empty-state-only review must say so.

Step 2 — Audit (three lenses)

1. Pixel lens (the core). For each screen pair, a fresh-eyes subagent

(VERIFY.md protocol: sees ONLY the PNGs + the rubric, never the source) audits against the TASTE.md laws — hue budget count, neutral dominance, pure-pole check, type channels/contrast ratio, tabular numerals, radii concentricity, density bimodality (dense-or-calm, flag the medium-medium slop zone), drama budget (name each screen's one dramatic surface — "none nameable" is a finding), plus the anti-pattern list. Verdict per screen: strongest law violations with locations.

1. Source lens. Run the /swiftui-craft checklist (iOS) or /web-craft

plus the Vercel web-interface-guidelines skill if installed (web) over the UI code (spacing scale, weights, semantic colors/token discipline, widget rules if any). Hardcode audit is grep-backed, not impressionistic: Color(hex:, Color(red:, .opacity(0. and raw .padding() outside the token/Theme file are each counted findings (cite count + worst offenders file:line).

1. Coherence lens. Cross-check: does the rendered app match its own

DESIGN.md laws and tokens? Divergence between stated system and shipped pixels is a first-class finding (cite both sides).

Step 3 — Report (the deliverable; report-only)

1. Ranked findings, most severe first, each as:

[law] — evidence (screenshot name / file:line) — minimal fix — where the fix lands (Theme token / kit component / screen) — the altitude rule: prefer one-token fixes that propagate.

1. Head the report with: an honest one-paragraph verdict ("how beautiful

is this app, really"), the top 3 highest-leverage beauty wins, and a per-law scorecard (pass / fail / not-assessed — never silently skip).

1. Close with routes, do not execute them: fixes → /swiftui-craft

(apply mode); redesign-level findings → /ios-design; theme-level → /skin-gallery; motion spec absent → note for DESIGN.md. Pairing note: this skill judges pixels; /ux-review judges the experience (taps, flows, habit ethics); /journey-qa proves function — the three together are the full pre-ship audit.

Does not do

• Fix anything (report-only; routes above), design mockups (/ios-design),

functional/journey QA (/journey-qa, /dogfood), App Store screenshot compliance (/app-store), performance.

• Praise inflation: a screen with no findings gets "clean under the

15-law rubric", not superlatives. Findings a founder would dispute need the evidence inline.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dndungu
• Source: dndungu/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.