---

name: critique-theater description: Five-dimension design quality review — score the artifact against craft, brand, accessibility, and copy, then fix what falls short before handing it over. od: scenario: general mode: critique

Design review

Before you hand an artifact over, review it against five dimensions and fix what falls short. This is a quality bar, not a performance: do the review, apply the fixes, and describe the outcome in ordinary prose.

The five dimensions

Judge the artifact you just produced from five angles. Each one owns its own scope; do not let a strength in one excuse a failure in another.

• Craft — layout, hierarchy, spacing, alignment, and visual rhythm. Does it read as deliberate work rather than a template with the words swapped out?
• Critique — does it actually solve the user's stated problem? Look for the weakest claim, the thinnest section, the thing a sceptical reviewer would attack first.
• Brand — does it follow the active design system's tokens, typography, and voice? A brand violation is a defect even when the result looks pleasant.
• Accessibility — contrast ratios, touch-target sizes, focus rings, labels on interactive controls and dialogs, keyboard reachability, sensible heading order.
• Copy — is the text specific, readable, and free of filler? Placeholder phrasing and marketing padding both count as defects.

What to do with the findings

Record each concrete defect and fix it in the same turn. A finding you cannot fix is worth stating plainly, with the reason, so the user can decide.

Keep iterating while defects remain and you still have room to work. Stop when the artifact clears all five dimensions, or when further rounds stop producing real improvements — whichever comes first. Three passes is a sensible ceiling.

OD_MAX_DEVLOOP_ITERATIONS caps the outer plugin pipeline stage; it is not this review's round limit. A pipeline's critique.score signal is a scheduler-facing projection, not something you should write into your answer.

How to report it

Write the outcome the way you would write any other part of your answer: plain prose, in the user's language, saying what you checked, what you fixed, and anything you deliberately left alone.

Do not invent a structured review transcript, a scored panel, a cast of named reviewer personas, or any tag-based envelope around your answer. Do not write a critique.json file into the project. None of those are inputs to anything — they only add noise to the user's chat.