open-design-critique

Get a design critic's second opinion on one Open Design artifact.

Request: the rest of the user's message (if there is none, ask the user: "Which design should get a second opinion?")

How to talk to the user. Many people using Open Design don't write code, so:

• Use the user's own words. If they say "artifact", "design tokens" or give a file path, use those terms back; otherwise use the plain words below.
• Keep the machinery out of replies: no tool names, no ids like od:prototype:poster-hero, no internal files (.artifact.json, .comments.json, config.json), and not the words "register", "manifest", "sidecar", "entry" or "surface", unless the user used them first.
• Explain a print term the first time it comes up, in one short clause, and not again.
• Say where a file is the way the user would find it ("in your Open Design folder, under seed-swap-flyer"). Give a raw path only where the user can click it (Claude Code, Claude Desktop's Code tab, VS Code) or asks for it.
• End each reply that finishes a step with one line on what they can do next, with at most two options ("Want it in Instagram sizes too, or is it ready to print?").

1. Find the artifact

Use the artifact the request names; if it names none, use the one you made or changed most recently in this conversation. Registered artifacts are the files under the Open Design output folder (default .open-design/) that have a .artifact.json file next to them. If it isn't registered yet, register it first with register_open_design_artifact.

2. Gather what the critic sees

Call get_open_design_artifact with its entryPath and critique: true. The result's critiqueInput holds the recorded brief (or, when there is none, the title and skill id), the design system's DESIGN.md, the latest saved check run's findings (including any taste and state findings) and its screenshot paths, and the last critique. The run's screenshots are attached.

If it says there is no saved check run, call check_open_design_artifact for the artifact first, fix any error it reports, then ask for the critique input again.

3. Get the critique

The critic judges only what is in critiqueInput and the screenshots, never what the builder meant. Pick the first of these your host has:

• The design-critic agent (Claude Code with the Open Design plugin; it may be listed as open-design:design-critic). Start it with the entry path, the critiqueInput JSON exactly as returned, and the screenshot and entry file paths written as full paths your own file tools can read. Add nothing about what you intended or what the user said beyond the recorded brief. It reads, it never edits.
• A general subagent tool (the Agent tool in Claude Code, runSubagent in VS Code). Give it the same material plus the rubric and output format below, and tell it not to edit any file.
• Neither: run it yourself, inline. Judge the attached screenshots against the rubric as if you had never seen the design before: look for what is on the screen, not for what you meant to put there. In your reply, call it a self-review ("I looked it over again myself"), since it is weaker than a fresh critic.

Rubric. Judge the screenshots first and the entry file only to confirm copy and states. Every finding names one of these areas:

The brief wins. When the brief or the design system asks for the look a finding objects to (all caps, one colour, a dense layout), drop the finding. Don't flag what the check already reported as an error unless it is still visible in the screenshots.

Verdict: one of

• ship: nothing worth another round.
• polish: one round of the listed fixes makes it right.
• rework: the direction is wrong (wrong audience, wrong kind of design, unreadable), and fixes won't save it.

Findings: at most five, most important first, each with area, where (the section, element, slide or viewport), problem (what is wrong, in one sentence) and fix (the change to make, specific enough to do without asking). Fewer is better than padding: a ship verdict usually has none.

Output: only this JSON, nothing before or after it:

{ "verdict": "polish", "findings": [{ "area": "copy", "where": "hero button", "problem": "\"Learn more\" doesn't say what happens.", "fix": "Say \"Start your free trial\"." }] }

4. Act on the verdict

• ship: the design is done. Record the critique (step 5) and tell the user.
• polish: apply every finding once with your own file-editing tools, register the artifact again (with the critique, step 5), run check_open_design_artifact, and fix any new error. Then report it done: don't ask for a second critique unless the user wants one.
• rework: don't rebuild yet. Record the critique, tell the user in a sentence or two what is wrong and what you would change, and ask whether to rebuild that way. Rebuilding is their call.

When the user asked for this opinion themselves, show them the verdict and findings and ask which to apply, instead of applying them straight away.

5. Record it

Pass the critique as critique (verdict and findings, as returned) on your next register_open_design_artifact call for the artifact, with the same other arguments as its last registration (kind, title, skill id, design system, format, supporting files). Only the latest critique is kept; it shows in the browser preview's Checks panel as "Second look". checkRunId and at are filled in for you. If registration rejects it as over 4 KB, shorten the findings and register again.

6. Tell the user

Keep it short and in everyday words: "I had a second look: …", then the top one or two things you improved (or, for rework, what's wrong), and nothing about rubric areas, verdict codes, file paths or tools. In Claude Desktop Chat and Cowork, say at most two findings and nothing more technical than that. Elsewhere, list every finding only if the user asks.

If the user says they don't want a second look on their designs, respect it for the rest of the conversation and skip this skill in the check step.