by-design

出于设计

请先阅读这条规则，因为以下每一步都遵循它：每项决定占一行，每条回复最多提出一个问题。

只要能使用 Python 3.11 或更高版本以及 shell，就能运行此技能。它仅使用标准库，无需访问网络。

这个名称就是此技能针对工作中的每个选择提出的问题：这是出于设计，还是随模板一并带来后就保留了下来？

此技能揭示的是决策，而不是评审设计。批评、选择方向和塑造尚未开展的工作，是同一行为在三个时点的体现：决策之后、决策之中和决策之前。因此，任务只需一句话：找出这项工作中的各项决定，指出每项决定舍弃了什么，并说明哪些决定其实无人做出。

最后这一点最有价值。糟糕的设计往往源自无人意识到自己正在做选择的决定，例如沿用了另一页面的网格，或借鉴了竞争对手的语气。

此技能接受哪些命令？

命令	功能
help	显示此表格，并为每个命令提供一行说明。
watch	默认命令。将决策记录到台账中，并且每条回复最多提出一个问题。
judge	阅读现有的屏幕、组件、流程或文案块，并据此填写台账。
choose	列出两个或更多方向之间的权衡，并暂不做出选择。
shape	将台账条目设为空白栏位，供尚不存在的工作使用。
audit	检验简报中声明的哪些约束是真实的，哪些是已固化的选择。
ask	返回完整的问题列表，并保持台账不变。

用户未指定命令时，运行 watch。根据收到的内容选择处理方式，参照此表，并将用户的话视为比附件更优先的信息。

收到的内容	处理方式
一个素材，例如截图、链接或文案块	judge
两个或更多选项，或明确指出了分歧	choose
只有意图，没有任何已构建的内容	shape
一份简报或一组已声明的规则	audit
提出问题的请求，措辞为“给我”或“列出”	ask

如何运行此技能？

按顺序运行每一步。每一步都指定一项操作及其必须产出的结果。如果结果与指定结果不同，请先修正并重新运行该步骤，再继续下一步。 0. 判断是否适用。运行 mise run gate --text "<the request>"。以 not-design 开头的行表示在此结束运行，本技能不会对回复有任何贡献。以 design 开头的行表示继续执行步骤 1。结果：一行判定结果；若为 not-design，则不再执行后续步骤。

1. 读取台账。运行 mise run ledger show --file decision-ledger-<slug>.md。退出码为 1 表示这是新台账，因此运行 mise run ledger init --file decision-ledger-<slug>.md --slug <slug>。结果：文件已存在，你可以列出其中已有的决策。
2. 用一个分句说出立场，使用上方第二个表格中的内容。结果：一个可以写入回复的立场名称。
3. 读取工件以确定其坐标。如果工件是一张图片，先写两行：这是什么，以及它处于什么状态，从 populated、empty、error、loading、offline、disabled 或 mid-flow 中选择。图片本身包含其状态，而对图片的描述通常会丢失这一信息；状态往往就是决策所在。然后运行 mise run locate --file <artifact>，或通过 --text 传入请求；如果状态词有用，也将它们传给 --hint。结果：一个排序列表，每个位置都附有其得分、命中的词数以及命中的词。stderr 中出现 weak read 行表示不应信任此排序，原因可能是排名第一的位置仅由一个词支撑，也可能是前两名过于接近，难以区分。出现此行时，自己说出工件类型，并使用 --hint "<the words for what this is>" 再运行一次；这样，即使某个领域的词汇未被涵盖，也能确定其位置。
4. 提取问题。运行 mise run slice --category "<category>" --stage <stage> --match "<a noun from the artifact>" --limit 20。结果：退出码为 0，并返回问题列表。查看 stderr：widened: 行表示匹配条件已放宽，因此要在回复中说明。如果匹配只找到一两个问题，会先放宽其他条件并保留匹配项，因为来自工件的词才是值得保留的条件。dropped match 行表示问题库没有用你所在领域的语言谈论你的工作，因此要在回复中说明这一点，并根据实际工作而非问题切片来填写其余各行。传给 --match 的词应是工件本身使用的词，因为仅指定类别会返回常见内容，而非当前工件中的内容。
5. 将问题归纳为决策。多个问题通常指向一个选择。删除任何观察结果之前，先将其转化为它所暗示的决策：未标注的网格不是要提及的缺陷，而是一个尚未有人决定如何朗读网格的问题。结果：一份简短的决策列表，条目数少于问题数，且每项观察都对应一行。
6. 每项决策写一行。运行 mise run ledger add --file decision-ledger-<slug>.md --decision "<text>" --chosen "<text>" --trades "<text>" --risks "<text>" --origin <deliberate, inherited, or open>；如果步骤 4 中的问题而非工件引出了该条目，则加上 --source "<question id and url>"。结果：每项决策追加一行，文件会注明哪些条目来自观察，哪些来自问题库。
7. 统计所写内容。运行 mise run ledger count --file decision-ledger-<slug>.md --decision "<text>"，并运行 show，统计回复行所需的条目数和继承条目数。结果：通过命令而非凭记忆获得的数字，步骤 10 会根据文件检查这些数字。
8. 询问脚本是否应发言，以及应提及哪一条。运行 mise run speak --file decision-ledger-<slug>.md --rank，按每条继承条目的信息缺失程度对其排序；然后运行 mise run speak --file decision-ledger-<slug>.md --decision "<the first ranked row>" --origin inherited --live yes。结果：一个排序列表，随后是一行以 ask 或 hold 开头的内容。如果该行以 ask 开头，就在回复中提出一个问题。
9. 根据 assets/reply-template.md 起草回复。结果：四行内容，且每行均已填写。
10. 检查草稿。运行 mise run check-reply --file <draft path>；对于 ask 立场，添加 --full-slice；如果台账不在草稿旁边，则添加 --ledger-dir <folder>。该命令会读取回复中提到的台账，并将其计数与文件内容核对，因此未经命令确认的数字会导致检查失败。结果：输出行 draft passed every rule。任何其他输出行都会指出需要修正的内容；修正后再次运行此命令。

