# SkillPatch skill: frontend-design-review

A dual-mode agent skill for frontend UI work: it can review existing UI implementations against design system standards, accessibility, and three quality pillars (Frictionless, Quality Craft, Trustworthy), or create distinctive, production-grade frontend interfaces from scratch with clear aesthetic direction. It provides structured workflows for design system compliance checks, PR/design reviews, and creative UI generation that avoids generic aesthetics.

You (the agent) were given this URL and asked to use this skill. This is a **public** skill — no SkillPatch account, API key, or prior setup is required. Two ways to use it:

**1. Use it right now** — the skill's complete file tree (SKILL.md + all reference files) is inlined below; read `SKILL.md` first, then follow it, consulting the other files as it directs.

**2. Install the exact package onto disk** (recommended if you can run a shell — this reproduces the skill byte-for-byte, including any binary assets that can't be inlined):

```bash
mkdir -p .claude/skills/frontend-design-review
curl -sSL https://skillpatch.dev/install_skill/frontend-design-review | tar -xz -C .claude/skills/
```

(`.claude/skills/` is Claude Code's convention; use whatever directory your agent loads skills from.)


---

## Skill files (5)

- `SKILL.md`
- `references/pattern-examples.md`
- `references/quick-checklist.md`
- `references/review-output-format.md`
- `references/review-type-modifiers.md`


### `SKILL.md`

```markdown
---
name: frontend-design-review
description: >
  Review and create distinctive, production-grade frontend interfaces with high design quality and design system compliance.
  Evaluates using three pillars: frictionless insight-to-action, quality craft, and trustworthy building.
  USE FOR: PR reviews, design reviews, accessibility audits, design system compliance checks, creative frontend design,
  UI code review, component reviews, responsive design checks, theme testing, and creating memorable UI.
  DO NOT USE FOR: Backend API reviews, database schema reviews, infrastructure or DevOps work, pure business logic
  without UI, or non-frontend code.
acknowledgments: |
  Design review principles and quality pillar framework created by @Quirinevwm (https://github.com/Quirinevwm).
  Creative frontend guidance inspired by Anthropic's frontend-design skill
  (https://github.com/anthropics/skills/tree/main/skills/frontend-design). Licensed under respective terms.
---

# Frontend Design Review

Review UI implementations against design quality standards and your design system **OR** create distinctive, production-grade frontend interfaces from scratch.

## Two Modes

### Mode 1: Design Review
Evaluate existing UI for design system compliance, three quality pillars (Frictionless, Quality Craft, Trustworthy), accessibility, and code quality.

### Mode 2: Creative Frontend Design
Create distinctive interfaces that avoid generic "AI slop" aesthetics, have clear conceptual direction, and execute with precision.

---

## Creative Frontend Design

Before coding, commit to an aesthetic direction:
- **Purpose**: What problem does this solve? Who uses it?
- **Tone**: minimal, maximalist, retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco, soft/pastel, industrial, etc.
- **Constraints**: Framework, performance, accessibility requirements.
- **Differentiation**: What makes this distinctive and context-appropriate?

### Aesthetics Guidelines

- **Typography**: Distinctive fonts that elevate aesthetics. Pair a display font with a refined body font. Avoid Inter, Roboto, Arial, Space Grotesk.
- **Color & Theme**: Cohesive palette with CSS variables. Dominant colors + sharp accents > timid, evenly-distributed palettes.
- **Motion**: CSS-only preferred. One well-orchestrated page load with staggered reveals > scattered micro-interactions.
- **Spatial Composition**: Asymmetry, overlap, diagonal flow, grid-breaking elements, generous negative space OR controlled density.
- **Backgrounds**: Gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, grain overlays.

**AVOID**: Overused fonts, cliched color schemes, predictable layouts, cookie-cutter design without context-specific character.

Match implementation complexity to vision. Maximalist = elaborate code. Minimalist = restraint and precision.

---

## Design Review

### Design System Workflow

**Before implementing:**
1. Review component in your Storybook / component library for API and usage
2. Use Figma Dev Mode to get exact specs (spacing, tokens, properties)
3. Implement using design system components + design tokens

**During review:**
1. Compare implementation to Figma design
2. Verify design tokens are used (not hardcoded values)
3. Check all variants/states are implemented correctly
4. Flag deviations (needs design approval)

**If component doesn't exist:**
1. Check if existing component can be adapted
2. Reach out to design for new component creation
3. Document exception and rationale in code

### Review Process

1. Identify user task
2. Check design system for matching patterns
3. Evaluate aesthetic direction
4. Identify scope (component, feature, or flow)
5. Evaluate each pillar
6. Score and prioritize issues (blocking/major/minor)
7. Provide recommendations with design system examples

### Core Principles

- **Task completion**: Minimum clicks. Every screen answers "What can I do?" and "What happens next?"
- **Action hierarchy**: 1-2 primary actions per view. Progressive disclosure for secondary.
- **Onboarding**: Explain features on introduction. Smart defaults over configuration.
- **Navigation**: Clear entry/exit points. Back/cancel always available. Breadcrumbs for deep flows.

---

## Quality Pillars

### 1. Frictionless Insight to Action

**Evaluate:** Task completable in ≤3 interactions? Primary action obvious and singular?

**Red flags:** Excessive clicks, multiple competing primary buttons, buried actions, dead ends.

### 2. Quality is Craft

**Evaluate:**
- Design system compliance: matches Figma specs, uses design tokens
- Aesthetic direction: distinctive typography, cohesive colors, intentional motion
- Accessibility: Grade C minimum (WCAG 2.1 A), Grade B ideal (WCAG 2.1 AA)

**Red flags:** Generic AI aesthetics, hardcoded values, implementation doesn't match Figma, broken reflow, missing focus indicators.

### 3. Trustworthy Building

**Evaluate:**
- AI transparency: disclaimer on AI-generated content
- Error transparency: actionable error messages

**Red flags:** Missing AI disclaimers, opaque errors without guidance.

---

## Review Output Format

See [references/review-output-format.md](references/review-output-format.md) for the full review template.

## Review Type Modifiers

See [references/review-type-modifiers.md](references/review-type-modifiers.md) for context-specific review focus areas (PR, Creative, Design, Accessibility).

## Quick Checklist

See [references/quick-checklist.md](references/quick-checklist.md) for the pre-approval checklist covering design system compliance, aesthetic quality, frictionless, quality craft, and trustworthy pillars.

## Pattern Examples

See [references/pattern-examples.md](references/pattern-examples.md) for good/bad examples of creative frontend and design system review work.

---

## Acknowledgments

Creative frontend principles inspired by [Anthropic's frontend-design skill](https://github.com/anthropics/skills/tree/main/skills/frontend-design). Design review principles and quality pillar framework created by [@Quirinevwm](https://github.com/Quirinevwm) for systematic UI evaluation.

```


### `references/pattern-examples.md`

```markdown
# Pattern Examples

## Creative Frontend (New Interfaces)

### Good: Clear Aesthetic Direction
- Landing page with brutalist aesthetic: Raw typography (Neue Haas Grotesk), stark black and white, asymmetric layouts
- Dashboard with organic theme: Rounded forms, earth tones, flowing animations, textured backgrounds

### Bad: Generic AI Aesthetic
- Overused fonts, cliched color schemes, centered content, generic card layouts

## Design System Review (Existing Work)

### Good: Frictionless
- Single primary button, clear task completion path

### Good: Quality Craft
- Uses design system with tokens, distinctive typography, keyboard accessible, tested in themes

### Bad: Quality Craft
- Hardcoded values, generic overused fonts, poor contrast in dark mode

```


### `references/quick-checklist.md`

```markdown
# Quick Checklist

Before approving any UI work:

## Design System Compliance
- [ ] Component verified in your Figma Design System
- [ ] Component implementation checked in your Component Library
- [ ] Figma Dev Mode specs followed (spacing, tokens, typography)
- [ ] Design tokens used (no hardcoded hex colors or pixel values)
- [ ] Token imports verified in code
- [ ] All variants/states implemented as designed in Figma
- [ ] Spacing measurements match Figma Dev Mode exactly
- [ ] Deviations documented with design approval

## Aesthetic Quality (especially for new designs)
- [ ] Clear conceptual direction (not generic overused fonts and cliched schemes)
- [ ] Distinctive typography (avoid overused fonts)
- [ ] Cohesive color palette with CSS variables
- [ ] Intentional motion (staggered reveals, hover states)
- [ ] Visual interest through composition (asymmetry, overlap, grid-breaking)
- [ ] Atmosphere through backgrounds (gradients, textures, patterns)
- [ ] Implementation complexity matches vision

## Frictionless
- [ ] Core task completable efficiently (≤3 interactions)
- [ ] Single clear primary action per view

## Quality Craft
- [ ] Uses design system components (verified in Figma)
- [ ] Design tokens used (no hardcoded values)
- [ ] Distinctive aesthetic (not generic overused fonts/cliched schemes)
- [ ] Accessible (Grade C minimum, Grade B ideal)
- [ ] Keyboard navigation complete
- [ ] Tested in light/dark/high contrast modes

## Trustworthy
- [ ] AI-generated content has disclaimer
- [ ] Error messages are actionable

```


### `references/review-output-format.md`

````markdown
# Review Output Format

```
## Frontend Design Review: [Component/Feature Name]

### Context
- **Purpose**: What problem does this solve? Who uses it?
- **Aesthetic Direction**: [If new design: describe the bold conceptual direction]
- **User Task**: What is the user trying to accomplish?

### Summary
[Pass/Needs Work/Blocked] - [One-line assessment]

### Design System Compliance (if applicable)
- [ ] Component exists in [Your Figma Design System]
- [ ] Component usage verified in [Your Component Library]
- [ ] Implementation matches Figma specs (spacing, colors, typography)
- [ ] Uses design tokens (not hardcoded values) - verified in code
- [ ] All variants match design system options
- [ ] Spacing verified against Figma Dev Mode
- [ ] Documented exception if deviating from design system

### Aesthetic Quality (especially for new designs)
- [ ] Clear conceptual direction (not generic AI aesthetic)
- [ ] Distinctive typography choices
- [ ] Cohesive color palette with CSS variables
- [ ] Intentional motion and micro-interactions
- [ ] Spatial composition creates visual interest
- [ ] Backgrounds and visual details add atmosphere

### Pillar Assessment

| Pillar | Status | Notes |
|--------|--------|-------|
| Frictionless | 🟢/🟠/⚫ | Task completion efficient, primary action clear |
| Quality Craft | 🟢/🟠/⚫ | Design system compliant, aesthetic distinctive, accessible |
| Trustworthy | 🟢/🟠/⚫ | AI disclaimers present, errors actionable |

**Legend:** 🟢 Pass | 🟠 Needs attention | ⚫ Blocking issue

### Design Critique
**Verdict:** [Pass / Needs work / Reach out to design for more support]

**Rationale:** [Brief explanation based on pillar assessment, design system compliance, and aesthetic direction]

**Criteria:**
- **Pass**: All pillars 🟢 or minor 🟠 that don't block user tasks, design system compliant, clear aesthetic direction
- **Needs work**: Multiple 🟠 or any critical workflow issues, design system deviations, or generic aesthetic choices
- **Reach out to design for more support**: Any ⚫ blocking issues, fundamental pattern problems, major design system violations, or need for aesthetic direction

### Issues

**Blocking (must fix before merge):**
1. [Pillar/Design System/Aesthetic] Issue description + recommendation with link

**Major (should fix):**
1. [Pillar/Design System/Aesthetic] Issue description + pattern suggestion with reference

**Minor (consider for refinement):**
1. [Pillar/Design System/Aesthetic] Issue description + optional improvement

### Recommendations
- [Design system component to use with link]
- [Specific code change with design token reference]
- [Typography recommendation for better aesthetic direction]
- [Motion/animation suggestion]
- [Link to design system in Figma]
```

````


### `references/review-type-modifiers.md`

```markdown
# Review Type Modifiers

Adjust focus based on review context:

## PR Review
- **Focus**: Code implementation, design system component usage, design token usage, accessibility in code
- **Check**: Proper imports, design tokens used (not hardcoded), ARIA attributes present
- **Verify**: Component matches Figma specs using Dev Mode

## Creative Frontend Review
- **Focus**: Aesthetic direction, typography choices, visual distinctiveness, motion design
- **Check**: Clear conceptual intent, avoiding generic AI patterns, cohesive execution
- **Verify**: Implementation complexity matches vision (maximalist needs elaborate code, minimalist needs precision)

## Design Review
- **Focus**: User flows, interaction patterns, visual hierarchy, navigation, design system alignment
- **Check**: Task completion path, action hierarchy, progressive disclosure
- **Verify**: All components exist in design system or have documented exceptions

## Accessibility Audit
- **Focus**: Deep dive Quality Craft pillar
- **Check**: Keyboard testing, screen reader testing, contrast ratios, ARIA patterns
- **Test with**: Screen readers (NVDA, JAWS, Narrator), keyboard only, 200% zoom
- **Verify**: Design system accessibility features are properly implemented

## Design System Compliance Audit
- **Focus**: Deep dive design system usage
- **Check**: All components match Figma specs, design tokens used throughout, no hardcoded values
- **Test**: Compare implementation side-by-side with Figma using Dev Mode
- **Verify**: Component variants, spacing, colors, typography all match design system
- **Document**: Any deviations with rationale and plan to align

```