design-like-im-5

像给五岁小孩讲一样进行设计

打造可用的产品，同时不掩盖事实、成本、风险、状态或控制权。完整支持流程请参阅 references/section-support.md，并运行 mise run section-support。

一套契约

• 尽量缩短完成经验证的所属产物变更所需的时间。保留探索性和实验性的广度、正确性、每一道关卡，以及由同一执行器完成视觉检查的愿景。
• assets/speed-policy.json、assets/speed-policy.schema.json 和 evals/speed-budgets.json 通过 mise run complete 管理安全调度和边界。
• assets/workflow.json 是唯一的步骤顺序。assets/execution-ownership.json 是唯一的负责人映射。通过 mise run task-graph 和 mise run ownership 检查两者。不得跳过、合并、替换或重新排序任何必需步骤。
• assets/context-routing.json、assets/context-routing.schema.json 和 assets/context-bundle.schema.json 通过 mise run context-routing 管理路由和数据包结构。assets/section-support.json 和 assets/section-support.schema.json 通过 mise run section-support 管理标题支持。通过这些任务阅读 references/context-routing.md 和 references/section-support.md。路由变更后重新检查。
• 模型可以在权利和否决权范围内添加、拆分、混合、反转或拒绝选项。所有视觉、脑力和触控审查均由模型完成。模型会检查所有糟糕设计、糟糕输出和糟糕实践规则。通过 mise run human-sweep 阅读 references/review.md，并保持画布整洁。脚本不能授予设计或整洁度方面的 PASS。
• 事实、访问、任务、感知、熟悉度、标准、独特性、工艺和韧性都必须分别通过。以零信任为起点。将继承的工作标记为 STALE，先观察，保留已通过项，并拒绝不必要的重新设计。用证据支撑主张；绝不通过平均结果掩盖失败。
• 最重要的视觉验证规则规定：通过测量关卡后，以直接观察为最终依据。同一位发起任务且具备强视觉能力的执行器，必须通过所有适用且可用的视觉能力检查当前像素。在每次变更和失效前后，检查不同状态、视口和输入路径下的完整视图及细节。代理检查可以否决，但不能授予视觉方面的 PASS；无法直接观察时为 BLOCKED。
• 在多页面工作中，每个深度一级负责人都必须有一个经过说明的规范页面，并检查其后代页面。位置错误、重复项、孤立项、过期工作和移动都会阻塞受影响的视图。当前的视觉、脑力和触控判断必须通过。
• 在纵向和横向模式下检查每个移动设备和平板电脑层，包括在支持时检查屏幕旋转。验证层级、触达范围、安全区域、换行、密度、间距、状态和输入。只有在结构或行为发生变化时才添加方向 API；否则保留一个负责人，并验证两种环境。
• skill-factory 更新模式负责管理软件包变更。运行 mise run domain-research-policy、mise run use-case-policy、mise run mise-primitives-policy、mise run primitive-lifecycle-policy、mise run task-graph-policy、mise run decision-policy 和 mise run improvement-policy。长提示词和开放式产品设计工作请使用 mise run agentic-request。Mise 任务会检查结构，但不会做设计判断。
• 在 Computer Use 审计期间，将 computer-use 用作平台无关的本地应用控制能力。同一执行器必须直接检查当前活动的设计应用（包括 Figma），并负责处理每一项；否则该项为 BLOCKED。Figma 审计还需要生命周期回执，并且每项都要有一条来源记录。在该审计之外，本技能保持独立。

有序工作流

对于一次完整使用，按照 examples/run.md 执行 mise run examples。assets/workflow.json 通过 mise run task-graph 按固定顺序组织整个运行流程。

命令

• help： 说明输入、输出、路由、任务和停止条件。按照 examples/help.md 执行 mise run run-help。不要开始工作。
• run： 创建、审核或修订。审核不会更改任何产品文件。修订只更改已批准的文件。
• 模型开始工作前： 在首次运行前，以及任何任务、路径、数据包或输出变更后，通过 mise run examples 阅读 examples/run.md 和 examples/context-packets.md。
• 上下文不完整时： 通过 mise run evals 对比 evals/files/valid-context-record.json 和 evals/files/missing-context-record.json。缺少事实或证明字段时，通过 mise run examples 使用 examples/failure-missing-proof.md。不要猜测。

