agentleFS
caocong1caocong1/design-skill-lab/skills/critique-design/SKILL.md

critique-design

Skill8 starsChanged 47 days agoMITView on GitHub

Reviews, audits and scores an existing design or build like a senior design lead: a site, app screen, flow, component, brand asset, deck or graphic, from screenshots, a URL, mockups or a Figma export. Judges the render against the brief first, then checks the mechanical floor (computed contrast, overflow, targets, focus, states), and returns ranked findings (severity and evidence basis, Before | After | Why), rubric scores and a disposition: ship, fix, rebuild or recapture. Also the fresh-context critic for design-studio's own work, accessibility (WCAG 2.2) audits, and design QA that accepts a build against its handoff screenshots. 评审、设计评审、走查、体验走查、验收、设计验收、还原度检查、哪里不好、这个页面哪里不好看、无障碍检查、设计 QA、打分。Not for: making a new design or redesigning one (use design-studio); building or fixing a design in code (use implement-design); code review with no visual question.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Prefer a fresh subagent even for your own work: authors over-rate what they made.

    line 39
  2. Distinctive:

    Track B: Run or open the mechanical evidence and merge it with Track A.

    line 77
  3. Distinctive:

    Only screenshots of the build count, from any source (browser, simulator, device, golden test, a paste).

    line 127
  4. Distinctive:

    Never rewrite an issued finding to match what was built.

    line 151
  5. Distinctive:

    When this skill is corrected, fails or lacks something, follow design-studio's feedback: silent, lab inbox only, short retro.

    line 163

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Critique Design

Findings first; praise and summary after. A finding says what is wrong, where, why it matters to the user or the business, and what to do, with evidence someone else can check. Judge the rendered result against the brief and the surface contract. The author's intent is not evidence.

Modes

ModeUse whenInputOutput
reviewsomeone's product, site, screen, brand asset or deckURL, files or shots; capture the restreport and fix plan
freshdesign-studio (loop step 9) spawned you as its critica critic briefreport, disposition first
self-checkthe author checks their own workyour own rendersquick effort: floor + ★ heuristics; otherwise the full report, single-context
acceptance (was qa)a build is compared with its handoff shotshandoff + build shots, often via a critic briefacceptance report
redesign-brieffindings will feed a redesignas reviewreport + structural findings

Prefer a fresh subagent even for your own work: authors over-rate what they made. In self-check, write Track A before opening any tool output; the report starts Method: single-context (<reason>). redesign-brief weighs structure (heuristics section 2) as heavily as detail: detail fixes become every direction's baseline, and equity is what users rely on (learned locations, shortcuts, scanned data), not the layout. Findings feed redesign.

Two tracks, in this order

Track A: judgement, in a fresh context. It gets the brief (and PRODUCT.md), the surface contract, a screenshot manifest and the rubric. It does not get the conversation, the reasoning in decisions.md, drafts, rejected options or the author's self-assessment. Decide what you see before any number anchors you.

Track B: mechanical evidence, opened only after Track A is written. In ../design-studio/scripts/ (run each with --help first): lint.mjs (the deterministic floor on a rendered page), color_tools.py (contrast, matrix --from tokens.css, cvd for charts and status sets), capture.mjs (sizes x themes x states; non-zero exit on walls, blanks, errors), shot.sh (fallback). Installed alone: use what the host has (computed styles, axe, a contrast calculator) and name it. B wins on what it measures; A stands on what B cannot measure. Record agreements, what only B caught, and B's false positives. Floor items no tool checked are not verified: not passed.

Procedure

  1. Check the evidence. Open every file: right route, fully loaded (no spinner, wall or error page), intended font, declared size, theme, state and build stamp. Recapture a bad file yourself (step 2); if you cannot, the disposition is recapture: list what to capture and stop.
  2. Capture what is missing at the declared sizes and themes (defaults, traps: render-and-look), in every state you can trigger: focus by tabbing, hover, error, empty, loading, longest content, 200% zoom, reduced motion. Walk the primary task. Never judge from code alone or one shot; with code, cite the cause's file:line.
  3. State the yardstick from the brief: audience, job, attributes, platform, constraints. With no brief, infer the design read and label it inferred. Note what works; the fix plan keeps it. Brand work: .design/brand/strategy.md and the tests in brand section 4.
  4. Coverage pass (Track A). Walk the heuristics in order; run two or three personas. Then rationale against render: for each contract block (thesis, own-world, story, first viewport, form, finish line) and each claim in the critic brief, name the shot and region that delivers it: kept, partial or missing. A rationale the render does not show is design theater; partial and missing are findings. Write down every candidate; do not filter.
  5. Track B. Run or open the mechanical evidence and merge it with Track A.
  6. Vet pass. Re-open every cited location (shot region, selector, file:line) before a candidate becomes a finding. Drop false positives, fix wrong locations, merge repeats into one systemic finding, then grade it. Keep a one-line reason for each rejected candidate.
  7. Score with the rubric: floor, then ceiling, then the gate.
  8. Decide, crop, report: disposition, one crop per finding, report.

