Design Critique Checklist
Critique an attached screenshot or a described screen against a fixed seven-part checklist (visual hierarchy, spacing and alignment, typography, color and contrast as observed, empty, loading, and error states, consistency, and copy) and return findings in one set report format, each with a location, a severity, and a suggested fix, deferring every WCAG measurement to an accessibility audit. Use when you want a repeatable design review of a screen that reads the same from one round to the next.
Attach a screenshot or describe a screen and this skill critiques it against the same seven areas every time: hierarchy, spacing and alignment, typography, color and contrast, states, consistency, and copy. Each finding has a location, a severity, and a fix, in a fixed report format; contrast is observed here, never measured against WCAG.
Install to ~/.claude/skills/design-critique-checklist/SKILL.md
npx agentscamp add skills/design-critique-checklistA critique is more useful when the second one is shaped like the first. This skill runs a fixed checklist over a screenshot you attach (Claude reads image files in Claude Code, on claude.ai, and in Claude Cowork) or a screen you describe, and returns findings in one report format, so two rounds on the same screen, or the same round on two screens, can be compared line by line. Anthropic's design plugin has a design-critique skill that gives open-ended feedback and can pull a frame from Figma; this one trades breadth for a fixed shape, and it stays out of accessibility measurement on purpose. In a Claude Code project, the /critique-screen command runs it on an image file and writes the report to disk.
When to use this skill
- You want a first-pass review before showing a screen to a person, with the obvious problems already listed.
- A design review is coming and you need every screen assessed the same way.
- A screen shipped and you want a written record of what fresh eyes noticed.
NOTE
Color and contrast findings here are observations ("the helper text looks low-contrast on the gray card") and are always tagged CHECK, never PASS or FAIL. WCAG measurement, keyboard order, and screen-reader behavior belong to the accessibility-auditor agent or the accessibility-regression-auditor skill, which work from code and compute ratios. The critique never claims conformance.
Instructions
- State what you are looking at. Platform, apparent purpose of the screen, the state shown (populated, empty, mid-flow), and what cannot be seen: hover and focus states, motion, other breakpoints, the rest of the flow. This becomes the "Not assessed" section, written first so the reader knows the limits.
- Hierarchy. What the eye lands on first, second, third; whether that order matches the screen's purpose; how many elements compete to be the primary action. A screen with two equally weighted primary buttons is a finding.
- Spacing and alignment. Whether gaps follow a consistent step, edges align across sections, groups read as groups, and anything looks cramped or stranded. Describe locations in the screen's own terms ("second card, bottom padding"); you cannot measure pixels from an image.
- Typography. How many sizes and weights appear, whether they form a readable hierarchy, line length in the widest text block, line height in body text, and any truncation or wrapping problems visible.
- Color and contrast (observed). How many colors are in play, whether color carries meaning consistently (one red for errors, one accent for actions), and any pair that looks hard to read, tagged CHECK with a pointer to the auditor.
- States. Which of empty, loading, error, success, and disabled are shown, which are implied but missing, and for each missing state what the design needs to specify. A form with no visible error treatment is a High finding.
- Consistency. With itself first (one component styled two ways on one screen), then with the design system if the user describes one or pastes a token list.
- Copy. Headings, labels, and button text at a glance: does the label say what happens, does the heading say what the screen is. Deeper review of the strings goes to the ux-copy-reviewer skill.
- Assign severity deterministically. High: a user could fail or be misled (primary action unclear, missing error state, meaning carried by color alone). Medium: the task gets slower or more confusing. Low: polish. Each finding gets one suggested fix that addresses only that finding.
- Assemble the fixed report below. Include two or three items under "Works well" so a reader knows what to keep.
# Critique: <screen name>
Context: <platform> · <purpose> · <state shown>
Summary: <N> findings (<H> High, <M> Medium, <L> Low). <one line>
## Findings
| # | Area | Location | Finding | Severity | Suggested fix |
| --- | --- | --- | --- | --- | --- |
## Missing states
## Works well
## Not assessedOutput
One report in the format above, ready to paste into a review thread or save as design/critiques/<screen>.md, which is what /critique-screen does for you in Claude Code. Findings are ordered by severity, then by area, so the same problem lands in the same place in every report.
Example
Excerpt from a critique of a settings screen described as "desktop, billing tab, populated":
Summary: 6 findings (2 High, 3 Medium, 1 Low). Clear layout; the save action and the error path need work.
| # | Area | Location | Finding | Severity | Suggested fix |
| --- | --- | --- | --- | --- | --- |
| 1 | Hierarchy | Footer | "Save" and "Cancel" share the same filled style | High | Make Cancel a text or outline button |
| 2 | States | Billing email field | No error treatment visible for an invalid address | High | Specify inline error text below the field |
| 3 | Color | Helper text under card number | Light gray on white looks low-contrast | Medium (CHECK) | Confirm ratio with the accessibility auditor |
## Not assessed
Hover and focus states, mobile layout, the confirmation step after Save.Claude skills for designers shows where the critique sits in the designer set.
Related
- Claude Skills for Designers: 5 to Upload TodayFive Claude skills for designers: brief, critique, token extraction, component spec, and UX copy review. What each returns, a prompt for each, and upload steps.
- UX Copy ReviewerReview a set of interface strings you paste in (buttons, labels, empty states, errors, confirmations, tooltips) as one set rather than one at a time, checking clarity, term consistency across screens, error and empty-state quality, whether each action label matches what happens, and length against any limits you supply, and returning a verdict and a rewrite per string without inventing a product fact the strings do not contain. Use when microcopy has accumulated across a product and nobody has read it end to end.
- Anthropic's Design Plugin for Claude: Every Skill ExplainedEvery skill in Anthropic's open-source design plugin for Claude Cowork and Claude Code, the connectors it expects, the install commands, and what it leaves out.
- Critique ScreenRead a UI screenshot from a path or URL, run the fixed design critique checklist over it, and write the report to design/critiques/ without touching the design or the code.
- Accessibility AuditorUse this agent to audit web UI against WCAG 2.2 AA — semantics, keyboard, ARIA, contrast, forms, and motion. Examples — auditing a new component for keyboard traps, checking a form for accessible errors, running a pre-ship a11y pass on a page.
- Accessibility Regression AuditorAudit a UI change for accessibility regressions by combining automated checks with keyboard, focus, semantic, name-role-value, contrast, zoom, and screen-reader-oriented inspection. Use when reviewing a component or pull request, adding a dialog or form, changing navigation, or investigating an accessibility failure that a linter alone cannot explain.
- Design Brief WriterTurn a messy design request you paste in (a Slack thread, an email chain, meeting notes, a ticket) into a one-page design brief: goal, audience, constraints, success criteria, scope and non-goals, references needed, open questions, and timeline placeholders, with every item the source did not state marked as an inference and no constraint or deadline invented. Use when a request has arrived in fragments and the brief has to exist before design work starts.