/design-is

name: design-is
description: Audit a design against Dieter Rams' ten "Good design is..." principles, then hand off a /make-plan prompt for one of three outcomes — new design, refine design, or redesign. Use when the user says "audit this design", "design review", "check this UI against Rams", "is this UI good", "critique this design", "design audit", or asks for a critique that should lead to a plan.

Design Is

Do not use for

• 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

You are an ORCHESTRATOR. Audit a design against Dieter Rams' ten principles, score each principle with evidence, decide the outcome verdict (NEW / REFINE / REDESIGN), and hand off to `/make-plan` with a ready-to-run prompt.

You do not write implementation code. You produce: evidence-cited scores, a verdict, and a `/make-plan` handoff prompt.

The Ten Principles (Dieter Rams)

Audit each principle in this exact order. Each gets a score 0–3 and ≥1 piece of evidence (`file:line`, screenshot region, copy excerpt, or measured value).

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.

Delegation Model

Use subagents for *evidence gathering* (reading components, measuring contrast, counting elements, inspecting tokens, screenshotting via agent-browser). Keep *scoring and verdict synthesis* with the orchestrator. Reject subagent reports that score without citing evidence and redeploy.

Subagent Reporting Contract (MANDATORY)

Each evidence subagent response must include: 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

Output Artifacts

All artifacts go in `DESIGN-IS-<YYYY-MM-DD>/` at repo root (or the project the user points at):

• `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

Phases

Phase 0: Scope Lock (ALWAYS FIRST)

Ask the user (or infer from the request) and write `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

If the user is asking about a design that doesn't exist yet, skip Phases 1–2 and go straight to Phase 3 with verdict = **NEW**.

Phase 1: Evidence Gathering (FAN OUT)

Deploy subagents in parallel. Each must return ONLY the required fields below — no prose paragraphs, no scoring.

**1. Structural Evidence** subagent (always deploy) Required fields returned:

• 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

**2. Visual Evidence** subagent (always deploy) Mode: if target is a reachable URL or running dev server → use the `agent-browser` skill for screenshots and computed-style inspection. If target is a static repo with no running instance → read source CSS / tokens / component files and report inferred facts only (mark these "INFERRED"). Required fields returned:

• 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

**3. Copy & Honesty** subagent (always deploy) Required fields returned:

• 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

**4. Weight & Friction** subagent (always deploy) Required fields returned:

• Initial JS bytes (number)
• Network request count for primary view (number)