准备运行

运行检查清单：

• 1. 通过 mise run run-scaffold 阅读 assets/workflow.json、assets/execution-ownership.json 和 assets/context-routing.json。固定其顺序、负责人、路由和路由哈希。
• 2. 阅读 references/intake.md，并通过 mise run run-start 将事实写入 assets/run-intake.schema.json。缺少必要事实时，仅停止受影响的工作。
• 3. 运行 mise run run-start --intake INPUT --run-dir RUN。
• 4. 将 RUN 保存在此技能文件夹之外。不要手动构建其中的文件或字段。
• 5. 阅读下一个数据包列出的所有路径。
• 6. 数据包要求人工审核时，运行两个审核任务。
• 7. 每个运行文件只由一位写入者负责。

该任务会写入固定的运行表单和路由哈希，但不会选择状态、规则、选项或结果。

按顺序完成所有操作

• 通过 mise run task-graph，按顺序执行 assets/workflow.json 中的每项操作。操作前加载每个指定的源文件。保存指定的证明。
• 每个运行任务都会拒绝尚未轮到的工作。
• 在单项操作中，固定输入后，可批量进行互不依赖的读取、渲染、捕获和检查。
• run-start 会完成操作 1 和 2。其下一项操作必须是 source_meaning。

1. [CTX-FREEZE-INTAKE] freeze_intake。 Mise：mise run run-start 会检查并冻结接收内容。模型：通过该任务应用 references/intake.md 和 evals/files/missing-proof.json；切勿捏造事实。
2. [CTX-LIST-CAPABILITIES] list_capabilities。 Mise：mise run run-scaffold 会展示固定的能力表单。模型：通过该任务应用 references/failure.md，绝不可把结构当作视觉或触摸证明。
3. [CTX-SOURCE-MEANING] source_meaning。 Mise：mise run run-packet 会路由 references/research.md、evals/source-mapping.json 和 evals/context-cases.json。模型：记录源文件含义及反证。
4. [CTX-STATE-JUDGMENT] state_judgment。 Mise：运行 mise run run-packet、mise run review-checklist 和 mise run human-sweep。模型：通过这些任务应用 references/product-states.md，并发现产品状态。
5. [CTX-SELECT-RULES] select_rules。 Mise：运行 mise run run-select-rules --run-dir RUN。模型：通过该任务应用 assets/simplicity-contract.json 和 references/decisions.md，并保持固定的否决顺序。
6. [CTX-ATOM-JUDGMENT] atom_judgment。 Mise：运行 mise run run-packet。模型：通过该任务应用 assets/lineage.schema.json 和 evals/files/valid-lineage.json，仅判断有证据证明的原子项。
7. [CTX-PART-DESIGN] part_design。 Mise：运行 mise run run-packet 和 mise run lineage-file MANIFEST。模型：通过这些任务应用 evals/files/skipped-lineage.json，仅基于已锁定的下层归属项进行构建。
8. [CTX-SCREEN-DESIGN] screen_design。 Mise：运行 mise run run-packet。模型：通过该任务应用 references/build.md 和 examples/context-packets.md，并根据有证据证明的部件构建屏幕。
9. [CTX-MOTION-JUDGMENT] motion_judgment。 Mise：运行 mise run run-packet 和 mise run human-sweep。模型：通过这些任务应用 references/review.md。绝不可从静态图推断动态效果。
10. [CTX-VISUAL-REVIEW] visual_review。 Mise：运行 mise run run-packet、mise run review-checklist 和 mise run human-sweep。模型：通过这些任务应用 assets/review-record.schema.json，并检查当前像素表现及使用情况。
11. [CTX-PLAIN-READBACK] plain_readback。 Mise：运行 mise run run-packet。模型：通过该任务应用 evals/cases.json。即使措辞清晰，只要状态不正确，也绝不可接受。
12. [CTX-CHECK-LINEAGE] check_lineage。 Mise：使用 assets/lineage.schema.json 运行 mise run lineage-file MANIFEST --run-dir RUN。模型：仅依据链接和证据给出有限结论，绝不可评价设计质量。
13. [CTX-FINAL-CHECK] final_check。 Mise：运行 mise run run-check --run-dir RUN，然后使用 evals/contract.md 和 evals/rubric.md 运行 mise run complete。模型：拒绝任何将任务证明转化为设计证明的尝试。

