Design Is
Score an existing UI or design artifact against Dieter Rams’ ten principles, get a NEW/REFINE/REDESIGN verdict, and receive a ready `/make-plan` handoff—without writing implementation code yourself.
Overview
Design Is is an agent skill most often used in Ship (also Validate, Build) that audits a design against Dieter Rams’ ten principles with scored evidence and hands off a `/make-plan` prompt for NEW, REFINE, or REDESIGN.
Install
npx skills add https://github.com/thedotmack/claude-mem --skill design-isWhat is this skill?
- Orchestrates a fixed-order audit of all 10 Dieter Rams “Good design is…” principles with 0–3 scores each
- Requires ≥1 cited evidence per principle (file:line, screenshot region, copy, or measured value)
- Outputs a single outcome verdict: NEW, REFINE, or REDESIGN
- Hands off a copy-paste `/make-plan` prompt; does not write implementation code
- Explicit anti-patterns: not for `/review`, pure copy passes, or greenfield ideation with no artifact
- 10 Dieter Rams principles audited in fixed order
- 0–3 score scale per principle with mandatory evidence
Adoption & trust: 414 installs on skills.sh; 81.2k GitHub stars.
What problem does it solve?
You have screens or UI in front of you but no shared, evidence-based way to decide whether to start over, polish, or redesign before your agent writes a plan.
Who is it for?
Solo builders with an existing mockup, live UI, or component library who want a Rams-grounded audit that ends in a planning handoff—not ad-hoc “does this look good?” chat.
Skip if: Routine UI code reviews (use `/review`), copy-only passes, or ideation when no design artifact exists yet (start with `/make-plan` or brainstorming instead).
When should I use this skill?
User says “audit this design”, “design review”, “check this UI against Rams”, “is this UI good”, “critique this design”, “design audit”, or wants a critique that should lead to a plan.
What do I get? / Deliverables
You get ten principle scores with citations, a NEW/REFINE/REDESIGN verdict, and a ready `/make-plan` handoff so implementation planning starts from an explicit design decision.
- Per-principle 0–3 scores with evidence citations
- NEW / REFINE / REDESIGN verdict
- Ready-to-run `/make-plan` handoff prompt
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Design critique with evidence and a go-forward verdict sits in Ship’s review lane: you already have something to judge before you commit to more build work. Subphase review covers structured critique, scoring, and quality gates—not routine code diff review (`/review`) or pre-artifact ideation.
Where it fits
Score a Figma-exported prototype before you lock scope for the first build sprint.
Audit shipped components for usefulness and aesthetic execution before a refactor sprint.
Run a pre-release UI pass that ends in REFINE vs REDESIGN instead of endless tweak loops.
Critique store-facing screenshots and hero frames against Rams before you regenerate marketing assets.
How it compares
Use instead of informal design chatter when you need scored principles and a forced NEW/REFINE/REDESIGN verdict before planning.
Common Questions / FAQ
Who is design-is for?
Indie and solo builders shipping web or mobile products who already have UI to critique and want Dieter Rams–based scoring plus a `/make-plan` handoff without the agent jumping into code.
When should I use design-is?
Use it when you say “audit this design”, “design review”, “check this UI against Rams”, or “critique this design” with an artifact in hand—common in Validate (prototype review), Build (frontend polish), and Ship (pre-launch UI review).
Is design-is safe to install?
It is a procedural orchestration skill with no bundled network or shell requirements in the skill itself; review the Security Audits panel on this Prism page before trusting any repo install.
Workflow Chain
Then invoke: make plan
SKILL.md
READMESKILL.md - Design Is
# 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 n