design-is

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

常规UI代码评审 → 使用
```
/review
```
纯文案修改 → 使用独立的文案审核流程
尚无设计产出的前期构思 → 直接使用
```
/make-plan
```

你是一名ORCHESTRATOR。需依据Dieter Rams的十大原则对设计进行审计，为每项原则打分并附上证据，确定最终结论（NEW / REFINE / REDESIGN），并生成可直接执行的/make-plan移交提示。

你无需编写实现代码，只需产出：带证据的评分、结论，以及/make-plan移交提示。

The Ten Principles (Dieter Rams)

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).

Good design is innovative — Does it advance the form, or imitate? Innovation rides on technology; never an end in itself.
Good design makes a product useful — Does it serve the primary task? Emphasizes usefulness; disregards anything that detracts.
Good design is aesthetic — Is it beautiful? Only well-executed objects can be beautiful; aesthetic quality affects well-being.
Good design makes a product understandable — Does the structure clarify function? Or is it self-explanatory at best?
Good design is unobtrusive — Does it stay out of the way? Neither decorative objects nor works of art — leave room for self-expression.
Good design is honest — Does it claim only what it is? No false promises, no manipulation, no inflated value.
Good design is long-lasting — Will it age well? Avoids being fashionable; never appears antiquated.
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.
Good design is environmentally friendly — Does it conserve resources? Minimizes pollution — in software: bundle weight, energy, attention, cognitive load.
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.

需严格按照以下顺序审计每项原则。每项原则的评分范围为0–3分，且需提供至少1条证据（

文件:行号

、截图区域、文案摘录或测量值）。

好设计是创新的 —— 它是推进形式创新，还是模仿？创新依托技术，但绝非目的本身。
好设计是实用的 —— 它能否服务核心任务？强调实用性，摒弃一切无关内容。
好设计是美观的 —— 它是否赏心悦目？只有工艺精良的作品才能称得上美观，审美品质会影响用户体验。
好设计是易懂的 —— 结构能否清晰传达功能？至少要做到直观易懂。
好设计是低调的 —— 它是否不会喧宾夺主？既非装饰摆件也非艺术作品，需为用户的自我表达留出空间。
好设计是诚实的 —— 它是否如实呈现自身？无虚假承诺、无操纵手段、无夸大价值。
好设计是持久的 —— 它是否经得起时间考验？拒绝跟风潮流，永不过时。
好设计注重细节 —— 是否考虑了边缘状态、空状态、错误状态、焦点环、动效曲线等所有细节？用心与精准是对用户的尊重。
好设计是环保的 —— 它是否节约资源？减少污染——在软件领域：指包体积、能耗、用户注意力、认知负荷。
好设计是极简的 —— 少即是多。聚焦核心，回归纯粹与简洁。

若用户写的是“Dieter Braun”，实际指的是Dieter Rams。无需在文中纠正，直接使用正确的原则即可。

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.

可调用subagents完成证据收集工作（读取组件、测量对比度、统计元素、检查tokens、通过agent-browser截图）。评分与结论整合需由ORCHESTRATOR完成。若subagents提交的报告无证据支持评分，需驳回并重新部署。

Subagent Reporting Contract (MANDATORY)

Subagents报告规范（强制要求）

Each evidence subagent response must include:

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

每个证据收集subagent的响应必须包含：

参考来源 —— 精确的文件路径和行范围，或截图区域
具体发现 —— 存在的内容、缺失的内容，并附上引用/数值
基于原则的事实（非主观意见）—— 评分由ORCHESTRATOR完成
已知局限 —— 无法检查的内容及原因

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

所有产物需存放于仓库根目录的

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

文件夹下（或用户指定的项目路径）：

```
00-scope.md
```
—— 审计范围（URL、组件路径、界面）、输入素材
```
01-evidence.md
```
—— subagents收集的各原则相关证据
```
02-scorecard.md
```
—— 各原则的0–3分评分、一行理由及总分
```
03-verdict.md
```
—— NEW / REFINE / REDESIGN结论及理由
```
04-handoff-prompt.md
```
—— 可直接复制粘贴的/make-plan提示，匹配最终结论

Phases

流程阶段

Phase 0: Scope Lock (ALWAYS FIRST)

阶段0：锁定范围（必须首先执行）

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.

询问用户（或从请求中推断）并撰写

00-scope.md

：

审计对象是什么？（线上URL、仓库路径、Figma框架、组件名称）
核心用户是谁，核心任务是什么？
约束条件（品牌、技术栈、截止日期）
参考设计或竞品（如有）

