Run a broad web UI review for pages, flows, or component surfaces using audit categories such as layout hierarchy, content clarity, CTA emphasis, visual consistency, interaction states, responsiveness basics, performance signals, and accessibility basics. Use when the user asks to review a UI, audit a page, critique UX polish, check interface quality before launch, or turn vague design-feedback requests into a structured audit packet. Not for accessibility- only remediation, reusable component API design, system-level token governance, or React/runtime performance debugging. Triggers on: UI audit, design review, UX review, interface critique, polish review, landing-page review, dashboard review, usability review, visual consistency, CTA clarity.
Run a broad web UI review for pages, flows, or component surfaces using audit categories such as layout hierarchy, content clarity, CTA emphasis, visual consistency, interaction states, responsiveness basics, performance signals, and accessibility basics. Use when the user asks to review a UI, audit a page, critique UX polish, check interface quality before launch, or turn vague design-feedback requests into a structured audit packet. Not for accessibility- only remediation, reusable component API design, system-level token governance, or React/runtime performance debugging. Triggers on: UI audit, design review, UX review, interface critique, polish review, landing-page review, dashboard review, usability review, visual consistency, CTA clarity.
allowed-tools
Bash Read Write Grep Glob
compatibility
Best for frontend and fullstack web work where the main task is a broad page or flow review. Route specialized remediation to neighboring frontend skills when the issue is mainly accessibility, responsive layout, design-system governance, component architecture, or React behavior.
Use this skill when the question is "how good is this interface overall, what is creating friction, and what should we fix first?"
This is the repo's broad interface audit / design-review anchor.
It is not just a vendor-rule fetcher and it is not a replacement for specialized neighboring skills.
Review a landing page, dashboard, signup flow, settings page, or marketing site for broad interface quality
Turn "review my UI" or "audit this UX" into a structured audit instead of scattered opinions
Judge hierarchy, clarity, spacing, consistency, component-state quality, CTA emphasis, and task friction together
Check whether a screen or flow is ready for implementation, release, or stakeholder review
Compare a page against broad interface heuristics and practical implementation guidelines
Convert mixed findings into one prioritized UI audit packet with explicit handoffs
When not to use this skill
The main task is accessibility remediation, keyboard/focus behavior, labels, semantic HTML, or manual-vs-automated WCAG verification → use web-accessibility
The main task is viewport adaptation, overflow, breakpoint strategy, or container-aware layout behavior → use responsive-design
The main task is reusable primitive / slot / variant API design or controlled-vs-uncontrolled component architecture → use ui-component-patterns
The main task is system-level token governance, visual language, or component-library foundations → use design-system
The main task is React rendering, hydration, state churn, bundle/runtime behavior, or performance debugging → use react-best-practices or performance-optimization
The task is only to paste automated tool output with no design judgment; run the tool directly, then return here to interpret and prioritize
Core idea
Broad UI review works best when you:
define the review surface,
classify findings into stable categories,
separate broad interface issues from specialist remediation lanes,
prioritize by user friction and launch risk,
leave behind one concise audit packet.
Do not pretend one checklist, linter, or vendor guideline is the whole answer.
Use rule sources and heuristics as inputs, then make a judgment call.
Instructions
Step 1: Frame the review surface
Before judging the UI, identify what kind of surface is being reviewed.
Component cluster — consistency and state behavior across repeated controls, but not full component API design
Quick frame:
Review surface:
- Type: application screen + multi-step form
- Primary job: create a new workspace
- Main user risk: hidden next step, weak error recovery, inconsistent button hierarchy
If the request spans too many pages, choose a representative flow or top-priority screens first.
Step 2: Choose the review mode
Pick one primary mode so the review stays bounded.
Modes:
Launch-readiness audit — broad pre-release review with severity and fix ordering
