review-ui

name	review-ui
description	Reviews an existing UI (file, URL, screenshot, code, or description) against the full UI_MASTER_GUIDE.md — hierarchy, spacing, typography, color, depth, forms, patterns, mobile, copy, and WCAG 2.2 accessibility. Auto-activates on "review my UI", "critique this design", "audit this page", "is this design good", "what's wrong with this screen", or /uix:review-ui. Produces a categorized findings list with severity, source citations, and fix recommendations.
argument-hint	[file, URL, or description]
version	0.1.0
allowed-tools	Read, Grep, Glob

review-ui

Conduct rigorous UI reviews against the master guide. Auto-activates on UI-review requests or via /uix:review-ui.

Triggers

"review my UI / design / component / page / screen" · "critique this" · "audit this" · "is this design good" · "what's wrong with this screen" · "does this follow best practices" · "grade my UI".

Process

1. Ingest the target. File path → Read. URL → ask the user for a screenshot or rendered HTML (don't fetch live unless explicitly asked). Screenshot provided → analyze visually. Description only → treat as a verbal spec, note assumptions.

2. Load the checklist from ${CLAUDE_PLUGIN_ROOT}/references/UI_MASTER_GUIDE.md Part XIV (60-second pre-ship checklist). Work through each category.

3. Evaluate along these axes (skip sections that don't apply):

   • Clarity & scannability [DMMT]
   • Visual hierarchy (weight+color, not size alone) [RUI]
   • Spacing & layout (fixed scale, breathing room, grid discipline) [RUI]
   • Typography (scale, line length, line-height, baseline alignment) [RUI]
   • Color (systemic palette, value contrast, color-only meaning) [RUI][IOC]
   • Depth & shadows (tinted shadows, consistent light source) [RUI][C&L]
   • Forms (labels visible, errors actionable, progressive disclosure) [DI][DMMT]
   • Navigation & IA (persistent nav, breadcrumbs, escape hatches) [DMMT][DI]
   • Pattern choice — is the right Tidwell pattern being used? [DI]
   • Mobile (target sizes, thumb zones, reflow) [DI][WCAG]
   • Content & copy (jargon, happy talk, action-oriented) [DMMT][UXB]
   • Accessibility (WCAG 2.2 AA) — delegate deep check to accessibility-audit skill if issues are dense.

4. Output format:

   ## UI Review — <target>
   
   ### Summary
   One-paragraph verdict. Top 3 priorities.
   
   ### Critical (must fix before ship)
   - [Category] **Issue** — Why it fails · Source · Fix.
   
   ### Warnings (should fix)
   - [Category] ...
   
   ### Suggestions (nice-to-have)
   - [Category] ...
   
   ### Strengths
   - What the design already does well — keep these.
   
   ### Next steps
   - 2-3 concrete next actions.
   

5. Assign severity honestly:

   • Critical — broken experience, WCAG AA failure, lost conversions, broken keyboard path.
   • Warning — violates a named principle; slows users; brittle at scale.
   • Suggestion — polish, edge-case, or style preference.

6. Every finding must cite a source tag — no unsourced opinions.

Ground rules

• Critique the design, not the designer. No sarcasm.
• Name strengths too — reviews that are only negative lose signal.
• If the design violates a WCAG 2.2 AA criterion, that's Critical, not Warning.
• If you're unsure (e.g., only have a screenshot), say so and list which axes you couldn't evaluate.
• When multiple issues share a root cause, group them — don't pad the list.
• Suggest a specific fix, not just "improve hierarchy".

Handoffs

• Accessibility-deep → accessibility-audit skill.
• Needs a new component design → design-component skill.
• Needs pattern selection → choose-pattern skill.
• Color-system problems → color-system skill.