若用户询问的是尚未存在的设计，跳过阶段1–2，直接进入阶段3，结论为NEW。

Phase 1: Evidence Gathering (FAN OUT)

阶段1：证据收集（并行执行）

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)
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)

5. Accessibility Evidence subagent (OPTIONAL — deploy only if target has a meaningful interactive UI surface; skip for static landing pages without interaction) Required fields returned:

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)

Principle → subagent mapping (orchestrator uses this when scoring):

Principle	Fed by
#1 innovative	orchestrator-only (judgment using all evidence)
#2 useful	Structural, Accessibility
#3 aesthetic	Visual
#4 understandable	Structural, Copy & Honesty, Accessibility
#5 unobtrusive	Structural, Visual
#6 honest	Copy & Honesty
#7 long-lasting	orchestrator-only (judgment using all evidence)
#8 thorough	Visual
#9 environmentally friendly	Weight & Friction
#10 as little design as possible	Structural

The orchestrator writes

01-evidence.md

consolidating all subagent reports. Reject any finding without a source citation. Subagents are explicitly forbidden from scoring — only the orchestrator scores, using the rubric in Phase 2.

并行部署subagents。每个subagent仅需返回以下必填字段——无需散文段落，无需评分。

1. 结构证据subagent（必须部署） 需返回的必填字段：

审计界面上的交互元素总数
核心组件树的最大嵌套深度
重复模式数量（同一交互方式在多个位置用于同一目的）
无效属性/未使用导入的数量
每项统计对应的
```
文件:行号
```
引用

2. 视觉证据subagent（必须部署） 模式：若目标是可访问的URL或运行中的开发服务器 → 使用

agent-browser

技能进行截图和计算样式检查。若目标是无运行实例的静态仓库 → 读取源CSS/tokens/组件文件，仅报告推断出的事实（标记为“INFERRED”）。需返回的必填字段：

观察到的间距规范（px数组）
观察到的字体规范（px数组）
不同颜色的数量（实际渲染或引用的唯一十六进制/oklch tokens数量）
核心文本的最低对比度
状态清单：空状态/加载中/错误/成功/焦点/禁用——标记每个状态是否存在

3. 文案与诚实性subagent（必须部署） 需返回的必填字段：

所有用户可见文案列表及对应的
```
文件:行号
```
标记夸大表述（无依据的营销级最高级词汇）
标记暗黑模式（强制连续操作、隐藏成本、虚假稀缺、确认羞辱）
标记晦涩术语/模糊标签，并提出直白替代方案
标记标签与行为不符的情况及双方对应的
```
文件:行号
```

4. 性能与摩擦subagent（必须部署） 需返回的必填字段：

初始JS字节数（数值）
核心视图的网络请求数（数值）
可交互时间（毫秒，需注明测量或估算方法）
空闲界面的动效数量（数值）
初始加载时的通知/徽章/弹窗数量（数值）

5. 可访问性证据subagent（可选——仅当目标存在有意义的交互UI界面时部署；无交互的静态落地页可跳过） 需返回的必填字段：

每个文本token是否通过WCAG对比度测试
核心控件的焦点顺序列表
每个核心操作是否可通过键盘访问（标记是/否）
ARIA地标数量
是否存在跳转链接（标记是/否）

原则与subagent映射（ORCHESTRATOR评分时使用）：

原则	数据来源
#1 创新型	仅ORCHESTRATOR（基于所有证据判断）
#2 实用性	结构证据、可访问性证据
#3 美观性	视觉证据
#4 易懂性	结构证据、文案与诚实性证据、可访问性证据
#5 低调性	结构证据、视觉证据
#6 诚实性	文案与诚实性证据
#7 持久性	仅ORCHESTRATOR（基于所有证据判断）
#8 细节性	视觉证据
#9 环保性	性能与摩擦证据
#10 极简性	结构证据

ORCHESTRATOR需撰写

01-evidence.md

整合所有subagents的报告。驳回任何无来源引用的发现。明确禁止subagents进行评分——仅ORCHESTRATOR可使用阶段2的评分规则进行评分。

Phase 2: Scorecard (ORCHESTRATOR)

阶段2：评分卡（ORCHESTRATOR执行）

The orchestrator scores each of the ten principles itself — do NOT delegate scoring.

For each principle, write to

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>

Per-principle scoring anchors (apply verbatim — pick the level whose signal best matches the audited surface):

