/design-review

name: design-review
description: Use when the user wants to evaluate something that ALREADY EXISTS rather than build something new — "review this", "audit this screen", "what's wrong with this page", "is this accessible?", or when they share a screenshot, URL, or existing code/markup. Runs the existing reviewers (design-critic, accessibility-reviewer, heuristic-evaluator) in parallel against the artefact and reconciles their findings into one prioritised report — WITHOUT running discovery, strategy, or the full build pipeline

Design Review (the review lane)

Most design work is improving something that already exists, not starting from a blank page. This is the **review-only lane**: it takes an existing artefact — a screenshot, a live URL, a prototype, or existing code/markup — and runs it through the same reviewers and reconciliation the full pipeline uses, but **without** discovery, strategy, design, or build.

It's the counterpart to the build lane. The build lane asks "what are we designing?" and creates. The review lane asks "what are we evaluating?" and critiques.

When to Use

Route here, instead of the build pipeline, when the user already has something:

• "Review / audit / critique this [screen / page / app / flow / component]"
• "What's wrong with this?" / "How can I improve this?" / "Is this accessible?"
• They share a **screenshot**, a **URL**, or point at **existing code/markup**
• They want a usability, accessibility, or craft assessment of work that already exists

If the user wants to *build* something new, use the normal pipeline (`design-discovery` → …). If it's genuinely unclear which they want, ask one question: "Do you want me to review something you already have, or design something new?"

What this lane skips and why

It deliberately skips discovery, research, strategy, inspiration, planning, and build — there is nothing to build. It does **not** skip accessibility, usability, or craft evaluation. The point is a rigorous, reconciled critique, fast, then a decision about what to fix.

Process

Step 1: Get the artefact

Establish what you're reviewing and take it in directly — always evaluate the **actual artefact**, never a description of it:

| Artefact | How to take it in | |----------|-------------------| | **Screenshot / image** | Read the image directly | | **Live URL** | Load and screenshot it (browser tooling); note interactive states | | **Existing code / markup** | Read the relevant files; if it runs, screenshot the running build | | **A `DESIGN.md` + a build** | Read the spec via `design-md`, then review the build against it |

If you can only get a static image, say so — keyboard, focus, and screen-reader findings will be **inferred, not verified**. Be explicit about that coverage limit.

Step 2: Capture a lightweight inferred brief

The reviewers normally evaluate against a brief, personas, and principles. In review mode those don't exist yet, so build a **minimal inferred brief** — a few quick questions, not a discovery session:

1. **What is this, and what's the main thing a person is trying to do here?** (the key task) 2. **Who is it for?** (audience and ability spectrum — if unknown, assume the full spectrum: permanent, temporary, situational) 3. **What's the quality bar, and what prompted the review?** (shipping prototype vs. flagship; "it feels off" vs. "failed an audit" vs. "low conversion")

Record this in `design-state.md`, clearly marked as **inferred** (reconstructed for review, not authored up front).

Step 3: Run the three reviewers in parallel

Dispatch the existing reviewer agents **simultaneously** against the artefact and the inferred brief — this is the Reconciliation Protocol's parallel-review step (see `using-designpowers`):

        artefact + inferred brief
   ┌────────────┼────────────┐
   v            v            v
design-critic  accessibility-  heuristic-evaluator
               reviewer
   └────────────┼────────────┘
                v
          reconciliation

• **accessibility-reviewer** — WCAG/COGA evaluation. On a static image, flags what it can verify vs. only infer.
• **design-critic** — craft and intent against the inferred brief.
• **heuristic-evaluator** — Nielsen's 10 + a cognitive walkthrough of the key task from Step 2.

Step 4: Reconcile

Apply the **Reconciliation Protocol** from `using-designpowers`: classify findings (Aligned / Complementary / Conflicting) and resolve conflicts by its priority rules (accessibility over aesthetics, usability over style, brief over opinion, personas break ties, escalate to the user if unresolvable).

Step 5: Present one consolidated report

Deliver a single prioritised report — not three separate ones:

# Design Review: [what was reviewed]

**Reviewed:** [artefact + how it was accessed]
**Inferred brief:** [key task · audience · quality bar]
**Coverage:** [what was verified vs. inferred — e.g. "static screenshot: visual + content verified; interaction/keyboard inferred"]

## Summary
[2-3 sentences: overall assessment]

## Findings (prioritised, reconciled)
### Critical — blocks access or breaks the key task
- [source(s)] [finding] → [fix] · affects [persona(s)]
### Major — significantly degrades the experience
- ...
### Minor — improvement opportunities
- ...

## What works well
- [genuine strengths — review is not only problems]

## Recommendation
[Ship as-is / fix criticals first / rethink — and the single most important next move]

For each Critical and Major finding, name who it affects and why it matters — not just what's wrong.

Step 6: Offer next steps (the user decides)

End by handing the decision to the user. Offer the routes that fit the artefact:

• **Fix it** — if it's code you can edit, dispatch `design-builder` with the prioritised fix list.
• **Track it** — send deferred Minor findings to `design-debt-tracker` so they aren't silently dropped (accessibility debt needs explicit user acknowledgement t