Verbs that judge
beginner·8 min·Markdown for agents
What this lesson teaches
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.
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.
$ /design-engineering review src/PricingCard.tsxWhat 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:
- A verdict, first line. Blocked (an interaction or accessibility-floor failure), Approve with changes, or Ship it.
- The table. Three to five rows. Twelve rows aren't actionable.
- 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.
"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.
- Remove bg-clip-text on the hero h1: solid ink · page.tsx:14
- Replace from-indigo-500 to-purple-600 with the brand accent · page.tsx:9
- Delete the tiny FEATURES eyebrow above the h2 · page.tsx:41
$ /design-engineering tells app/page.tsxWhat 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 . 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
✓ A deletion list
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.
$ /design-engineering a11y components/Dialog.tsxWhat it does. It reads the accessibility baseline and the 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.
/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.
Quick check
You run /design-engineering tells on your landing page. What should you expect back?
In the skill
The nodes your agent reads when it does this work.
Connected lessons
What this lesson builds on and leads to, across every course.