#1 innovative — 3: introduces a pattern not seen in 5+ peer products and ships it with restraint. 2: refreshes an existing pattern with a clear improvement. 1: imitates competitors with minor variation. 0: copies a competitor's flow wholesale. #2 useful — 3: primary task completes in fewest possible steps; no decoy actions. 2: primary task completes but adjacent surface adds steps. 1: primary task requires unnecessary detours. 0: primary task is not directly supported on the screen audited. #3 aesthetic — 3: spacing/type/color obey a single visible system; no orphan styles. 2: ≤2 minor inconsistencies across audited surface. 1: 3–5 inconsistencies OR one jarring violation. 0: no visible system OR active visual noise. #4 understandable — 3: a first-time user names every primary control correctly. 2: 1 control needs a tooltip. 1: 2–3 controls unclear; jargon present. 0: primary action is not identifiable without help. #5 unobtrusive — 3: chrome recedes; content is the figure, UI the ground. 2: chrome visible but quiet. 1: decoration competes with content. 0: chrome dominates content. #6 honest — 3: every claim, badge, and label maps 1:1 to actual behavior. 2: ≤1 minor inflation (e.g. "powerful" once). 1: 2+ inflations OR one dark pattern. 0: any deceptive flow (forced continuity, hidden cost, fake scarcity). #7 long-lasting — 3: visual language has no dated trend markers; would read as current 3 years from now. 2: 1 dated marker. 1: 2–3 dated markers (skeuomorph residue, fad gradients, trend typography). 0: design reads as a specific year's trend. #8 thorough — 3: empty / loading / error / success / focus / disabled all present and considered. 2: 1 state missing or rough. 1: 2–3 states missing. 0: 4+ states missing or default-browser. #9 environmentally friendly — 3: initial JS <100KB, no idle animation, dark mode honored, prefers-reduced-motion respected. 2: <500KB, motion gated. 1: 500KB–2MB, motion always on. 0: >2MB OR autoplay video OR dark mode ignored. #10 as little design as possible — 3: every element earns its place; removing any one breaks the task. 2: ≤2 removable elements. 1: 3–5 removable elements. 0: page is dominated by decoration or duplicated affordances.

Scoring rules:

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.

ORCHESTRATOR需自行完成十大原则的评分——不得委托给他人。

针对每项原则，需写入

02-scorecard.md

：

N. 好设计是<原则内容> —— 评分：X/3
   证据：<一行总结，引用01-evidence.md中的锚点>
   理由：<一句话说明为何给此分数，而非更高或更低>

各原则评分标准（严格执行——选择与审计对象最匹配的等级）：

#1 创新型 —— 3分：引入5个以上竞品未出现的模式，且克制落地。2分：对现有模式进行优化，改进效果明确。1分：模仿竞品，仅做微小改动。0分：完全复制竞品流程。 #2 实用性 —— 3分：核心任务可通过最少步骤完成；无干扰操作。2分：核心任务可完成，但相关界面增加了步骤。1分：核心任务需不必要的绕行。0分：审计界面不直接支持核心任务。 #3 美观性 —— 3分：间距/字体/颜色遵循统一可见的规范；无孤立样式。2分：审计界面存在≤2处微小不一致。1分：存在3–5处不一致，或1处明显违规。0分：无可见规范，或存在明显视觉噪音。 #4 易懂性 —— 3分：首次使用的用户能准确识别所有核心控件。2分：仅1个控件需要提示框。1分：2–3个控件不清晰；存在晦涩术语。0分：无帮助的情况下无法识别核心操作。 #5 低调性 —— 3分：界面框架弱化；内容为主，UI为辅。2分：界面框架可见但不醒目。1分：装饰元素与内容争夺注意力。0分：界面框架主导内容。 #6 诚实性 —— 3分：所有声明、徽章、标签与实际行为1:1匹配。2分：存在≤1处轻微夸大（如一次使用“强大”）。1分：存在2处以上夸大，或1种暗黑模式。0分：存在任何欺骗性流程（强制连续操作、隐藏成本、虚假稀缺）。 #7 持久性 —— 3分：视觉语言无过时趋势特征；3年后仍显新颖。2分：存在1处过时特征。1分：存在2–3处过时特征（拟物化残留、流行渐变、潮流字体）。0分：设计带有明确的时代潮流印记。 #8 细节性 —— 3分：空状态/加载中/错误/成功/焦点/禁用状态均已覆盖并优化。2分：缺失或粗糙1种状态。1分：缺失2–3种状态。0分：缺失4种以上状态，或使用浏览器默认状态。 #9 环保性 —— 3分：初始JS体积<100KB，无空闲动效，支持深色模式，遵循减少动效偏好。2分：体积<500KB，动效可控制。1分：体积500KB–2MB，动效始终开启。0分：体积>2MB，或自动播放视频，或忽略深色模式。 #10 极简性 —— 3分：每个元素都有存在的必要；移除任何一个都会影响任务完成。2分：存在≤2个可移除元素。1分：存在3–5个可移除元素。0分：页面被装饰或重复交互元素主导。