这个技能何时发声？

资源门控：使用此处提到的包文件前，先运行 mise run validate。

第 8 步会回答这个问题，脚本会保存计数，让答案每次都保持一致。只有当某个决策当前需要做出、选择是继承而来的，并且账本中记录它的次数少于三次时，才发声。其他情况下都保持安静，但仍要写入该行。沉默是最常见且正确的结果。

推理规则的参考资料见 references/interruption.md。

何时加载什么？

• references/coordinates.md：在第 3 步读取，了解 35 个类别名称、八个视角和逐步扩展阶梯。
• references/interruption.md：当第 8 步背后的推理很重要，或用户询问技能为何保持安静时读取。
• references/ledger-format.md：在第 6 步读取，了解每一列应填写的内容。
• assets/gate-terms.yaml：门控步骤 0 匹配的词汇表，由门控读取。
• assets/terms-index.yaml：按类别统计的问题中的术语，由 mise run locate 在第 3 步读取。
• assets/trade-terms.yaml：某个专业用于描述自身工作的词汇，手动编写，在第 3 步与统计术语一起读取。如果某个专业被归到错误的类别，请将其添加到此文件，然后运行 mise run bench。
• assets/disciplines.yaml：职业名称本身，以及各个工艺的决策所在的类别，在第 3 步读取，其权重高于行业词汇。
• references/disciplines.md：当工作不涉及屏幕、某种工艺未列出，或第 3 步无法归类该产物时读取。
• references/generation-contract.md：更改此技能的布局、任务图或检查项之前读取，了解结构必须满足的规则。
• references/decisions.md：需要了解此技能为何如此构建时，在更改脚本、阈值或词汇之前读取。
• references/decisions-field.md：当问题涉及衡量方式、夹具或库覆盖了多少种工艺时，与 references/decisions.md 一起读取。
• assets/index.yaml：类别索引，由脚本读取。
• assets/questions/：每个类别对应一个文件，共包含 16,112 个问题。脚本会读取这些文件，回复只引用选中的条目。
• assets/reply-template.md：在第 9 步读取。
• mise run test：运行这些检查。对任何检查运行 --help，都会显示标志、退出代码和示例。
• mise run crafts：运行以查看此技能覆盖了多少种设计职业；使用 --thin 可列出其自身类别覆盖较少的工艺。
• mise run test：更改任何脚本后，运行 mise run test。
• examples/：读取与正在运行的命令相匹配的文件；在信任任何切片前读取 examples/example-widened-slice.md；当第 3 步打印弱匹配提示行时读取 examples/example-weak-read.md；当工作以图片形式提供时读取 examples/example-image-artifact.md；当账本中没有继承条目时读取 examples/example-no-question.md。
• evals/：衡量此技能而非使用它时读取。
• mise run bench：更改词汇、术语索引或评分后，以及在真实设计工作中运行后，都要运行。

如何让真实工作留在这个技能中？

通过此技能完成的每项真实设计任务都会成为永久测试样例，因此之后的更改无法悄悄撤销本次任务的修正。每次处理真实工作后，都要在结束时执行以下步骤。

1. 按照相关专业实际使用的措辞，将需求说明保存到 evals/files/brief-<nn>-<slug>.txt。结果：文件读起来像真实请求，而不是测试。
2. 将最终确定的分类架新增为 evals/files/briefs.json 中的一个键。结果：新增一个键，不更改任何现有键。
3. 将任何应该被门禁拒绝的请求添加到 evals/files/non-design.json。结果：门禁还需要拦截一个请求。
4. 运行 mise run bench。退出码为 1 时会列出所有下降的指标；修复原因后再次运行。结果：显示 exit 0，表示没有任何指标低于已记录的基线。
5. 仅当第 4 步通过且本次运行新增了测试样例时，才运行 mise run bench --update。结果：建立一个之后的运行不得低于的基线。

evals/baseline.json 中的基线记录了门禁指标，以及每个测试样例中正确分类架的排名。排名位置是关键。词汇能力减弱时，分类架的排名会从第二位降到第五位，远在跌出前三之前；只有排名位置能察觉这种变化。

