Critique Screen
Read 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.
/critique-screen[image path]A Claude Code slash command that reads the screenshot you point it at, applies the design-critique-checklist skill's seven areas, and writes a dated Markdown report to design/critiques/. If a critique of the same screen already exists it diffs against it, so you can see which findings were fixed and which came back.
Install to ~/.claude/commands/critique-screen.md
npx agentscamp add commands/critique-screenPoint this at a screenshot and get a written critique on disk. It runs the design-critique-checklist skill's seven areas over the image, gives every finding a severity and a fix, and saves the report so the next round can be compared against it. Claude Code's Read tool renders image files, so a PNG or JPG in your repo is readable the same way a source file is. The command writes one file and nothing else: it never edits your components, your styles, or the image.
Scope
Interpret $ARGUMENTS in this order:
- One image path (
.png,.jpg,.jpeg,.webp,.gif):Readit. That is the screen. The report name is the file's basename. - Several image paths separated by spaces: critique each, write one report per image, and add a short "Across screens" section at the end of the last report noting inconsistencies between them.
- A URL: you cannot fetch it with the tools this command has. Reply with one line asking for the file to be saved into the project, and stop.
- A path plus a phrase (
login.png mobile onboarding, exploration stage): the phrase is context. Use it for the Context line and to judge whether the visual hierarchy matches the screen's purpose. - Empty:
Globfordesign/**/*.png,**/screenshots/*.png, and**/*.pngat the repo root, list at most ten of the most recently modified matches, ask which one, and stop. Never pick for the user.
If Read fails on a path, say so and continue with the others. Do not substitute a similar filename.
NOTE
This is a design critique, not an accessibility audit. Contrast observations are tagged CHECK and never stated as a pass or a failure. For WCAG measurement run /audit-accessibility or the accessibility-auditor agent against the implemented component, where ratios and focus order can actually be computed.
Step 1 — Read the image and set the context
Read the image, then write the Context line: platform as it appears, apparent purpose of the screen, and the state shown (populated, empty, mid-flow). If a brief exists, Glob for design/briefs/*.md and read one whose name matches the image; judge hierarchy against the goal it states rather than against a general idea of a good screen. Say in the report whether a brief was found.
Step 2 — Run the checklist
Work the seven areas in order: hierarchy, spacing and alignment, typography, color and contrast (observed only), states, consistency, and copy. Assign severity deterministically. High: a user could fail the task or be misled, such as two competing primary actions, no error treatment on a form, or meaning carried by color alone. Medium: the task gets slower or more confusing. Low: polish. Every finding gets a location in the screen's own terms and one fix that addresses only that finding.
Step 3 — Diff against the previous critique
Glob for design/critiques/<basename>*.md. If an earlier report exists, read it and compare finding by finding. Classify each previous finding as Fixed (no longer visible), Open (still present), or Regressed (was absent in a later round and is back), and mark findings that appear for the first time as New. If no earlier report exists, say so in one line; do not invent a history.
Step 4 — Write the report
Write to design/critiques/<basename>-<YYYY-MM-DD>.md using the checklist's fixed format: title, Context, Summary counts, the findings table, Missing states, Works well, Not assessed, and the Since last critique section from step 3. Create design/critiques/ if it does not exist. Never overwrite an existing report; the dated filename is what makes the diff possible.
Output
The path written, the summary line (counts by severity), the High findings inline in the reply so they are visible without opening the file, and the since-last-critique counts. Then one next-step line: hand the implemented component to the accessibility-auditor agent for the checks this command deliberately leaves out. Setting the command up alongside the rest of a designer's Claude Code project is covered in Claude Code for designers, and the skill it wraps in Claude skills for designers.
Related
- Design Critique ChecklistCritique 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.
- Claude Code for Designers: Prototype in Code Without Becoming an EngineerWhy a designer opens a terminal agent, how to set it up safely, connecting Figma, a CLAUDE.md for a design-system repo, and three workflows with prompts.
- 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.
- 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.
- Audit AccessibilityAudit a component or page for accessibility against WCAG — semantics, names, keyboard, ARIA, contrast, forms, motion.
- 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.
- Figma to Code with Claude Code and the Figma MCP ServerConnect Figma's MCP server to Claude Code and turn a selected frame into a component that uses your real design tokens and your existing components.