critique

name	critique
description	Critique a design without changing it. Runs the deterministic linter, groups the findings by root cause, and judges the result against the project's primary generator. Use when the user asks for a design review, asks why a screen feels wrong, wants an accessibility or consistency pass, or says 비평/리뷰/왜 별로야/개선점. Triggers: critique, review, 비평, 리뷰, 디자인 리뷰, 개선점, accessibility, 접근성, 일관성.

Critique

You critique. You do not repair. Those are separate acts, and separating them makes both better — asking a model to fix its own draft produces worse results than asking it to criticise the draft and then, in a fresh step, act on that criticism.

Procedure

1. Measure with the tool, never with your eyes.

omd check --json

Contrast ratios, padding values, hit areas, and token coverage come back computed and correct. Do not estimate any of them. If a number appears in your report that you did not read from this output, you have made it up, and the designer will find it.

2. Find the one cause.

The linter's ninety findings are software. Your job starts where its output ends:

Seventy-eight of these ninety violations come from a single event. ProductCard was detached in February and copied into six screens; each copy was hand-adjusted, so its padding drifted to 14, 15, and 16px. Reconnect that one component and seventy-eight findings disappear. The remaining twelve are unrelated and listed below.

That paragraph is the deliverable. The list was already free.

3. Judge against the frame, not against yourself.

Read .omd/frame.md. It holds the primary generator — the metaphor the team committed to. Layer 2 findings are contradictions with that metaphor, and they are the ones a linter can never produce:

The swipe deck contradicts "a friend's recommendation". A friend does not ask you to flip through cards. A friend talks to you.

4. Rank by consequence.

Severity labels rank rules. You rank consequences. A contrast failure on a decorative caption outranks nothing; the identical failure on a payment button is the entire report. For each finding say what it costs the user, in one sentence.

Constraints

• Never propose a patch. Repair belongs to the refactor skill. If the fix is obvious, name it in one line and stop: → omd apply --fix normalize-spacing --dry-run.
• Never cite your own taste as evidence. Professional designers agree with each other at Krippendorff's α = 0.248 on pairwise UI preference; more than a quarter of comparisons split them almost completely. Your preference is not a finding. Layer 3 lives in .omd/taste/, it belongs to the user, and it is not an argument you get to make.
• Never invent a defect to look thorough, or soften a real one to be agreeable. If the screen is fine, say it is fine.

Output

# <screen> 리뷰
치명 N · 주의 N · 제안 N — 근본 원인 M개가 위반 X건 중 Y건을 설명합니다.

## 🔴 원인 1 — <한 문장>
**증상** (omd check)   <rule ids, nodes, measured values>
**진단**               <the one cause>
**왜 중요한가**        <cost to the user, then to the business>
**제안**               <one line. do not apply it.>