Design Is (Dieter Rams Audit)
Audit designs against Dieter Rams' ten principles, score with evidence, decide NEW/REFINE/REDESIGN, and hand off a ready-to-run /make-plan prompt.
The skill itself is a pure auditing workflow: it doesn't execute external commands, doesn't modify system config, and only outputs markdown files, so permissions are reasonable. However, it lacks explicit data-flow transparency (what is recorded), user confirmation mechanism (whether to confirm before writing artifacts), and rollback strategy (how overwrites are handled). It also references external tools like agent-browser without declaring safety boundaries. Publisher identity is unverified but not a direct deduction. Deductions: missing data-flow disclosure, user confirmation, and rollback.
The skill has detailed procedures, templates, and failure-mode prevention, but relies on multiple subagents and external skills (agent-browser, /make-plan, /do) whose availability isn't verified. There are no tests for this skill, and static review cannot verify actual execution. Deductions: dependency on unverified external components and no test evidence.
Use cases are clear (design audit) with explicit non-fit scenarios (routine code review, copy editing), and trigger conditions are defined (user says specific phrases). But environment fit is weak: skill is English-only, no Chinese support; dependencies like agent-browser may be unreachable from mainland China; and no clear boundary for non-web designs. Deductions: missing Chinese support and undisclosed reliance on overseas services.
Documentation is well-structured with clear layering (Do not use for, Phases, output artifacts), includes templates and known limitations (e.g., subagents forbidden to score), and license/version are clear in the repo. But the skill itself lacks a version number, changelog, and explicit maintenance responsibility (only repo author). Deductions: missing skill version and changelog.
Core task (audit and generate plan) is clearly defined with a complete process, and in theory produces a directly usable /make-plan prompt. But static review cannot verify output quality, and reliance on multiple subagents and external tools makes actual effectiveness uncertain. Deductions: no live verification; effectiveness inferred from documentation only.
The repo has CI workflows and many test files, but tests target the main claude-mem functionality, not this skill. The skill file itself contains auditable rules and templates, but no third-party execution evidence. Deductions: no tests or execution evidence specifically for this skill.
- The skill depends on external services (e.g., agent-browser) that may be unreachable from mainland China; verify availability or provide alternatives.
- The skill is English-only with no Chinese version, increasing barriers for Chinese users.
- The skill creates/overwrites files without explicit user confirmation or rollback; back up manually before use.
- Publisher identity is unverified; verify source security before deployment.
What does this skill do, and when should you use it?
Design Is is an orchestrator-style skill that audits a design against Dieter Rams' ten principles. It fans out parallel subagents to collect structural, visual, copy, weight, and optional accessibility evidence, then the orchestrator scores each principle on a 0-3 scale, issues a verdict of NEW, REFINE, or REDESIGN based on total score and load-bearing failures, and finally produces a self-contained /make-plan prompt for the next session. The skill requires the user to define the audit scope (URL, repo path, Figma frame, etc.) and emphasizes evidence citation over taste. It does not write implementation code; it delivers an executable plan.
The skill performs the following concrete operations: locks the scope in Phase 0 and writes 00-scope.md; deploys four (or five) evidence-gathering subagents in Phase 1—structural (interactive element counts, nesting depth, repeated patterns, dead props), visual (spacing, type scale, color count, contrast ratio, state checklist), copy & honesty (all user-facing strings, inflated claims, dark patterns), and weight & friction (JS bytes, request count, idle animations), plus an optional accessibility subagent; then scores each of the ten principles (0-3) using verbatim anchors and writes 02-scorecard.md; derives a verdict mechanically in Phase 3 and writes 03-verdict.md; and finally writes 04-handoff-prompt.md with a fully substituted /make-plan prompt quoting the verdict and top moves.
- A designer or PM before shipping a new UI wants a quick, evidence-based audit against Dieter Rams and a concrete improvement plan.
- A developer facing a REFINE vs REDESIGN decision needs a defensible scorecard and a clear recommendation based on load-bearing principles.
- An architect reviewing a legacy interface that has confusing flows wants to identify whether the core usefulness or honesty principles have failed.
- A team planning a greenfield feature wants to pre-define design goals (usefulness, understandability, restraint) and deliverables like token decisions and state checklists.
What are this skill's strengths and limitations?
- Provides a rigorous, evidence-based framework with explicit scoring anchors and mechanical verdict rules, reducing subjectivity.
- Forces source citation (file:line) for every score and prevents verdicts driven by sunk cost or hype.
- The audit is directly actionable via the built-in /make-plan handoff, not just a report.
- Clearly separates orchestrator (scoring, verdict) from subagents (evidence), avoiding role confusion.
- Visual evidence depends on an external browser (agent-browser); for static repos without a running instance, facts may be inferred only and marked as such.
- Requires the user to define clear scope; otherwise it may audit the wrong surface and waste the evidence phase.
- Scoring for 'innovative' and 'long-lasting' relies on orchestrator judgment with no objective measuring tool.
- No automated test suite to validate the process; evidence quality depends on subagent and orchestrator adherence.
- Only produces a plan, not implementation; subsequent sessions must execute.
How do you install this skill?
The skill lives at plugin/skills/design-is/SKILL.md inside the monorepo. To install the whole collection, copy the plugin/skills/design-is folder into your Claude skills directory (e.g. ~/.claude/skills/), or use the repository's marketplace commands: /plugin marketplace add thedotmack/claude-mem and /plugin install claude-mem (these install the claude-mem plugin set, not this skill alone).
How do you use this skill?
Trigger the skill by saying a phrase like 'audit this design' or 'check this UI against Rams'. First, Phase 0 asks you to specify what is being audited (URL, repo path, or Figma frame), who the primary user is, and the primary task; you may also decide whether to run the optional accessibility check. The skill then creates a DESIGN-IS-YYYY-MM-DD/ directory with output artifacts (00-scope.md, 01-evidence.md, 02-scorecard.md, 03-verdict.md, 04-handoff-prompt.md) and ends with a copy-pasteable /make-plan prompt. If the design does not exist yet, state that and the skill will skip to a NEW verdict.