绝不要为了让运行通过而降低已记录的数值。指标下降反映的是更改的问题，而不是测试样例的问题。

这适用于我的专业领域吗？

资源门禁：使用此处提到的包文件之前，先运行 mise run validate。

适用，而最快的方法就是说明你做什么。assets/disciplines.yaml 将两百个职业名称映射到其决策所属的分类架，从艺术总监到船舶设计师，再到花艺设计师，因此只需说出专业领域，就能一步定位到对应部分。在针对六十五个职业进行的评估中，每个职业都用本行业语言描述一行真实工作；所有样例都通过了门禁，其中六十二个首先命中了正确分类架，六十五个全部进入前三名。

此方法不受专业领域限制，但资料库的覆盖深度并不均衡。六十五个专业领域中，有九个在其所属分类架中的资料较少；这些领域已列在 references/disciplines.md 中，而不是留给用户在运行过程中自行发现。资料最丰富的是屏幕、品牌和产品领域；花艺、剪裁和灯光架领域的资料则较少。分类架资料较少时，各列仍然适用，因此可将对应部分视为提示词，并根据实际工作补充其余行。references/disciplines.md 中包含未列出专业领域的分类表，以及需要添加的两行内容，让后来者无需重复摸索。

哪些内容属于其他技能？

事实应由其他技能负责。记录设计背景的技能负责令牌、屏幕清单、验收标准和明示规则。本技能负责决策。两者之间的界限很重要：需求说明中的每条明示规则都是某人做出的选择，随后被写成约束；审计视角正是用来检验这一点。枚举屏幕状态的技能负责状态列表，而本技能则将决策关联到这些状态。

注意事项

• 默认会继续执行步骤 0。只有当请求指定了另一个创作领域，且不涉及设计面时，流程才会停止，因为设计对话使用的是日常用语，仅凭一份设计名词列表无法识别所有这类对话。
• 手动选择类别会把切片放到错误的架子上。步骤 3 会读取产物本身，因此它排在步骤 4 之前，而不是放在步骤 4 里面。
• 步骤 3 提出建议，由你来决定。根据来自 26 个学科的 26 份简报进行评估，正确的架子有 24 次排在第一位，每次都进入了前三名。它会读取两种词汇：一种从问题中统计得出，另一种是为某个学科使用的词汇手动编写的，因此即使用行业术语撰写的简报，例如画面下方的字幕、击杀动态栏，或公交车的提示音，也能得到正确归类。所有错误的排序都会发出提示，因此应将较弱的读取结果视为传入 --hint 的指示，而不是一条备注。
• 如果类别没有 --match，返回的就是该类别中常见的内容，而不是你眼前的内容。请传入产物使用的名词。
• 在步骤 4 查看 stderr。扩大的切片看起来与精准切片相同，但回答的是更宽泛的问题。
• 写之前先分组。关于结账页面的 20 个问题通常会归纳为四五个决定。
• 任何你注意到却没有记下来的内容都会丢失。决策账本记录的是选择，因此应将观察表述为它所意味着的选择，并为其添加一行，而不是把它留在回复中或直接删掉。
• 在选择和塑形期间，将已选列留空。空白单元格就是交付物。
• 预期会有继承的行。如果账本的每一行都显得经过刻意选择，说明审计跳过了步骤 5；如果一行都没有，则无法提出问题，而步骤 10 会强制检查这一点。在这种情况下，第四行只写 none。
• 类别名称必须完全匹配。名称不匹配时会以状态码 2 退出，并打印收到的名称。
• 切片输出会将长破折号替换为逗号或冒号。存储的文件会保留原有标点。

何时算完成这项技能？

如果判定为 not-design，则在步骤 0 就完成，无需编写或说出任何内容。否则，当决策账本对每个决定都各有一行、每行都标明来源、回复遵循模板且计数取自本轮运行的命令，并且 mise run check-reply 输出 draft passed every rule 时，工作即告完成。

工厂执行约定

可接受的结果是：将指定的设计意图转化为一份经过审查、由渲染证据支持的设计决策账本。在变更范围最小的所有者时，保留当前设计决策账本的行为。

1. 使用 mise run ci 冻结当前软件包，并记录其摘要。
2. 运行 mise run domain-research-policy，然后评估当前设计决策账本的来源和反证。
3. 针对指定的设计决策账本操作运行 mise run agentic-request。将语义选择交由模型处理。
4. 运行 mise run decision-policy、mise run ci 和行为评估。返回到最低层的失败所有者。
5. 运行 mise run invocation-policy -- <receipt>，并说明每项任务的情况，或说明为何不适用该领域。
6. 可选择运行 mise run improvement-policy。仅当没有受保护的维度出现退化时，才保留一项变更的维度。

只有在需要其约定时，才通过 mise run use-case-policy 加载 assets/use-case-contract.json，并通过 mise run evals 加载 evals/evals.json。

Mise 负责可重复的机制、顺序、凭据和检查。模型负责解读、因果判断、创造性工作，以及代码无法提供的直接感知。遇到缺少授权、证据过时或门禁失败时，立即停止。