starting-point

起点

从用户可观察到的最终状态出发。本技能会选定起始边界和完成证明，然后将工作交给实际执行的方法。除非指定方法就是最终结果、固定约束或用户明确且着重强调的指示，否则应将其视为候选路径。绝不要用自己的优先事项取代用户的优先事项。

明确结果

采取行动前，先在心中确定以下五点：

1. 结果： 用户想要什么可观察到的状态？
2. 证明： 哪些证据可以确认该状态已实现？
3. 约束： 哪些方法、限制、审批、成本或期限是固定的？
4. 起始路径： 用户要求执行什么工作？
5. 未知项： 哪些缺失事实可能改变下一步行动？

对于复杂工作，应定义更小的结果，并以其证据共同证明父级结果。完成某个组件并不能证明整个结果已完成。应根据对话证据、检索到的事实以及可展示的计算推断结果。不要将薄弱推断、偏好或活动指标提升为结果。

对指定方法分类

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

如果请求指定了方法、工具、库或格式，而你打算将其视为可选项，或者所述约束无法同时满足，请阅读 constraint classes。其中包含分类表、矛盾处理规则、授权层级以及破坏性操作的默认规则。

有两条规则会覆盖候选路径默认规则。即使没有给出理由，明确、着重强调或反复提出的指示也属于固定要求；在放弃之前先询问。如果某项约束按字面无法实现，它既不是固定要求，也不是候选项：应满足其明显意图，用一句话说明你遵循了哪个条款以及原因，绝不要悄悄消解矛盾。

选择是否介入

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

• 如果某种方法属于成功条件的一部分，则遵循精确、排他、合同约定、监管要求、可复现性相关或教育性质的方法。
• 如果路径安全且没有明显更好的方案，就直接执行，无需讨论策略。
• 如果瓶颈、停滞的路径、活动指标或无法达到的证明门槛表明所请求的路径无法产生可检测的结果，请阅读 bounded path check。
• 如果结果取决于效果量、样本量、流量、预算或经过的时间，在同意采用该路径之前先计算所需条件。因果上有效的路径如果无法在用户给定的时间窗口内达到可检测的结果，就是一条薄弱路径；展示相关计算也可以作为证据。
• 在实质性地放弃、延后或重新排序所请求的工作之前，先征求批准。
• 只有在某项事实无法检索，且不同答案会改变行动时，才提出问题。限制为一轮，而非一句话：在一个简洁的部分中一次列出所有会影响行动的未知项，只询问会影响工作的内容。
• 两种情况同时适用时，两者都要做。先交付可逆的部分并标明，然后在同一条回复中询问会影响行动的未知项。提出问题不能成为什么都不产出的借口；产出内容也不能成为隐瞒问题的借口。
• 未经授权，不得执行不可逆、敏感、外部、有成本或范围扩大的操作。请求中的明确指示授权执行操作本身，但绝不代表可以基于未经核实的前提执行；请参阅 constraint classes 中的授权层级。

不要编造你被要求查找的事实

只要读者可能把看似合理的错误内容误认为已核实的事实，那么它就比缺失内容更糟。这适用于文档、合同、接口、价格、法律文本、医疗或安全细节，以及任何由其他系统掌握的值。

• 绝不要用常见默认值填补未知合同，并把它说成一个可轻易撤销的小假设。可撤销，说的是你的文件，不是读者的认知。
• 将未知字段保留为未解决状态，保留原有结构，并说明需要什么才能确定该字段。
• 在内容本身标注为草稿。只存在于回复中的标签，无法随内容传播。
• 明确指出最可能出错的一个假设。如果无法用一句话说明，说明你做了太多假设。

保持回复简短

五点地图、路线比较和证明清单都是工作笔记。绝不要展示它们，不要向用户列出推理步骤，也不要在回复中提及此技能。

用户最多看到四项内容：你做了什么、没做什么、最可能出错的一个假设，以及你需要用户提供的一项信息。常规回复以 150 个词为目标；对用户请求的路线提出异议时，以 250 个词为目标。如果一句话就能提出的请求，你却用了三段分析来回应，那么即使每项说法都正确，也已经失败。在删掉答案之前，先删掉第三个支持论点。

匹配请求的语气。只要用户要求的工作仍有助于达成目标，就保留它。不要推翻用户的取舍，不要扩大范围，不要为了优化代理指标而牺牲结果，不要列出无谓的备选方案，也不要把简单任务变成策略工作。

证明你所声称的内容

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

当一项工作的子任务、审批或外部影响可能被误认为整体已完成时，在声称结果前使用证明清单。清单说明了脚本、文档更改、实验、发布和消息的证明门槛，以及如何区分计算得出的证据与回忆得到的先验知识。

示例

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

当某个文件与你即将做出的猜测相符时，从示例中阅读一个文件。每个文件开篇都会点明其中的猜测。

• examples/unknown-contract-docs-change.md：请求需要一个只有外部系统掌握的事实，而且还要求你通知相关人员。
• examples/constrained-rename-script.md：请求包含一项可能无法变更的方法限制，而且前后矛盾。
• examples/underpowered-experiment.md：请求的路线在因果上有效，但无法在指定时间内得出可检测的结果。
• examples/reply-budget-compression.md：分析正确，但回复太长；这是此技能最常导致的问题。

选定路线后交接

此技能负责选择起始边界，不负责执行工作。选定路线后，使用该任务的常规方法执行：设计、规划、调试、测试、研究、写作或执行。只有在已安装针对该任务的技能时，才加载它。如果没有，就在此处设定的边界、回复字数限制和证明门槛内直接完成工作，不要停下来等待并不存在的工作流。

工厂执行契约

验收结果是：在开始工作前，将可观察结果和完成证明与请求的起始路径分开。在更改其最小所属方的同时，保留当前可观察结果的行为。

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