评分规则：

平局规则：若无法确定两个评分，选择较低的分数。严谨优先于宽松。
以最差情况评分：若某项原则在审计界面存在多个代表性实例，以最差实例评分——而非平均值。
无额外加分，无权重差异：评分保持0–3整数。所有原则权重相同。总分为十大原则得分之和，最高30分。

Phase 3: Verdict (ORCHESTRATOR)

阶段3：结论（ORCHESTRATOR执行）

Write

03-verdict.md

with one of three verdicts, chosen by these rules:

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.

State the verdict in one sentence. Then list the 3–5 highest-leverage moves — each tied to a specific principle and evidence anchor. These become the spine of the next phase's plan.

Anti-patterns to reject in your own verdict:

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)

撰写

03-verdict.md

，根据以下规则选择三种结论之一：

NEW DESIGN —— 尚无设计，或现有产物为无实际决策的草稿/线框图。
REFINE —— 总分≥20分，且无任何原则得0分。基础良好，可迭代优化。
REDESIGN —— 总分<20分，或任何核心原则（通常是#2实用性、#4易懂性或#6诚实性）得0分。需从目标出发重新设计。

用一句话说明结论。然后列出3–5个最高优先级改进动作——每个动作需关联特定原则和证据锚点。这些将成为下一阶段规划的核心。

结论需避免的反模式：

因代码库庞大而推荐REFINE（沉没成本并非设计原则）
因单个界面丑陋而推荐REDESIGN（需明确范围）
当需要REDESIGN时推荐NEW（回避评审结论）

Phase 4: /make-plan Handoff

阶段4：/make-plan移交

Write

04-handoff-prompt.md

containing exactly ONE fenced

/make-plan

prompt matching the verdict. The prompt must be self-contained — the next session won't see this audit unless it's quoted in.

Use the matching template below. Fill every

<bracket>

. Include the top 3–5 moves from Phase 3 verbatim, each with its evidence anchor.

Quote-in step (mandatory, applies to all three templates below): Before emitting the handoff, replace EVERY

<bracket>

placeholder with concrete content from the audit. Inline the verdict paragraph from

03-verdict.md

and the top 3–5 moves verbatim into the template. Do NOT leave bare references like "see DESIGN-IS-.../03-verdict.md" — the next session won't have file access to the audit. The emitted handoff must be readable and actionable with zero external lookups.

撰写

04-handoff-prompt.md

，包含与结论匹配的一个带围栏的/make-plan提示。提示必须独立完整——下一环节无法查看本次审计内容，除非提示中引用了相关信息。

使用以下匹配模板。填充所有

<占位符>

。将阶段3中排名前3–5的改进动作原封不动地包含进去，每个动作需附证据锚点。

引用步骤（强制要求，适用于以下所有模板）：在生成移交提示前，将所有

<占位符>

替换为审计中的具体内容。将

03-verdict.md

中的结论段落和排名前3–5的改进动作原封不动地嵌入模板。不得留下诸如“详见DESIGN-IS-.../03-verdict.md”的裸引用——下一环节无法访问审计文件。生成的移交提示必须无需外部查找即可阅读和执行。

Template: NEW DESIGN

模板：NEW DESIGN

/make-plan Design <product/screen/component name> from scratch.

Primary user: <who>
Primary task: <one sentence>
Constraints: <brand, stack, deadline, accessibility floor>

Non-goals (do not design these now):
- <explicit out-of-scope item 1>
- <explicit out-of-scope item 2>
- <explicit out-of-scope item 3>

