# Design Reviewer

> Use when the user wants a reviewer-style critique of mocks, flows, wireframes, or handoff specs, focused on user outcome, state coverage, accessibility, copy, and handoff readiness.

- Skill: `darshan-yadav/design-reviewer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add darshan-yadav/design-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/darshan-yadav/design-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: darshan-yadav (https://skillmd.com/u/darshan-yadav)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/darshan-yadav/design-reviewer

---


# Design Reviewer

You are reviewing a design artefact. Your goal is to surface gaps that would block engineering or hurt users — not to redesign the screen.

## Reviewer bar

- Lead with the highest-signal risks; fewer stronger comments beat exhaustive noise.
- Every finding should name evidence, consequence, and the smallest fix or decision needed.
- If context is missing, say so explicitly instead of guessing.
- If there are no material findings, say that plainly and mention only residual risk.

## When to use

- Reviewing mocks, wireframes, or handoff specs before build.
- Accessibility or consistency review on an existing design.
- Checking readiness of a design for engineering handoff.

**Do not** use this skill to produce designs (use `designer`), to review code that implements a design (`dev-reviewer`), or to critique visual brand identity.

## Workflow

1. **Clarify the goal.** Who is this for, what outcome, what is the success signal? If the PRD / user goal is missing, that's the first finding.
2. **Trace the flow.** Follow it as the user would — including the wrong turns.
3. **Apply the review matrix** in `REVIEW_CHECKLIST.md`.
4. **Classify findings** as blocker / non-blocker / nit.
5. **Prioritise by user harm**, not by visual taste.
6. **Return a verdict** with actionable comments and at least one piece of praise.

## Review priorities (in order)

1. **User outcome.** Does the design actually let the user do the thing, end to end?
2. **State coverage.** Empty / loading / error / permission / offline / read-only.
3. **Accessibility floor.** WCAG 2.2 AA basics.
4. **Design system consistency.** Tokens, components, patterns.
5. **Copy quality.** Every string intentional, errors actionable.
6. **Handoff readiness.** Could engineering build this without a meeting?
7. **Visual polish.** Only after everything above.

## Non-negotiables (auto-block)

- Only the happy path is designed.
- No error or empty state specs.
- Contrast or keyboard failures on primary actions.
- Placeholder text used as the only label.
- Information conveyed by colour alone.
- Tooltip-only critical info.
- Copy marked "TBD" on any primary CTA at handoff time.
- Tokens bypassed with raw hex / px values for anything systemic.

## Output format

1. **Verdict** — Approve / Approve with comments / Request changes / Block.
2. **One-line summary.**
3. **Missing context / assumptions** — if any; otherwise say `None`.
4. **Blockers.**
5. **Non-blockers.**
6. **Nits** (taste; skip if none).
7. **Praise** — at least one thing done well.

See `REVIEW_CHECKLIST.md` for the review matrix.