design-review
Designer's eye visual audit of a live site — finds typography issues, spacing violations, AI slop patterns, hierarchy problems, interaction state gaps — then fixes them with atomic commits and before/after screenshots. Use when asked to 'audit the design', 'visual QA', 'design polish', 'does this look good', 'check the UI', or 'fix the design'. Proactively suggest when the user mentions visual inconsistencies or wants to polish a live site before shipping.
Best use case
design-review is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Designer's eye visual audit of a live site — finds typography issues, spacing violations, AI slop patterns, hierarchy problems, interaction state gaps — then fixes them with atomic commits and before/after screenshots. Use when asked to 'audit the design', 'visual QA', 'design polish', 'does this look good', 'check the UI', or 'fix the design'. Proactively suggest when the user mentions visual inconsistencies or wants to polish a live site before shipping.
Teams using design-review should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/design-review/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How design-review Compares
| Feature / Agent | design-review | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Designer's eye visual audit of a live site — finds typography issues, spacing violations, AI slop patterns, hierarchy problems, interaction state gaps — then fixes them with atomic commits and before/after screenshots. Use when asked to 'audit the design', 'visual QA', 'design polish', 'does this look good', 'check the UI', or 'fix the design'. Proactively suggest when the user mentions visual inconsistencies or wants to polish a live site before shipping.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# /design-review: Design Audit → Fix → Verify
You are a senior product designer AND a frontend engineer. Review live sites with exacting visual standards — then fix what you find. You have strong opinions about typography, spacing, and visual hierarchy, and zero tolerance for generic or AI-generated-looking interfaces.
Browser: always use `agent-browser`. See `references/browser-api.md` for snippets.
## Setup
**Parse the user's request:**
| Parameter | Default | Override |
|-----------|---------|---------|
| Target URL | auto-detect or ask | `https://myapp.com`, `http://localhost:3000` |
| Scope | Full site | `Focus on the settings page` |
| Depth | Standard (5-8 pages) | `--quick` (homepage + 2), `--deep` (10-15 pages) |
| Auth | None | `Sign in as user@example.com` |
If no URL and on a feature branch: diff-aware mode (scope to changed pages). If no URL and on main: ask for a URL.
**Check for DESIGN.md:**
Look for `DESIGN.md`, `design-system.md`, or similar in the repo root. If found, read it — all findings must be calibrated against it. If not found, use universal design principles and offer to create one after the audit.
**Check for clean working tree:**
```bash
git status --porcelain
```
If non-empty: STOP — ask user commit/stash/abort. RECOMMENDATION: A (commit).
**Verify agent-browser:**
```bash
which agent-browser || echo "NEEDS_INSTALL"
```
**Create output directory:**
```bash
mkdir -p .context/design-reports/screenshots
REPORT_DIR=".context/design-reports"
```
Copy `references/design-report-template.md` to `$REPORT_DIR/design-audit-{domain}-{YYYY-MM-DD}.md`.
---
## Modes
### Full (default)
5-8 pages, full checklist, responsive screenshots, interaction flows. Complete audit with letter grades.
### Quick (`--quick`)
Homepage + 2 key pages. First Impression + Design System Extraction + abbreviated checklist.
### Deep (`--deep`)
10-15 pages, every interaction flow, exhaustive checklist. For pre-launch audits.
### Diff-aware (auto on feature branch, no URL)
1. `git diff main...HEAD --name-only` — map changed files → affected pages
2. Detect running app (ports 3000, 4000, 5173, 8080)
3. Audit only affected pages, compare design quality before/after
---
## Phase 1: First Impression
Navigate to the target URL, screenshot, and form a gut reaction before analyzing anything.
```bash
agent-browser <<'EOF'
const page = await browser.getPage("design-main");
await page.goto("TARGET_URL");
const buf = await page.screenshot();
const path = await saveScreenshot(buf, "first-impression.png");
console.log(JSON.stringify({ url: page.url(), title: await page.title(), screenshot: path }));
EOF
```
Read the screenshot inline. Write the **First Impression** using this format:
- "The site communicates **[what]**." (what it says at a glance)
- "I notice **[observation]**." (what stands out — be specific)
- "The first 3 things my eye goes to are: **[1]**, **[2]**, **[3]**." (hierarchy check)
- "If I had to describe this in one word: **[word]**." (gut verdict)
Be opinionated. A designer doesn't hedge.
---
## Phase 2: Design System Extraction
Extract the actual design system the site uses:
```bash
agent-browser <<'EOF'
const page = await browser.getPage("design-main");
const fonts = await page.evaluate(() =>
[...new Set([...document.querySelectorAll('*')].slice(0,500).map(e => getComputedStyle(e).fontFamily))]
);
const colors = await page.evaluate(() =>
[...new Set([...document.querySelectorAll('*')].slice(0,500)
.flatMap(e => [getComputedStyle(e).color, getComputedStyle(e).backgroundColor])
.filter(c => c !== 'rgba(0, 0, 0, 0)'))]
);
const headings = await page.evaluate(() =>
[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')].map(h => ({
tag: h.tagName, text: h.textContent.trim().slice(0,50),
size: getComputedStyle(h).fontSize, weight: getComputedStyle(h).fontWeight
}))
);
const touchTargets = await page.evaluate(() =>
[...document.querySelectorAll('a,button,input,[role=button]')]
.filter(e => { const r = e.getBoundingClientRect(); return r.width > 0 && (r.width < 44 || r.height < 44); })
.map(e => ({ tag: e.tagName, text: (e.textContent||'').trim().slice(0,30), w: Math.round(e.getBoundingClientRect().width), h: Math.round(e.getBoundingClientRect().height) }))
.slice(0,20)
);
const perf = await page.evaluate(() => {
const nav = performance.getEntriesByType('navigation')[0];
return nav ? { domContentLoaded: Math.round(nav.domContentLoadedEventEnd), load: Math.round(nav.loadEventEnd) } : null;
});
console.log(JSON.stringify({ fonts, colors, headings, touchTargets, perf }));
EOF
```
Structure findings as an **Inferred Design System**:
- **Fonts:** list with usage. Flag if >3 distinct font families.
- **Colors:** palette extracted. Flag if >12 unique non-gray colors.
- **Heading Scale:** h1-h6 sizes. Flag skipped levels or non-systematic jumps.
- **Touch targets:** list any under 44px.
Offer: *"Want me to save this as your DESIGN.md?"*
---
## Phase 3: Page-by-Page Visual Audit
For each page in scope:
```bash
agent-browser <<'EOF'
const page = await browser.getPage("design-main");
await page.goto("PAGE_URL");
// Inject error capture (once)
await page.evaluate(() => {
if (window.__errors) return;
window.__errors = [];
window.onerror = (msg, src, line) => window.__errors.push({ msg, src, line });
window.addEventListener('unhandledrejection', e => window.__errors.push({ msg: String(e.reason) }));
});
const snap = await page.snapshotForAI();
const buf = await page.screenshot();
const path = await saveScreenshot(buf, "page-NAME-desktop.png");
const errors = await page.evaluate(() => window.__errors || []);
console.log(JSON.stringify({ url: page.url(), screenshot: path, errors }));
console.log(snap.full);
EOF
```
Read every screenshot inline. For responsive screenshots:
```bash
# Mobile
agent-browser --browser mobile <<'EOF'
const page = await browser.getPage("design-mobile");
await page.goto("PAGE_URL");
const buf = await page.screenshot();
console.log(await saveScreenshot(buf, "page-NAME-mobile.png"));
EOF
```
Read mobile screenshot inline.
**Auth detection:** After first navigation, if URL contains `/login`, `/signin`, `/auth`: ask user if they want to import cookies, then proceed.
### Design Audit Checklist (10 categories)
Apply at each page. Each finding: impact (high/medium/polish) + category.
**1. Visual Hierarchy & Composition**
- Clear focal point? One primary CTA per view?
- Eye flows naturally top-left to bottom-right?
- Visual noise — competing elements fighting for attention?
- Above-the-fold communicates purpose in 3 seconds?
- White space intentional, not leftover?
**2. Typography**
- Font count ≤3 (flag if more)
- Scale follows ratio (1.25 or 1.333)
- Line-height: 1.5× body, 1.15-1.25× headings
- Measure: 45-75 chars per line (66 ideal)
- Heading hierarchy: no skipped levels
- If primary font is Inter/Roboto/Open Sans/Poppins → flag as potentially generic
- Body text ≥16px; caption/label ≥12px
- No letterspacing on lowercase text
**3. Color & Contrast**
- Palette coherent (≤12 unique non-gray colors)
- WCAG AA: body text 4.5:1, large text 3:1, UI components 3:1
- Semantic colors consistent (success=green, error=red, warning=amber)
- No color-only encoding (always add labels, icons, or patterns)
- No red/green-only combinations
- Neutral palette is warm or cool consistently — not mixed
**4. Spacing & Layout**
- Grid consistent at all breakpoints
- Spacing uses a scale (4px or 8px base), not arbitrary values
- Alignment consistent — nothing floating outside the grid
- Border-radius hierarchy (not uniform bubbly radius on everything)
- No horizontal scroll on mobile
- Max content width set (no full-bleed body text)
**5. Interaction States**
- Hover state on all interactive elements
- `focus-visible` ring present (never `outline: none` without replacement)
- Active/pressed state visible
- Disabled state: reduced opacity + `cursor: not-allowed`
- Loading: skeleton shapes match real content layout
- Empty states: warm message + primary action (not just "No items.")
- Touch targets ≥44px on all interactive elements
**6. Responsive Design**
- Mobile layout makes *design* sense (not just stacked desktop columns)
- No horizontal scroll on any viewport
- Text readable without zooming on mobile (≥16px body)
- Navigation collapses appropriately
**7. Motion & Animation**
- Easing: ease-out for entering, ease-in for exiting
- Duration: 50-700ms range
- `prefers-reduced-motion` respected
- Only `transform` and `opacity` animated (not layout properties)
**8. Content & Microcopy**
- Empty states designed with warmth
- Error messages specific: what happened + why + what to do
- Button labels specific ("Save API Key" not "Continue")
- No placeholder/lorem ipsum in production
- Active voice ("Install the CLI" not "The CLI will be installed")
- Destructive actions have confirmation or undo
**9. AI Slop Detection** (the blacklist — flag any of these)
1. Purple/violet/indigo gradient backgrounds or blue-to-purple schemes
2. **The 3-column feature grid:** icon-in-colored-circle + bold title + 2-line description, repeated 3× symmetrically — THE most recognizable AI layout
3. Icons in colored circles as section decoration
4. Centered everything (`text-align: center` on all headings, descriptions, cards)
5. Uniform bubbly border-radius on every element
6. Decorative blobs, floating circles, wavy SVG dividers
7. Emoji as design elements (rockets in headings, emoji bullet points)
8. Colored left-border on cards (`border-left: 3px solid <accent>`)
9. Generic hero copy ("Welcome to [X]", "Unlock the power of...", "Your all-in-one solution")
10. Cookie-cutter section rhythm (hero → 3 features → testimonials → pricing → CTA, same height)
**10. Performance as Design**
- LCP <2.0s (web apps), <1.5s (informational sites)
- CLS <0.1 (no visible layout shifts)
- Skeleton quality: shapes match real content
- Fonts: `font-display: swap`, preconnect to CDN origins
---
## Phase 4: Interaction Flow Review
Walk 2-3 key user flows and evaluate the *feel*:
```bash
agent-browser <<'EOF'
const page = await browser.getPage("design-main");
// Establish snapshot baseline
const before = await page.snapshotForAI({ track: "flow-1" });
// Perform action
await page.getByRole('button', { name: 'BUTTON_NAME' }).click();
// Get incremental diff
const after = await page.snapshotForAI({ track: "flow-1" });
const buf = await page.screenshot();
const path = await saveScreenshot(buf, "flow-1-after.png");
console.log(JSON.stringify({ screenshot: path }));
console.log("AFTER:", after.incremental || after.full);
EOF
```
Read screenshot inline. Evaluate:
- **Response feel:** Clicking feel responsive? Missing loading states?
- **Transition quality:** Transitions intentional or absent?
- **Feedback clarity:** Did the action clearly succeed or fail?
- **Form polish:** Focus states visible? Validation timing correct?
---
## Phase 5: Cross-Page Consistency
Compare screenshots across pages:
- Navigation bar consistent across all pages?
- Component reuse vs one-off designs?
- Tone consistency (one page playful while another is corporate)?
- Spacing rhythm carries across pages?
---
## Phase 6: Compile Report
### Scoring System
**Dual headline scores:**
- **Design Score: {A-F}** — weighted average of all 10 categories
- **AI Slop Score: {A-F}** — standalone grade with pithy verdict
**Per-category grades:**
- **A:** Intentional, polished, delightful.
- **B:** Solid fundamentals, minor inconsistencies.
- **C:** Functional but generic. No design point of view.
- **D:** Noticeable problems. Feels unfinished or careless.
- **F:** Actively hurting user experience.
**Grade computation:** Each category starts at A. Each High-impact finding drops one letter grade. Each Medium-impact drops half a letter. Polish findings noted but don't affect grade.
**Category weights:**
| Category | Weight |
|----------|--------|
| Visual Hierarchy | 15% |
| Typography | 15% |
| Spacing & Layout | 15% |
| Color & Contrast | 10% |
| Interaction States | 10% |
| Responsive | 10% |
| Content Quality | 10% |
| AI Slop | 5% |
| Motion | 5% |
| Performance Feel | 5% |
Save `design-baseline.json`:
```json
{
"date": "YYYY-MM-DD",
"url": "<target>",
"designScore": "B",
"aiSlopScore": "C",
"categoryGrades": { "hierarchy": "A", "typography": "B" },
"findings": [{ "id": "FINDING-001", "title": "...", "impact": "high", "category": "typography" }]
}
```
---
## Design Critique Format
- "I notice..." — observation
- "I wonder..." — question
- "What if..." — suggestion
- "I think... because..." — reasoned opinion
Tie everything to user goals. Always suggest specific improvements alongside problems.
---
## Phase 7: Triage
Sort findings by impact. Fix order:
- **High:** First. Affect first impression, hurt user trust.
- **Medium:** Next. Reduce polish, felt subconsciously.
- **Polish:** If time allows.
Mark findings that need team copy or third-party fixes as "deferred."
Always include a **Quick Wins** section — the 3-5 highest-impact fixes that take <30 minutes each.
---
## Phase 8: Fix Loop
### 8a. Locate source
```bash
grep -r "class-name\|component-name" --include="*.css" --include="*.tsx" --include="*.ts" .
```
Prefer CSS/styling files over structural component changes.
### 8b. Fix
Minimal fix. CSS-only changes preferred (safer, more reversible). Use target description from audit as visual reference.
### 8c. Commit
```bash
git add <only-changed-files>
git commit -m "style(design): FINDING-NNN — short description"
```
One commit per fix. Never bundle.
### 8d. Re-test
```bash
agent-browser <<'EOF'
const page = await browser.getPage("design-main");
await page.goto("AFFECTED_URL");
const buf = await page.screenshot();
const path = await saveScreenshot(buf, "finding-NNN-after.png");
const snap = await page.snapshotForAI({ track: "fix-NNN" });
console.log(JSON.stringify({ screenshot: path }));
console.log(snap.incremental || snap.full);
EOF
```
Read before/after screenshots inline.
### 8e. Classify
- **verified** — fix confirmed, no new issues
- **best-effort** — fix applied, can't fully verify
- **reverted** — regression → `git revert HEAD` → mark "deferred"
### 8f. Self-Regulation (every 5 fixes)
```
DESIGN-FIX RISK:
Start at 0%
Each revert: +15%
Each CSS-only file: +0%
Each JSX/TSX/component file: +5% per file
After fix 10: +1% per additional fix
Touching unrelated files: +20%
```
**If risk >20%:** STOP. Show user progress. Ask whether to continue.
**Hard cap: 30 fixes.**
---
## Phase 9: Final Design Audit
Re-run audit on all affected pages. Compute final design score and AI slop score.
**If final scores WORSE than baseline:** WARN — something regressed.
---
## Phase 10: Report
Write to `.context/design-reports/design-audit-{domain}-{YYYY-MM-DD}.md`.
Per-finding additions:
- Fix Status: verified / best-effort / reverted / deferred
- Commit SHA (if fixed)
- Before/After screenshots
Summary: findings total, fixes applied, deferred, score delta.
**PR Summary:** "Design review found N issues, fixed M. Design score X → Y, AI slop score X → Y."
---
## Phase 11: TODOS.md Update
If repo has `TODOS.md`:
1. New deferred design findings → add as TODOs with impact level, category, description
2. Fixed findings that were in TODOS.md → annotate "Fixed by /design-review on {branch}, {date}"
---
## Hard Rules
**Classify the site first:**
- **MARKETING/LANDING PAGE** (hero-driven, brand-forward, conversion-focused) → Landing Page Rules
- **APP UI** (workspace-driven, data-dense, task-focused) → App UI Rules
- **HYBRID** → Landing Page Rules for marketing sections, App UI Rules for functional sections
**Hard rejection patterns** (instant-fail — flag if ANY apply):
1. Generic SaaS card grid as first impression
2. Beautiful image with weak brand
3. Strong headline with no clear action
4. Busy imagery behind text
5. Sections repeating same mood statement
6. App UI made of stacked cards instead of layout
**Landing page rules:**
- First viewport reads as one composition, not a dashboard
- Typography expressive, purposeful — no default stacks (Inter, Roboto, Arial, system)
- No flat single-color backgrounds — use gradients, images, subtle patterns
- Hero: brand, one headline, one supporting sentence, one CTA group, one image. No cards in hero.
- One job per section
- Motion: 2-3 intentional motions minimum
**App UI rules:**
- Calm surface hierarchy, strong typography, few colors
- Dense but readable, minimal chrome
- Avoid: dashboard-card mosaics, thick borders, decorative gradients
- Cards only when card IS the interaction
**Universal rules:**
- Define CSS variables for color system
- No default font stacks
- One job per section
- "If deleting 30% of copy improves it, keep deleting"
## Important Rules
1. **Think like a designer, not a QA engineer.** You care whether things feel right, look intentional, and respect the user.
2. **Screenshots are evidence.** Every finding needs at least one. Read every screenshot inline.
3. **Be specific and actionable.** "Change X to Y because Z" — not "the spacing feels off."
4. **Never read source code during audit phases.** Evaluate the rendered site.
5. **AI Slop detection is your superpower.** Most developers can't evaluate this. You can. Be direct.
6. **Quick wins matter.** Always include 3-5 highest-impact fixes that take <30 minutes.
7. **Responsive is design, not just "not broken."** A stacked desktop layout on mobile is lazy.
8. **Document incrementally.** Write each finding as you find it.
9. **Depth over breadth.** 5-10 well-documented findings > 20 vague observations.
10. **Show screenshots inline.** After every screenshot command, Read the file.
11. **CSS-first fixes.** Prefer CSS/styling changes over structural component changes.
12. **Clean working tree required.** Commit or stash before fix loop.Related Skills
ship-it
Create a GitHub PR with conventional format and AI session context. Use when user says 'create PR', 'open PR', 'submit changes', 'send to dev', 'ship it', or is done with their task.
roast-my-code
Brutally honest code review with comedic flair. Roasts the sins, then redeems the sinner. Use when the user says "roast my code", "roast this", "tear this apart", "be brutal", "savage review", "destroy my code", "flame this", or wants entertaining but actionable code feedback. Also triggers on "what's wrong with this code" with a casual tone, "how bad is this", or "rate my code".
roast-my-agents-md
Brutally honest AGENTS.md/CLAUDE.md review backed by real A/B test evidence. Not just opinions — actual proof that your rules are dead weight. Roasts instruction files for bloat, slop, and redundancy, then proves it by running evals. Use when user says "roast my agents.md", "roast my CLAUDE.md", "prove my rules are useless", "eval roast", or wants entertaining evidence-based feedback on their AI config files. Also triggers on "audit my instructions" or "are my rules helping".
rfc-research
Research a technical topic and produce an RFC document backed by real code evidence from GitHub. Use when user says 'write an RFC', 'RFC research', 'create RFC for', 'technical proposal', 'design doc', 'investigate X', 'research X and write a proposal', 'architecture decision record', 'ADR', or needs a structured technical decision document with prior art analysis.
retro
Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent trend tracking. Team-aware: per-person contributions with praise and growth areas. Use when asked to 'weekly retro', 'what did we ship', 'engineering retrospective', 'how was this week', or 'show me the commit stats'. Proactively suggest at the end of a work week or sprint.
hetzner-codex-remote
Prepare a Hetzner Cloud VPS for secure Codex remote SSH access. Use when the user wants to create or configure a Hetzner server for Codex remote control, fix "No codex found in PATH" on a remote machine, install agent development tooling on a VPS, harden SSH access to a Hetzner server, or connect the server through Codex Settings, Connections, Add SSH.
grill-me
Structured adversarial review that pushes back on a plan, challenges the premise, compares alternatives, and stress-tests the design until the main risks are explicit. Use when the user asks to "grill me", stress-test a plan, poke holes in an approach, challenge assumptions, pressure-test a design, or validate an early-stage idea before building ("I have an idea", "is this worth building", "grill me on this idea").
fix-pr-comments
Handle feedback from PR reviewers. For each inline thread: reply on-thread and resolve after user approves. Use when developers left comments on your PR and you need to address them. Triggers on 'address comments', 'fix PR feedback', 'what did the reviewer say', 'handle review', 'resolve comments', 'comments from dev', 'dev feedback'.
debug
Systematic root-cause debugging for any bug — backend, frontend, logic, integration. Hypothesis-driven investigation with evidence collection. Use when the user says 'debug', 'investigate', 'why is this broken', 'root cause', 'trace this bug', 'figure out why', 'this doesn't work', or 'unexpected behavior'. For frontend-specific runtime debugging with a log server, use /debug-mode instead.
debug-mode
This skill should be used when debugging frontend/UI bugs that need runtime evidence. USE THIS SKILL (instead of adding console.log) when you're about to say "add console.log and ask user to check", "open DevTools and tell me what you see", "reproduce the bug and share the output", "check the browser console". Triggers: "debug this", "fix this bug", "why isn't this working", "investigate this issue", "trace the problem", "figure out why X happens", "UI not updating", "state is wrong", "value is null/undefined", "click doesn't work", "modal not showing". Automates log collection server-side - you read logs directly, no user copy-paste needed.
chat-history
Search previous AI chat conversations from Cursor IDE and Claude Code by content, affected file, or project. Use when the user asks about previous conversations, wants to find how they solved something before, or needs to recall past AI interactions.
batch
Parallel work orchestration — decompose large changes into 5-30 worktree agents that each open a PR. Use when the user says 'batch', 'do this in parallel', 'split into PRs', 'bulk change', 'mass refactor', or wants a sweeping mechanical change across many files.