to-goal

转化为目标

将现有规划和仓库证据整理为执行目标。不要实施、修改跟踪器、创建分支或修改文件。

信息来源

将用户已批准的规划证据视为权威依据，无论其来自对话、规范、问题、文档还是其他技能。不要重新讨论已确定的决策。如果证据不完整，请指出缺少的决策，而不要强迫用户采用特定的规划流程。

接受的输入

解析以下一种输入：

• 无参数：检查当前对话和仓库，找出最新的、已批准且未受阻的工作单元；
• 工单编号或 URL：完整阅读该工单；
• 父级规范问题：阅读规范、子问题和阻塞关系图，然后选出当前前沿工作；
• 本地规范或工单路径：完整阅读该文件及其直接引用的本地规划文档（本地跟踪器：.scratch/<feature>/spec.md，每个工单对应 .scratch/<feature>/issues/<NN>-<slug>.md 下的一个文件）；
• --all <parent>：生成一个按依赖顺序排列、涵盖多个工单的目标。

始终阅读工单评论。对于跟踪器中的父级问题，若有原生子问题和依赖关系，则使用这些关系；否则使用明确写出的阻塞信息。不要仅凭标签推断工单已就绪。

如果无参数输入得到多个前沿工单，请列出它们并让用户选择一个。不要默默将它们合并。如果请求的工单受阻，请报告其阻塞项，不要生成实施目标。

对于无法在一个全新的上下文窗口内完成的工作，应保留其依赖顺序，并生成一个范围明确的前沿目标；只有在用户明确要求时，才生成跨上下文的 --all 目标。建议拆分工作，但不要要求用户采用特定的工单技能。

收集当前证据

起草前：

1. 阅读完整的已批准来源，包括验收标准、修正内容以及直接关联的决策或评论。
2. 检查仓库说明和相关设计术语。
3. 检查当前分支、HEAD、工作区状态、近期提交和差异。记录实施前的 HEAD，作为对比基准。
4. 将当前行为和测试与每项验收标准进行对照。
5. 将标准分类为有证据表明已完成、可明确证明尚未完成或未经验证。提交消息不能作为证据。
6. 从仓库自身的脚本、CI、文档和现有测试中查找验证命令。
7. 保留来源上下文中用户设定的权限和工作区边界。

此工作必须只读。不要仅为构建目标而创建状态文件。

选择范围

默认只选择一个未受阻的工作单元。若来源使用工单，则选择一个前沿工单。生成的目标必须适合一个全新的上下文窗口，且不得引入后续工作。

对于 --all：

• 保留完整的依赖顺序；
• 区分当前前沿工作和未来工作；
• 延续尚未完成的部分，不要将其视为已完成；
• 提醒用户，该目标需要能够续接上下文的持久化工具；
• 绝不要将 --all 描述为 Matt 的常规工作流。

推荐执行能力

根据所需能力对实现会话进行分类，而不是依据硬编码的模型名称。此建议必须适用于 Claude Code、Codex、Pi 和其他编码 Agent。

准确选择一个能力等级：

• 轻量级：范围受限的搜索、清点、格式整理、机械性编辑，或遵循既定模式且失败代价较低的小型更改。
• 标准：常规功能开发、针对性 Bug 修复、测试，或遵循清晰代码库模式的中等规模多文件更改。这是默认等级。
• 高级：复杂的根因分析、跨模块设计、安全或授权更改、架构／数据迁移、并发、长上下文综合，或出错代价高的工作。

准确选择一个推理强度：

• 低：确定性工作，歧义很少且验证成本低。
• 中：需要一定设计判断、涉及多个文件，或测试并非易事。这是默认强度。
• 高：行为存在歧义、约束条件相互作用、有风险的迁移、并发、安全边界，或失败代价高。

推荐能够可靠完成所选工作的最低等级和强度。给出一条简短且基于证据的理由。不要仅因工作量大就推荐更高等级；如果工作无法放入一个全新的上下文窗口，优先考虑拆分。

只有在当前上下文已知目标运行环境及其可用模型选项时，才指定具体模型。如果要指定，请将其作为可选映射，放在通用建议之后，而不要将其作为建议本身。切勿假定模型选项固定为 Luna、Terra 或 Sol 等。

就绪检查清单

此列表供本编译器使用；不要放入粘贴块。

必需命题——起草前逐项勾选。如果其中任何一项未勾选，请停止，不要臆造目标。

