Design Review
Run a visual polish pass on a web page or app with browser screenshots and a structured findings report before you ship or demo.
Overview
Design Review is an agent skill most often used in Ship (also Build, Launch) that audits visual design quality—layout, type, spacing, colour, and responsiveness—and returns a screenshot-backed findings report, not a UX w
Install
npx skills add https://github.com/jezweb/claude-skills --skill design-reviewWhat is this skill?
- Checks layout, typography, spacing, colour, hierarchy, consistency, interaction patterns, and responsive behaviour
- Produces a design findings report with screenshots—not a UX friction audit
- Resolves live or deployed URLs (prefers non-localhost) like ux-audit
- Auto-detects Chrome MCP, Playwright MCP, or playwright-cli for captured evidence
- Explicit companion to ux-audit: run usability first, then visual polish
- Evaluates eight visual dimensions named in the skill: layout, typography, spacing, colour, hierarchy, consistency, inter
Adoption & trust: 825 installs on skills.sh; 841 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped UI that works but still looks uneven, cramped, or “developer-designed,” and you cannot name what to fix.
Who is it for?
Indie builders with a live or staging URL who want a structured visual critique before showing work or marking a feature complete.
Skip if: Teams that need usability, IA, or task-completion analysis—use a UX audit skill instead; skip when you only need brand strategy with no UI to inspect.
When should I use this skill?
Triggers include ‘design review’, ‘does this look good’, ‘review the design’, ‘check the layout’, ‘is this polished’, ‘visual review’, ‘design audit’, ‘make it look better’, and ‘it looks off’.
What do I get? / Deliverables
You get prioritized visual design findings with screenshots so you can polish the interface before demos, handoff, or release.
- Design findings report with prioritized visual issues
- Screenshot evidence per finding
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship → review because the skill gates “done” and pre-launch quality, even though you often invoke it right after finishing UI in Build. Subphase review matches code/design review workflows—not usability (UX audit)—and pairs naturally after implementation before security or launch prep.
Where it fits
After implementing a dashboard grid, capture breakpoints and spacing before merging the PR.
Before marking a feature done, run visual checks on staging to catch inconsistent cards and type scale.
Polish the marketing landing page layout and colour hierarchy the day before a Product Hunt or client walkthrough.
Quarterly sweep of production pages when drift in components makes the product feel less premium.
How it compares
Use for visual polish and consistency checks, not as a substitute for UX friction or accessibility workflow audits.
Common Questions / FAQ
Who is design-review for?
Solo and indie builders shipping web UIs with Claude Code who want a second pair of eyes on aesthetics, spacing, and responsive polish before stakeholders see the product.
When should I use design-review?
After finishing a feature in Build (frontend), before client demos in Launch (distribution), when a page looks wrong but you cannot diagnose it, for periodic checks on shipped products, or immediately after a UX audit when you still need visual consistency.
Is design-review safe to install?
Review the Security Audits panel on this Prism page for install risk and file hash details; the skill needs browser automation against URLs you supply, so only point it at environments you control.
SKILL.md
READMESKILL.md - Design Review
# Design Review Review a web app or page for visual design quality. This is not a UX audit (usability, workflow, friction) — this checks whether the design is **professional, consistent, and polished**. The goal: would a design-conscious person look at this and think "this is well made" or "this looks like a developer designed it"? ## When to Use - Before showing something to a client or team - When something "looks off" but you can't pinpoint why - After building a feature, before calling it done - Periodic quality check on a shipped product - After a UX audit — this is the visual companion ## Browser Tool Detection Same as ux-audit — Chrome MCP, Playwright MCP, or playwright-cli. ## URL Resolution Same as ux-audit — prefer deployed/live over localhost. ## What to Check ### 1. Layout and Spacing | Check | Good | Bad | |-------|------|-----| | **Consistent spacing** | Same gap between all cards in a grid, same padding in all sections | Some cards have 16px gap, others 24px. Header padding differs from body | | **Alignment** | Left edges of content align vertically across sections | Heading starts at one indent, body text at another, cards at a third | | **Breathing room** | Generous whitespace around content, elements don't feel cramped | Text touching container edges, buttons crowded against inputs | | **Grid discipline** | Content follows a clear column grid | Elements placed freely, no underlying structure | | **Responsive proportions** | Sidebar/content ratio looks intentional at every width | Sidebar takes 50% on tablet, content is squeezed | | **Vertical rhythm** | Consistent vertical spacing pattern (e.g. 8px/16px/24px/32px scale) | Random spacing: 13px here, 27px there, 8px somewhere else | ### 2. Typography | Check | Good | Bad | |-------|------|-----| | **Hierarchy** | Clear visual difference between h1 → h2 → h3 → body | Headings and body text look the same size/weight | | **Line length** | Body text 50-75 characters per line | Full-width text running 150+ characters — hard to read | | **Line height** | Body text 1.5-1.7, headings 1.1-1.3 | Cramped text or excessive line height | | **Font sizes** | Consistent scale (e.g. 14/16/20/24/32) | Random sizes: 15px, 17px, 22px with no relationship | | **Weight usage** | Regular for body, medium for labels, semibold for headings, bold sparingly | Everything bold, or everything regular with no hierarchy | | **Truncation** | Long text truncates with ellipsis, title attribute shows full text | Text overflows container, wraps awkwardly, or is cut off without ellipsis | ### 3. Colour and Contrast | Check | Good | Bad | |-------|------|-----| | **Semantic colour** | Using design tokens (bg-primary, text-muted-foreground) | Raw Tailwind colours (bg-blue-500, text-gray-300) | | **Contrast ratio** | Text meets WCAG AA (4.5:1 for body, 3:1 for large text) | Light grey text on white, or dark text on dark backgrounds | | **Colour consistency** | Same blue means the same thing everywhere (primary = action) | Blue means "clickable" in one place and "informational" in another | | **Dark mode** | All elements visible, borders defined, no invisible text | Elements disappear, text becomes unreadable, images look wrong | | **Status colours** | Green=success, yellow=warning, red=error consistently | Green used for both success and "active" with different meanings | | **Colour overuse** | 2-3 colours + neutrals | Rainbow