# Verbs that judge

> Use review for a verdict and a Before | After | Why table, tells for a deletion list of AI defaults, and a11y for an evidence-only accessibility audit, and know what each returns.

Module: The /design-engineering toolkit · Level: beginner · 8 min · https://school.agents.org.in/design/toolkit/verbs-that-judge

Three verbs read your work and report. None of them edits a line unless you ask afterwards. That's the deal: you get an honest assessment, and you decide what changes.

## review

**Reach for it** when something is done, or a change is ready to merge, and you want to know if it's right.

*[Interactive demo: review: a verdict on the first line, then three to five rows of before, after and why.]*

```bash
/design-engineering review src/PricingCard.tsx
```

**What it does.** It reads the review format, the 39-row checklist, your gotchas and your pov, in that order. Then it quotes your real lines into the Before column, runs every checklist row against them, and turns each failure into a row.

**What comes back:**

1. **A verdict, first line.** *Blocked* (an interaction or accessibility-floor failure), *Approve with changes*, or *Ship it*.
2. **The Before / After / Why (The table a design-engineering review comes back in: the exact line, its replacement, and one sentence of reason. One problem per row) table.** Three to five rows. Twelve rows aren't actionable.
3. A one-line lede if the issues share a theme.

Rows are ranked in a fixed order: interaction, accessibility floor, layout stability, motion, spacing, type, surface, component API, performance, polish. If there are more than three, they're grouped under Blocking, Should fix and Nits.

> **Point it at a branch.** Give it a branch, a pull request or nothing at all with uncommitted work, and it becomes a change-scoped review: a Status column (Introduced, Regression, Pre-existing), the removed lines read for lost signals, and at most three pre-existing findings.

*("Ship it, nothing to change" is a valid review. Invented nitpicks are not.)*

**Hand off** when motion is most of the problem (`motion`), when the question is "does this look AI-made?" (`tells`), or when it's the whole app before launch (`ship`).

## tells

**Reach for it** when a screen looks like every other generated page and you can't say why.

*[Interactive demo: tells: a numbered deletion list, then one line on what to enlarge so the page isn't left thin.]*

```bash
/design-engineering tells app/page.tsx
```

**What it does.** It picks the surface and reads only that surface's notes: a page, a screenshot, copy, code or a dashboard each have their own catalogue of AI-default tells. Then it runs the unslop pass in order.

**What comes back:** a deletion list (A numbered list of things to remove or replace, highest impact first, each with where it is and why. What the tells verb returns instead of a redesign). Numbered, highest impact first, each item saying what to remove or replace, where it is, and which node names the tell. Gradient text, the generated-page purple, a tiny tracked-caps label above every heading, emoji as icons, "John Doe" in a testimonial.

**Every tell you remove must leave something better behind.** Stripping a page and leaving a thin screen of nothing is its own failure, so the list ends with what to keep or enlarge.

  **A redesign (avoid):**

"Here's a new direction with a warmer palette and a serif headline."

  **A deletion list (do this):**

"1. Remove bg-clip-text on the h1 (solid ink). 2. Swap indigo-to-purple for the brand accent. 3. Delete the FEATURES eyebrow. Keep the product shot; enlarge it."

`tells` never proposes a new visual direction on its own. If you want one after the scan, that's `options`.

## a11y

**Reach for it** when you need to know who your interface locks out, and you want proof rather than opinions.

*[Interactive demo: a11y: every row tied to a WCAG criterion, or honestly labelled a preference.]*

```bash
/design-engineering a11y components/Dialog.tsx
```

**What it does.** It reads the accessibility baseline and the WCAG (The Web Content Accessibility Guidelines, the standard most laws point to. Its contrast rule is the familiar 4.5:1 for body text and 3:1 for large text) thresholds, then only what the target contains: widgets get keyboard maps, toasts get live-region checks, motion gets reduced-motion checks, colour gets contrast.

**What counts as a finding:** a WCAG criterion it fails, or a behaviour you can reproduce (focus escapes the dialog; the toast is never announced). Anything else is labelled a *preference*.

**What comes back:** the review table with a **Criterion** column (`4.1.2 A`, `1.4.3 AA`, or "preference"), most severe first.

> **Severity follows the criterion.** A 36px icon button on desktop meets the 24×24px minimum (criterion 2.5.8). 44px is a recommendation, never the top severity. The skill learned this the hard way; it's in its gotchas.

**An audit you can act on (paste into your agent):**

```text
/design-engineering a11y components/Dialog.tsx
Then: fix only the rows with a criterion. Leave preferences for me.
```

## Which one?

| Your question | Verb |
|---|---|
| "Is this right? Can I merge it?" | `review` |
| "Why does this look generated?" | `tells` |
| "Who can't use this?" | `a11y` |

All three are judges. The fix comes after, when you say which rows to apply.

**Check yourself:** You run /design-engineering tells on your landing page. What should you expect back?

- [ ] A new visual direction with a different palette
- [ ] The page rewritten without the tells
- [x] A numbered list of things to delete, with locations and the node for each, plus what to keep
- [ ] A WCAG audit

*Why:* tells is a judge verb. It returns a prioritised deletion list, not a redesign and not edits, and ends with what to enlarge so the page isn't left empty.

## In the skill

- https://school.agents.org.in/skill/commands/cmd-review.md
- https://school.agents.org.in/skill/commands/cmd-tells.md
- https://school.agents.org.in/skill/commands/cmd-a11y.md