Run an AI Pre-Review Before Human Critique

Workflow area: Handoff & Collaboration · Tier: Core · Hands-on time: ~30 minutes

Watch any design critique and count the minutes spent on mechanical findings: that's an off-token color, this button isn't the system component, where's the error state, this copy says "delete" but we say "remove." Every one is real, and every one is a waste of six senior people in a room — checkable facts don't need discussion, they need a checklist. The pre-review moves those findings to before the meeting, attached to the file, resolved or acknowledged by the author. What's left for humans is what humans are for: is this the right problem, the right structure, the right trade-off. The critical design property is authority: the pre-review can flag, and it can never approve. The moment "the AI passed it" becomes an argument, the tool has been promoted beyond its competence.

When to use — and when not to

• Use it as a standing pre-critique ritualauthor runs it, resolves or annotates findings, then books the humans; critique starts where the checklist ends.
• Use it for cross-team consistency at scalewhen four squads submit to one design authority, the shared rubric applied uniformly is the only way review load stays sane.
• Use it to onboard new designersthe rubric findings teach team conventions faster than any wiki page, with the new designer's own work as the textbook.
• Skip it for early explorationsconcept-stage work reviewed against a shipping rubric gets false rigor; divergence (pb-04) is graded on ideas, not token compliance.
• Never let it gate autonomouslyno auto-reject, no auto-approve, no "passed AI review" badge that substitutes for a human's yes. Screener, not judge.

The recipe

1. 1.

   Write the rubric down — the tool forces the conversation. Most teams' review criteria are folklore. Turn them into checkable items across four sections: system compliance (real components, bound tokens, layout-grid adherence), a11y basics (the pb-31 deterministic set: contrast, targets, labels), state coverage (the pb-07 matrix: empty, loading, error, edge content), and copy voice (the pb-27/pb-29 rules: terminology, tone, casing). Each item phrased so a finding is verifiable: not "is it consistent?" but "does every button use a library instance?"

2. 2.

   Assemble the review prompt. Screenshots of the submitted frames plus the rubric:

   Copy

   You are running a pre-critique screen for [TEAM]'s design review.
   Attached: screenshots of the submitted flow, plus context:
   [ONE-LINE BRIEF, TARGET PLATFORM, LINK CONVENTIONS].
   
   Review ONLY against this rubric:
   [PASTE RUBRIC — numbered items per section]
   
   For each rubric item return: PASS / FLAG / CANNOT-ASSESS.
   For every FLAG: screen, element, what the rubric expects, what you
   observe. For CANNOT-ASSESS (e.g. token binding not visible in a
   screenshot): say what artifact you'd need.
   
   Rules: no opinions beyond the rubric. No aesthetic judgments. No
   redesign suggestions. If everything passes, say so — do not invent
   findings to seem thorough.
   

   That last rule is load-bearing: review models pad. Sample output:

   Copy

   SYSTEM COMPLIANCE
   1.1 Library buttons — FLAG: "Export" button on screen 3 has 6px
       radius; library btn-primary uses 8px. Possible detached copy.
   1.2 Token colors — CANNOT-ASSESS from screenshots; needs Dev Mode
       values or file access.
   STATE COVERAGE
   3.1 Error states — FLAG: upload flow (screens 2–4) shows no
       failure state for the upload action.
   COPY VOICE
   4.2 Terminology — FLAG: screen 5 uses "Board"; term base says
       "Workspace" (TB-011).
   

3. 3.

   Author triages before critique — every flag gets a disposition. Fixed, or annotated: "6px radius is intentional here because X." The triaged list travels with the submission. This step is what makes the system respectful rather than surveillant: the author answers to the rubric before peers, privately, with the chance to fix or defend.

4. 4.

   Route CANNOT-ASSESS honestly. Items screenshots can't verify go to the right instrument — token binding to a Dev Mode/file check (pb-25 tooling), contrast to Stark. Don't let unverifiable items silently count as passes; list them as "checked by other means" or "open."

5. 5.

   Start human critique from the residue. The facilitator opens with the triaged list — thirty seconds of "lint is handled, two intentional deviations noted" — then spends the whole session on judgment: problem fit, flow logic, trade-offs, taste. Track over a month what fraction of critique time still goes to mechanical findings; that number falling is the system working.

6. 6.

   Feed disputes back into the rubric. When authors repeatedly annotate the same "violation" as intentional, the rubric is wrong or the system needs a variant — update it. When critique keeps surfacing a mechanical issue the screen missed, add the item. The rubric is a living document with a changelog, same discipline as pb-32's constraint block.

Make it yours

• Claude Project as the team reviewer: rubric, term base, and exemplar screenshots of "what good looks like" live in a shared Project; every author runs the same reviewer, and rubric updates propagate instantly to everyone.
• Severity tiers for scale: for high-volume teams, split flags into blocking (fix before critique) and advisory (note and proceed) — pre-agreed, so the screen never becomes a negotiation.
• Pair it with pb-8 for the full ladder: pb-08's self-lint while designing, this pre-review at submission, humans at critique — three passes, each cheaper than the next one's time it protects.

Quality check

• Every finding cites a rubric itema flag with no rubric anchor is the model editorializing; delete it and tighten the prompt.
• The padding rule heldclean sections came back clean; a reviewer that always finds something is training authors to ignore it.
• CANNOT-ASSESS items were routed, not droppedscreenshot-invisible checks went to real instruments; nothing unverifiable counted as a pass.
• Authors triage before critique sees flagsthe pre-review is the author's tool first; skipping triage turns it into ambush-by-robot.
• Human critique time shifted to judgmentthe observable outcome; if meetings still burn on lint, the rubric or the ritual isn't landing.