Use to review a design / UI change against its specification. Read-only; produces findings, applies no fixes.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add patforna/auto-task --skill review-design --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Review Design?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/patforna-review-design)More formats (shields.io, HTML) on the badges page.
---
name: review-design
description: "Use to review a design / UI change against its specification. Read-only; produces findings, applies no fixes."
---
# Review Design
## Usage
`/at:review-design [the change + its design intent]`
## Prerequisite
Requires chrome-devtools MCP. If not available, do not proceed and fail loudly.
## Goal
Verify a design / UI change matches the specified design.
## Guidance (DO NOT IGNORE!)
- Skip entirely for changes that don't alter rendered output.
- Read-only: surface findings, never fix.
## Step 1: Start the App
Start the app on deterministic fixture data and drive it via the chrome-devtools MCP.
The serve command comes from the project config (`.claude/auto-task.config.md`, design-review section) — e.g. a recipe that serves test fixtures. If no such entry exists, look for an obvious fixture-backed dev-server; if none, fail loudly — do not review against live/non-deterministic data.
Prefer a serve command that binds free ports (so parallel sessions don't collide) and navigate to the URL it prints — don't assume a fixed port.
## Step 2: Verify
1. **Measure, Don't Eyeball.** Read DOM geometry / computed styles (`getBoundingClientRect`, colour, contrast) and compare to the spec.
2. **Check Token Fidelity.** Read the diff, not just the render — flag hardcoded literals where a token was specified (e.g. `#3B82F6` instead of `var(--color-primary)` or a `bg-primary` utility). Computed styles collapse the token name, so this is a source-level check.
3. **Confirm the Gestalt** with a screenshot against the design reference. Save the frames — one per state×theme the change actually touches, plus open interaction states (tooltip/popover) — under `.design-review/<task-or-slug>/` (ensure it's gitignored) so the human can review them without re-booting the app. The chrome-devtools screenshot tool only writes within the repo workspace root, so save there even when reviewing a worktree (not under the worktree path).
4. **Exercise Interaction States** (hover / focus / open) with *real* input (real key/click events) — synthetic dispatch hides state-dependent bugs. Also cover the data / UI states the design defines (disabled / error / empty / loading), driven via the fixtures.
5. **Check for Unguarded Invariants** — load-bearing geometry / colour with no e2e assertion.
## Step 3: Output
Findings only — no edits. Match `/at:review-code`'s format so downstream triage consumes code and design findings uniformly:
- Severity: Critical / Major / Minor / Nit
- One-line finding + cited evidence (the measured number vs the spec, or the screenshot deviation)
- For an unguarded invariant: name the e2e assertion to add — the fix happens downstream, not here
- Reference the saved screenshot paths (Step 2.3) so the reader can open the frames alongside the findings
No autofix lane: design findings aren't mechanically certain, so every one goes through full triage.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!