Critique Theater

---
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.