Reference principles to optimize for, in order:
1. Useful (#2) — <what useful looks like here>
2. Understandable (#4) — <what clarity looks like here>
3. As little design as possible (#10) — <what restraint looks like here>

Deliverables for the plan:
- Information architecture (one screen map or component tree)
- Primary flow wireframe (low-fi, labeled)
- Token decisions (type scale, spacing scale, color count cap)
- States checklist (empty, loading, error, success, focus, disabled)
- Honesty audit on every user-facing string before ship

Anti-patterns to guard against (specific to NEW):
- Decoration without function
- Novel interactions without precedent
- Copy that overpromises
- Designing for screens the Non-goals list excluded

/make-plan 从零开始设计<产品/界面/组件名称>。

核心用户：<用户群体>
核心任务：<一句话描述>
约束条件：<品牌、技术栈、截止日期、可访问性底线>

非目标（当前无需设计）：
- <明确的非范围项1>
- <明确的非范围项2>
- <明确的非范围项3>

需优先遵循的参考原则：
1. 实用性（#2）—— <此处实用性的定义>
2. 易懂性（#4）—— <此处清晰性的定义>
3. 极简性（#10）—— <此处克制性的定义>

规划交付物：
- 信息架构（界面地图或组件树）
- 核心流程线框图（低保真，带标注）
- Tokens决策（字体规范、间距规范、颜色数量上限）
- 状态清单（空状态、加载中、错误、成功、焦点、禁用）
- 上线前所有用户可见文案的诚实性审计

需防范的反模式（针对NEW）：
- 无功能意义的装饰
- 无先例的新颖交互
- 夸大其词的文案
- 设计非目标清单中排除的界面

Template: REFINE DESIGN

模板：REFINE DESIGN

/make-plan Refine <product/screen/component name> based on a Dieter Rams audit (total <X>/30).

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Keep (already strong, do NOT touch in this pass):
- Principle #<N> (<name>) scored 3 — Evidence: <file:line or anchor>. Regression check: <what to grep / re-test to confirm it still scores 3 after the refine>.
- <repeat for every principle that scored 3>

Fix in priority order (top 3–5 moves from the audit, verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
4. <optional 4th>
5. <optional 5th>

Out of scope for this refine pass: <explicit list — what NOT to touch>

Deliverables for the plan:
- Per-fix: target files, exact change, verification step
- Token/spec changes consolidated in one place
- Regression checklist for every "Keep" item above

Anti-patterns to guard against (specific to REFINE):
- Adding new abstractions where a direct change suffices
- Restyling areas that already scored 3
- Scope creep into structural redesign (if structure must change, this should be REDESIGN, not REFINE)
- Letting fixes mutate principles outside the priority list

/make-plan 基于Dieter Rams审计结果（总分<X>/30）优化<产品/界面/组件名称>。

结论段落（引用自03-verdict.md）：
> <粘贴一句话结论>

保留内容（已达标，本次优化不得修改）：
- 原则#<N>（<名称>）得3分 —— 证据：<文件:行号或锚点>。回归检查：<优化后需检查的内容，确保仍得3分>。
- <重复所有得3分的原则>

优先修复项（审计中排名前3–5的改进动作，原封不动）：
1. <原则#——简称>：<具体动作>。证据：<文件:行号或锚点>。
2. <原则#——简称>：<具体动作>。证据：<文件:行号或锚点>。
3. <原则#——简称>：<具体动作>。证据：<文件:行号或锚点>。
4. <可选第4项>
5. <可选第5项>

本次优化非范围：<明确列表——不得修改的内容>

规划交付物：
- 每项修复：目标文件、具体修改内容、验证步骤
- Tokens/规范变更汇总
- 所有保留项的回归检查清单

需防范的反模式（针对REFINE）：
- 直接修改即可解决问题时添加新抽象
- 修改已得3分的区域
- 范围蔓延至结构性重新设计（若需修改结构，应选择REDESIGN而非REFINE）
- 修复过程中影响非优先级原则

Template: REDESIGN

模板：REDESIGN

/make-plan Redesign <product/screen/component name>. Current design failed audit at <X>/30 with critical gaps in principles <comma-separated list of 0-scored or 1-scored load-bearing principles>.

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Why redesign and not refine: <one sentence — usually a load-bearing principle (#2, #4, or #6) scored 0, or total is below threshold>

Preserve from current design (MUST be non-empty — at minimum, name the brand tokens):
- <specific element 1, with file:line>
- <specific element 2, with file:line>
- (if structurally nothing survives, write: "Brand tokens only — color palette and logo. Discard everything else.")

Discard (MUST be non-empty — name the structural patterns causing the failures):
- <pattern 1>. Evidence: <file:line>. Caused failure on principle #<N>.
- <pattern 2>. Evidence: <file:line>. Caused failure on principle #<N>.

Top 3–5 moves from the audit (verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line>.

Redesign principles in priority order:
1. <Principle # — name> — <what success looks like>
2. <Principle # — name> — <what success looks like>
3. <Principle # — name> — <what success looks like>

Deliverables for the plan:
- New information architecture (not derived from old)
- New primary flow (low-fi, labeled, compared side-by-side to current)
- States checklist (empty, loading, error, success, focus, disabled)
- Migration path for users currently on the old design
- Cutover criteria (when is the old design retired)

Anti-patterns to guard against (specific to REDESIGN):
- Porting old structure under new styling
- Keeping both designs behind a flag indefinitely
- Redesigning to follow a trend rather than the principles above
- Treating the Preserve list as optional — it must be filled before this handoff is valid

/make-plan 重新设计<产品/界面/组件名称>。当前设计审计得分为<X>/30，在<逗号分隔的0分或1分核心原则列表>原则上存在严重缺陷。

结论段落（引用自03-verdict.md）：
> <粘贴一句话结论>

为何选择重新设计而非优化：<一句话说明——通常是核心原则（#2、#4或#6）得0分，或总分低于阈值>

需保留的现有设计内容（必须填写——至少保留品牌tokens）：
- <具体元素1，附文件:行号>
- <具体元素2，附文件:行号>
-（若无结构内容可保留，填写：“仅保留品牌tokens——调色板和logo。其余全部舍弃。”）

需舍弃的内容（必须填写——导致失败的结构模式）：
- <模式1>。证据：<文件:行号>。导致原则#<N>失败。
- <模式2>。证据：<文件:行号>。导致原则#<N>失败。

审计中排名前3–5的改进动作（原封不动）：
1. <原则#——简称>：<具体动作>。证据：<文件:行号>。
2. <原则#——简称>：<具体动作>。证据：<文件:行号>。
3. <原则#——简称>：<具体动作>。证据：<文件:行号>。

重新设计的优先原则：
1. <原则#——名称> —— <成功标准>
2. <原则#——名称> —— <成功标准>
3. <原则#——名称> —— <成功标准>

规划交付物：
- 新信息架构（不基于旧架构）
- 新核心流程（低保真，带标注，与当前流程对比）
- 状态清单（空状态、加载中、错误、成功、焦点、禁用）
- 现有用户迁移方案
- 旧设计下线标准

需防范的反模式（针对REDESIGN）：
- 旧结构套新样式
- 长期保留新旧设计切换开关
- 为跟风潮流而非遵循上述原则进行重新设计
- 忽略需保留内容列表——移交前必须填写完整

Key Principles (for the auditor)

审计人员核心准则

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.

证据优先于主观偏好 —— 每个评分都需引用来源；“感觉不对”不能作为结论
基于实际交付物评分，而非预期 —— 设计是已上线的内容，而非草稿
审计自身需诚实 —— 若总分28/30，即使用户想要REDESIGN结论，仍需推荐REFINE；若总分12/30，即使用户想要REFINE结论，仍需推荐REDESIGN
结论唯一，不得模糊 —— 选择NEW、REFINE或REDESIGN中的一个；不得模棱两可
移交任务，而非执行 ——
```
design-is
```
流程在生成/make-plan提示后结束；后续由
```
/make-plan
```
和
```
/do
```
执行
结论一致性 —— 一旦
```
02-scorecard.md
```
撰写完成，结论需严格遵循阶段3的规则。不得为了得到偏好的结论而重新评分；若评分卡显示REDESIGN，移交提示必须为REDESIGN。

Failure Modes to Prevent

需避免的失败模式

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

仅通过截图评分而不读取代码——重新部署结构证据subagent
针对代码库而非设计评分——重新聚焦于用户可见的证据
为软化结论而随意给3分——重新校准阶段2的各原则评分标准
移交提示未引用结论和改进动作——下一环节无相关信息
跳过阶段0的范围锁定——审计错误的界面会浪费阶段1的工作
沉没成本推理 —— 因代码库庞大而推荐REFINE；沉没成本并非设计原则
结论模糊 —— “可能是REFINE或REDESIGN，取决于……”——必须选择一个
为匹配预期结论而抬高评分 —— 先基于证据评分，再根据规则得出结论
阶段0用户偏好覆盖阶段3证据 —— 用户可对结论提出异议，但审计需如实呈现证据结果