• Routine UI code reviews → use

  /review

• Pure copy edits → use a separate copy pass
• Pre-design ideation with no artifact yet → start with

  /make-plan

  directly

/make-plan

/make-plan

file:line

1. Good design is innovative — Does it advance the form, or imitate? Innovation rides on technology; never an end in itself.
2. Good design makes a product useful — Does it serve the primary task? Emphasizes usefulness; disregards anything that detracts.
3. Good design is aesthetic — Is it beautiful? Only well-executed objects can be beautiful; aesthetic quality affects well-being.
4. Good design makes a product understandable — Does the structure clarify function? Or is it self-explanatory at best?
5. Good design is unobtrusive — Does it stay out of the way? Neither decorative objects nor works of art — leave room for self-expression.
6. Good design is honest — Does it claim only what it is? No false promises, no manipulation, no inflated value.
7. Good design is long-lasting — Will it age well? Avoids being fashionable; never appears antiquated.
8. Good design is thorough down to the last detail — Are edges, empty states, errors, focus rings, motion curves all considered? Care and accuracy express respect for the user.
9. Good design is environmentally friendly — Does it conserve resources? Minimizes pollution — in software: bundle weight, energy, attention, cognitive load.
10. Good design is as little design as possible — Less, but better. Concentrates on essentials; back to purity, back to simplicity.

The user wrote "Dieter Braun" — they mean Dieter Rams. Don't correct them inline; just use the right principles.

1. Sources consulted — exact file paths and line ranges, or screenshot regions
2. Concrete findings — what is present, what is missing, with quotes/values
3. Per-principle facts (not opinions) — leave scoring to the orchestrator
4. Known gaps — what could not be inspected and why

DESIGN-IS-<YYYY-MM-DD>/

• 00-scope.md

  — what was audited (URL, component paths, screens), input materials

• 01-evidence.md

  — per-principle evidence collected by subagents

• 02-scorecard.md

  — per-principle 0–3 score with one-line justification + total

• 03-verdict.md

  — NEW / REFINE / REDESIGN with reasoning

• 04-handoff-prompt.md

  — copy-pasteable

  /make-plan

  prompt for the chosen outcome

00-scope.md

• What is being audited? (live URL, repo path, Figma frame, component name)
• Who is the primary user, and what is the primary task?
• Constraints (brand, stack, deadline)
• Reference designs or competitors, if any

• Total interactive-element count on audited surface
• Max nesting depth of the primary component tree
• Repeated-pattern count (same affordance appearing >1 place with the same purpose)
• Dead-prop / unused-import count
• File:line citations for every count

agent-browser

• Spacing scale observed (px array)
• Type scale observed (px array)
• Distinct color count (count of unique hex/oklch tokens actually rendered or referenced)
• Lowest contrast ratio observed across primary text
• States present checklist: empty / loading / error / success / focus / disabled — present or missing for each

• List of every user-facing string with file:line
• Flagged inflations (marketing superlatives without backing)
• Flagged dark patterns (forced continuity, hidden cost, fake scarcity, confirmshaming)
• Flagged jargon / unclear labels with proposed plain replacement
• Label→behavior mismatches with file:line of both

• Initial JS bytes (number)
• Network request count for primary view (number)
• Time-to-interactive ms (number, measured or estimated with method noted)
• Animation count on idle screen (number)
• Notification / badge / modal count on initial load (number)

• WCAG contrast pass/fail per text token
• Focus order list across primary controls
• Keyboard reachability of every primary action (yes/no per action)
• ARIA landmark count
• Skip-link present (yes/no)

01-evidence.md

02-scorecard.md

N. Good design is <principle> — Score: X/3
   Evidence: <one-line summary citing 01-evidence.md anchors>
   Justification: <one sentence on why this score, not the one above or below>

• Tie-breaker rule: When uncertain between two scores, pick the lower one. Convergence > generosity.
• Score worst, not mean: When a principle has multiple representative instances on the audited surface, score the worst instance — not the average.
• No bonuses, no weights: Scores stay 0–3 integer. Principles are equally weighted. Total is sum of ten scores, max 30.

03-verdict.md

• NEW DESIGN — No design exists yet, OR the existing artifact is a stub/wireframe with no real decisions to preserve.
• REFINE — Total score ≥ 20 AND no individual principle scored 0. The bones are good; iterate.
• REDESIGN — Total score < 20, OR any principle scored 0 on a load-bearing dimension (typically #2 useful, #4 understandable, or #6 honest). Start over from purpose.

• Recommending REFINE because the codebase is large (sunk cost is not a design principle)
• Recommending REDESIGN because a single screen is ugly (scope it)
• Recommending NEW when an honest REDESIGN is warranted (don't dodge the critique)

• Evidence over taste — every score cites a source; "feels wrong" is not a finding
• Score what is, not what was intended — design is what ships, not what was drawn
• Honesty applies to the audit too — if total is 28/30, say REFINE even if the user wanted a redesign; if it's 12/30, say REDESIGN even if the user wanted a refine
• One verdict, not three — pick NEW or REFINE or REDESIGN; do not hedge
• Handoff, don't implement —

  design-is

  ends at the

  /make-plan

  prompt;

  /make-plan

  and

  /do

  take it from there
• Verdict commitment — Once

  02-scorecard.md

  is written, the verdict follows the Phase 3 rule mechanically. Never re-score to back into a preferred verdict; if the scorecard says REDESIGN, the handoff is REDESIGN.

• Scoring from screenshots alone without reading the code — redeploy with structural subagent
• Scoring the codebase instead of the design — re-anchor on user-facing evidence
• Awarding 3s generously to soften the verdict — recalibrate against the per-principle anchors in Phase 2
• Producing a handoff prompt that doesn't quote the verdict and top moves — the next session is blind without them
• Skipping Phase 0 scope lock — auditing the wrong surface wastes Phase 1
• Sunk-cost reasoning — recommending REFINE because the codebase is large; sunk cost is not a design principle
• Hedging across verdicts — "could be REFINE or REDESIGN depending on..." — pick one
• Score inflation to match a desired verdict — score the evidence, then read the verdict off the rule
• Letting Phase 0 user preference override Phase 3 evidence — the user can disagree with the verdict, but the audit reports what the evidence says