构建每个模型数据包

• 运行 mise run run-packet --run-dir RUN --action ACTION。应用 assets/context-bundle.schema.json，加载其路由，并记录已使用或缺失的上下文。缺失必需上下文时，标记为 BLOCKED。
• 至少创建四种截然不同的起点：已知、产品导向、反转和奇特。围绕状态、结构、词语、操作、动作、声音、触感、访问、平台和服务效果添加、拆分、混合或反转这些起点。为每种起点提供场景、主张、证据、成本、否决项、测试和新颖性说明。在证据或否决项将大胆方案排除之前，始终保留该方案。
• 保留设计层之前，通过 mise run test 应用 references/controlled-comparisons.md。比较不同方向的材料，并在观察之前冻结证据。由当前的视觉、脑力、触感、糟糕设计、糟糕输出和糟糕实践判断来做选择。小幅优化需要请求、缺陷或阈值证据。
• 通过 mise run test，在 references/build.md 中创建规范的焦点意图记录。判断用户应注意什么、在哪里、何时、如何、为何以及按什么顺序注意。填写字段和突出显示内容并不能证明成功。
• 使用 mise run run-record --run-dir RUN --result RESULT，在执行任何后续操作之前保存结果。

评判设计

通过 mise run run-select-rules，将 references/decisions.md 与 assets/simplicity-contract.json 配合使用。模型负责每一项设计选择。

否决与失败规则

• 按以下顺序应用否决项：安全、访问、理解、自主性、任务成功、惯例、表达、新颖性，最后是构建成本。
• 不得牺牲安全、访问、理解或自主性。不得隐瞒成本、风险、工作或控制权。
• 通过 mise run run-check 阅读 references/failure.md，检查缺失的事实、权利、来源、视觉信息、原子级证据、上下文、冲突和变更。
• 对受影响的主张返回 BLOCKED。指出未通过的关卡、缺失的证据、关联部分、安全可行的工作，以及恢复所需的最小步骤。
• 将观察到的工作诊断为 DEFECT、MEDIOCRE、SLOP 或 PASS，而不是评价其创作者。通过最低要求、熟悉的惯例、独特的风格、构建便利性或数值平均值，都不能抵消其他未通过的关卡。

发现产品状态

• 通过 mise run run-packet 阅读 references/product-states.md、assets/state-record.schema.json、examples/product-states.md 和 evals/section-support-cases.json，然后运行 mise run review-checklist 和 mise run human-sweep。
• 根据证据发现状态，不要受封闭列表限制。检查用户、目标、过去的行为、数据、系统、地点、设备、输入、时间、内容、相关人员和风险。状态可能重叠、嵌套、冲突或发生变化。
• 创建彼此不同的响应。记录原因、关联、证据、疑点、权衡和选择。保持未知、混合、过时、短暂和并发状态开放。绝不请求私密的思维链。

运行每项评审不变量

• 对固定 ID 运行 mise run review-checklist，对开放式提示运行 mise run human-sweep。通过该任务应用 references/review.md。
• 眼睛、大脑、触觉： 检查视线顺序、分组、变化、内容、真实性、操作、记忆和语言。还要检查反馈、风险、目标、缺口、触达、提示、手势、修复和投入。
• 失败项： 拒绝重叠、裁切、控件被遮挡、工作丢失、死胡同和焦点错误。拒绝隐藏状态、过时证据、薄弱选项、残留内容、状态混杂区域和延后清理。
• 证据： 区分事实、视觉观察、推断和变化。NOT_APPLICABLE 需要证据；缺少证据即为 BLOCKED。源代码或产品发生变化时，受影响的截图和检查即告失效。
• 回答： 给出场景、观察、证据、选择、理由、选项、成本、否决项、疑虑和明确标注的估算。
• 质量： 通过 mise run human-sweep 使用 references/review.md。在确认真实性、可访问性、任务和感知之后，要求具备独特性、符合标准且易于识别。保留眼睛、大脑、触觉、整体视图、细节、响应式和输入路径方面的证据。

基于已验证的部分构建