• 源材料已准备好供 Agent 使用：证据中包含所有必需的产品决策和完成条件。如果没有，请停止，指出缺失内容，不要重新开始规划访谈。
• 所选工作单元不存在阻塞。如果存在阻塞，仅报告阻塞项；不要生成实现目标。
• 已选定且仅选定一个范围明确的工作前沿。如果有多个同样合理的选项，请列出并让用户选择；不要擅自合并。
• 已记录实施前的 HEAD，作为比较基线。
• 已对每项验收标准进行分类：有证据表明已完成／有证据表明未完成／未经验证。
• 已从代码库的脚本、CI、文档或现有测试中找出验证命令。
• 已保留源上下文中的权限和工作区边界。
• 每项完成标准都可根据可观察证据独立判定；不得包含主观的“看起来不错”之类条件。

条件性禁止事项——在单工单流程中默认已满足。不要勾选这些事项；未勾选不代表需要停止。

• 如果本次运行不带 --all：跳过。如果带 --all：用户已明确提出要求，且目标已标记为跨上下文。
• 没有工单的工作：如果可在一个全新的上下文窗口中完成，直接编译目标；否则建议拆分，但不要求使用特定的规划工具。

目标模板

必填字段必须填写。条件字段仅在适用时出现。将信封内容调整为已知的目标 harness；否则，输出此通用区块，以便粘贴到全新的编码 Agent 会话中。即使 harness 要求的章节更少，当前状态、执行顺序和预填约束仍为必填项。

除非源上下文明确覆盖默认约束，否则原样保留该行。若确实覆盖，请重写该行并注明来源。

如果当前实现尚未完成，请将已验证完成的工作写入 当前状态，并将所有剩余差距写入 完成标准。绝不隐瞒已知差距，也不要要求下一个 Agent 重做已验证完成的工作。

继承源中的每项标准，不得更改产品决策。不要将有证据证明已完成的工作重新列为待办。

目标

<一个范围明确的成果>

当前状态

• 分支：
• HEAD（比较基线）：
• 需保护的脏文件 / 未跟踪文件：
• 有证据证明已完成：
• 已知差距：
• 现有失败：

执行顺序

<所选工作的最短依赖顺序>

完成标准

• <源标准>
• 运行最小适用验证：<command>
• 对照源标准审查最终 diff，并记录基线
• 仅在所有所选标准均通过，且源上下文或用户授权提交后，才进行提交
• 除本任务的更改外，工作区保持干净（不触碰无关的脏文件或未跟踪文件）

约束

• 不要推送、发起拉取请求、合并、关闭 issue 或编辑跟踪器状态
• 不要修改无关的脏文件或未跟踪文件
• 不要提前实现下游工作
• 使用约定的验证切入点，并优先提供行为证据，而非实现细节
• 开发期间始终运行最小适用验证
• 仅当仓库门禁要求、用户明确要求，或更改影响核心逻辑、安全性、数据一致性、并发性或已知错误回归时，才要求进行广泛或完整验证
• 对于低风险的非行为性工作，仅在没有相关测试切入点，或非测试验证已足够时，才允许跳过测试；仍须进行最小适用验证，并要求执行报告说明跳过测试的原因并指出任何剩余风险
• 提交前，对照源标准和已记录的基线审查最终 diff；仅在能带来价值时使用可用的审查工具
• 仅在所有所选标准均通过，且源上下文或用户授权提交后，才进行提交
• 验证范围：最小 | 完整 原因：

上下文

• 已批准的来源：
• 设计文档：
• 约定的验证切入点：
• 优先检查（命令 / 文件）：

交付

仅输出：

1. 已勾选的就绪检查清单——不属于粘贴区块；
2. 已填写的目标模板，可直接复制粘贴；
3. 已填写的会话建议。

• 会话：全新 | 持续目标循环
• 能力：轻量 | 标准 | 高级
• 强度：低 | 中 | 高
• 原因：<根据观察到的任务风险和复杂度写一句话>
• 可选模型映射：<仅当目标 harness 及其模型选项已知时填写>

建议使用直接执行目标的全新会话。来源、分支和已记录的基线已包含所需上下文；不要让全新会话重新进行访谈，也不要要求使用特定的上游技能。

对于 --all，请明确标注目标为跨上下文目标，并建议使用持续目标循环。对于单一明确的工作范围，请建议使用常规的全新实施会话或目标循环会话。无论目标 Agent 如何实现，该目标都应作为执行契约。建议应便于移植：例如，对于带有并发不变量的授权迁移，写 高级 + 高；除非已知 Model X 可用，否则不要指定使用 Model X。