UI Design Review
Judge the rendered product, not the source in isolation. A design review distinguishes standards failures, product-quality problems, and subjective preferences so the user can trust the verdict.
Mutation boundary
Review and audit requests are report-only. Inspect, execute read-only checks, and return evidence-backed findings without editing files. Change files only when the user asks to fix, polish, redesign, or implement, or when a parent workflow explicitly carries that authorized fix scope.
Establish the baseline
Read the affected UI, its tokens/components, supported themes, product context, and user-stated constraints. Capture the current rendered state before proposing a correction. Existing brand and system choices outrank generic taste; accessibility requirements do not.
When Impeccable is installed, reuse current hook findings and named refinement evidence. Do not run its detector again unless no current hook evidence exists or a specific fix needs rechecking.
Select review lanes
Read only the relevant references, resolved relative to this skill:
| Lane | Required reference |
|---|
| Contrast, semantics, keyboard, forms, motion, target size, or WCAG review | references/accessibility.md |
| Brand fidelity, content discipline, hierarchy, rhythm, system consistency, or generic-template review | references/visual-quality.md |
| Interactive states, responsive/theme coverage, runtime verification, or final polish | references/interaction-and-verification.md |
A full pre-ship review uses all three. A focused contrast question reads only accessibility. Complete every applicable lane before aggregating findings so early fixes do not hide later issues.
Run lanes in the current agent by default. When the session exposes agent tools and multiple read-only lanes are genuinely independent, the active agent may delegate the minimum useful number with non-overlapping ownership, then integrates and verifies the result itself. Tool availability never changes the review contract.
Findings contract
Deduplicate findings and classify them:
- Blocker — standards failure or interaction/accessibility defect that prevents safe use or completion.
- Quality issue — broken hierarchy, system inconsistency, missing state, misleading content, responsive/theme defect, or unearned template pattern with clear product impact.
- Advisory — subjective refinement or deterministic detector signal that needs human judgment.
Every finding names the affected surface, evidence, user impact, and concrete correction. Do not report a preferred aesthetic as a standards failure.
Fix and re-verify
When edits are authorized, fix blockers first, then in-scope quality issues. Preserve established tokens/components and avoid unrelated redesign. Re-run the actual interaction, affected viewport/theme/state matrix, exact contrast checks, and any focused automated check after edits. Detector output remains advisory even when a fix was requested.
Completion
Return a verdict—ready, ready after named decisions, or needs iteration—plus counts by classification, evidence for each unresolved item, authorized fixes applied, and explicit unverified states. A clean source scan without rendered interaction is not a completed UI review.
When not to use
- Generic code review, security review, backend/API review, or architecture critique
- Creating a new screen, flow, or visual direction; use
open-claude-ui-design
- Extracting tokens or component contracts; use
open-claude-design-system
- Logic-only UI changes that preserve the rendered interface
- Accessing a Claude Design project or preview; use
open-claude-design for retrieval, then return here for the review