• 在处理原子或部件之前，通过 mise run lineage-file 阅读 references/build.md。
• 使用 token proof -> tokens -> atoms -> molecules -> organisms -> UI composition templates -> screens -> flows。
• UI composition template 是可复用的屏幕结构。Code Connect mapping template 是一种代码库映射产物。它不是产品设计层，二者也不能互为证明。
• 对所有源令牌和原子运行当前的 dtcg-tokens skill。不要复述其方法。
• 如果缺少该 skill 或相关证据，请停在原子关卡。屏幕不得自行引入低层规则。
• 低层内容发生变化后，将关联的高层部件标记为过时。重建并评审所有受影响的部件。
• 运行 mise run lineage-file MANIFEST。该命令会检查链接、顺序、循环、过时部件和未使用部件，但不会评判质量。

验证并完成

通过 mise run run-record 使用 assets/model-record.schema.json 保存证据。通过 mise run evals 使用 evals/contract.md 进行最终检查。

记录模型工作

• 使用 assets/model-record.schema.json、assets/state-record.schema.json 和 assets/review-record.schema.json，通过 mise run run-record 记录常规、状态和视觉记录。
• 运行 mise run run-record --run-dir RUN --result RESULT。该命令仅检查结构。当前证据、可见理由、选项、成本、否决项和疑虑由模型提供。

阅读规范与包维护者

• assets/reading-contract.json 和 assets/reading-exceptions.json 通过 mise run reading 负责阅读规则。SKILL.md 使用标准 YAML 标头和可移植的 CommonMark。只有在公开内容发生变化后，才通过 mise run generate 阅读 references/generation-contract.md。
• assets/file-manifest.json 通过 mise run file-manifest 负责文件角色；evals/source-lineage.json 通过 mise run source-lineage 负责哈希；assets/workflow.json 和 assets/execution-ownership.json 通过 mise run run-scaffold 负责运行结构。
• mise.toml 通过 mise run task-graph 负责任务；.github/workflows/ci.yml 调用 mise run ci。保持 UTF-8、LF、ATX 标题、块间空行和相对链接。每个块都必须整洁、易读且可供 Agent 解析。
• 运行 mise run skill-info，使用 mise run generate 重新生成已更改的公开源文件，最后运行 mise run complete。Mise 会并行运行互不依赖的检查，且绝不会缓存或跳过必需任务。

Eval 负责人映射

• 仅在处理 eval 时加载 eval 文件。evals/manifest.json、evals/contract.md、evals/rubric.md、assets/eval-case-template.json、evals/cases.json、evals/trigger-cases.json、evals/evals.json、evals/trigger-queries.json、evals/section-support-cases.json、evals/context-cases.json 和 evals/speed-budgets.json 通过 mise run evals 运行。
• references/proof-ladder.md、assets/proof-ladder.json、examples/proof-ladder.md 和 evals/pilot-cases.json 通过 mise run proof-ladder 运行。试点运行两次；不变量冲突属于 STALE。
• evals/source-lineage.json 和 evals/source-mapping.json 通过 mise run source-lineage 管理来源证明。evals/files/valid-intake.json 和 evals/files/missing-proof.json 通过 mise run run-start 运行；evals/files/valid-lineage.json 和 evals/files/skipped-lineage.json 通过 mise run lineage-file 运行。
• Fixture 通过仅能证明任务完成，不能证明可见性、使用、访问、品味、产品价值或选择。

返回与完成

完成清单：

• 返回产品文件和运行证明。注明来源、缺口、状态、选项、选择、评审、原子证明、链接、过时部分、上下文缺口和否决项。按照 examples/run.md 和 examples/failure-missing-proof.md 中的停止格式，通过 mise run examples 运行。
• 仅使用 PASS、STALE 或 BLOCKED。绝不能把任务通过转化为关于像素、使用、访问或价值的断言。确认每条记录和上下文路径均已提供、每个必要视图均已查看，且没有尚未解决的否决项。
• 运行 mise run run-check --run-dir RUN。然后运行 mise run complete。
• 仅当 mise run complete 以代码 0 退出后，才返回 PASS。
• 可选的最后一步： 必需的产品工作通过后，运行 mise run improvement-policy，在其最小责任归属处修改一个指定部分，然后重新运行 mise run complete。只有该部分有所改善时才保留修改。速度、真实性、可见性、选择、测试和所有当前规则都不得变差。如果任何部分变差，请恢复到上一个通过的版本并检查其摘要值。