Personas: pick two or three, walk the primary task as each, name the element that broke

PersonaProbesPick for
Power usertask cost of the top jobs, keyboard path and shortcuts, bulk actions, skippable steps, slow motionadmin, data-dense, daily tools
First-timerfirst action clear within 5 s, unlabelled icons, jargon, proof of successonboarding, landing, forms
AT userkeyboard-only path, focus visible and unobscured, names, colour-only meaning, 200% zoomevery product surface
Stress tester0, 1 and 1,000 items, longest strings, mixed scripts, errors, refresh mid-flowtables, forms, checkout
Distracted mobilethumb reach, interrupt and resume, slow network, less typingconsumer mobile, mini-programs

Grading findings

SeverityMeaning
P0blocks the primary task; excludes users on a core path; legal exposure (unlicensed asset, fabricated claim, a required AI label missing); risk of data loss
P1major damage to comprehension, trust or conversion; systemic inconsistency; missing core states; unmet finish line. Would a user contact support? Then at least P1
P2noticeable polish or consistency problems; minor friction with a workaround
P3nits and opportunities
Evidence basisMeaning
verifiedmeasured, or visible in a named crop; anyone can re-check it
needs confirmationinferred from a still (hover, keyboard, motion, a likely consequence); say what would confirm it
human-requiredonly a person can settle it: real assistive-technology use, licence or trademark clearance, user research, truth of content

Also tag effort (S/M/L) and type: quick win, systemic (fix once in tokens or components), structural (needs a redesign). Word evidence as evidence ("当前页面显示…"), inference as inference ("这可能导致…").

Dispositions and rounds

DispositionWhen
shipthe floor passes, the rubric gate holds, no P0 or P1 is open
fixdirection and structure hold; give at most eight material fixes, in order
rebuildstructure or direction fails (Fit or Hierarchy at 2 or below, or the thesis is not delivered); fixes cannot reach the gate
recaptureevidence is missing or invalid; no verdict on the design

At most two rounds. Round 2 re-checks each round-1 finding against its own evidence shot, re-captured at the same size, theme and state: resolved, partial or unresolved, plus at most three regressions. Partial or unresolved never adds up to ship. After round 2, disclose what remains.

Accepting a build (acceptance)

Only screenshots of the build count, from any source (browser, simulator, device, golden test, a paste). With none, acceptance has not happened: say so.

  1. Pair each handoff shot (shots in handoff.json) with a build shot at the same logical size, DPR, theme, state and content, carrying the build stamp. A mismatched pair is recapture.
  2. Compare region by region: the named components of the spec's structure tree (data-component in the mockup), side by side, then overlaid (render-and-look section 8). Per region: match, adapted, missing, contradicted or added, with a crop. Spacing, type (face, size, weight, line height, tracking), colour tokens, radii, borders, shadows, each asset in its slot at its rendered size, content; then states, other sizes, motion. Tolerances: the spec's Acceptance section (default: one spacing step, exact tokens, fonts as specified). Anti-aliasing is noise.
  3. Each deviation: expected -> actual, screen > component, crop, severity, one class: build bug (differs from a clear spec: fix the build), spec gap (the handoff did not say: fix the handoff, never guess), platform difference (a system component or font renders differently: usually accept, record it in the spec).
  4. Say how each thing a still cannot show was checked (targets, focus order and visibility, screen-reader names, contrast, text scaling, reduced motion), then fill the acceptance report. ship needs every region match or adapted and no open P0 or P1; a region is fixed only on a re-captured build shot.

Conduct

  • Judge the work against the goal, never the person; be direct. Prefer the smallest fix that works.
  • Ten findings that matter beat forty. Scores track change, never people. Write in the user's language.
  • Never rewrite an issued finding to match what was built. The implementer answers it: fixed, with the re-captured evidence shot (same size, theme and state), or a deviation recorded in decisions.md.

Output

.design/critique/<date>-<target>/: report.md plus one crop per finding (NN-<slug>.png, enough context to locate it), committed; bulk captures stay in .design/shots/ (gitignored). Acceptance writes .design/handoff/<feature>/acceptance.md. The last report on the same target is the baseline for score changes. Quick work: the table in chat.

Feedback

When this skill is corrected, fails or lacks something, follow design-studio's feedback: silent, lab inbox only, short retro.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.