定义目标

定义目标 是做什么的？

概述

将用户的意图塑造成一个具体的结果，该结果具有有限的边界以及从请求中得出的完成依据。普通验证使用在主要提示规则下的阅读和逻辑评估；仅在数字表达真实需求时使用数字。

该技能仅涵盖目标定义和目标工具的创建。不要从此技能创建中间计划工件、持久快照、日志、决策记录或恢复文件。

只有根 Main 管理原生目标。选择它不会增加任何测试、审查、委托、权限或其他工作流程。黄金标准独立评估有用的工作状态，无论是否有目标。Notebook 可能会在其自身条件下自动加入已选择的目标，无需额外手动请求；仅靠目标本身并不要求它。根据该策略保留有用的操作笔记，在此定义过程之外；原生客观和状态保持权威性。

仅定义本身不授权执行提议的任务。目标从不取代所需的批准或执行确认：ToSpec 准备不会启动未来的执行目标，而显式选择的准备目标仅关注所请求的准备结果。自动选择不会覆盖用户的暂停，也不会将阻塞、等待批准、回合结束或非丢弃的取消转换为完成。遵循实际的原生状态规则；完成需要实际结果以及所有已强制的操作。

工作流程

1. 评估目标对于当前实际指令是否有用。

   • 当独立请求的结果需要通过依赖阶段、实质性研究或不确定性或长时间执行时，自动选择它，但需遵守步骤6中的权限检查。
   • 简短的问题、直接的简单编辑以及关于未来可能工作的讨论不需要目标。请求的探索本身可以有一个具体的结果；讨论它并不授权执行它。
   • 直接的 /goal、创建目标的请求或要求目标定义会触发此技能，无论复杂性如何。要求无需目标的指令优先于受影响任务的自动选择。
   • 在任务发生实质性变化后重新评估，而不是在每次工具调用时；不使用命令、分钟数或文件的阈值。

2. 以具体术语重述可能的目标。 一个可用的目标需要明确：

   • 将会成为事实的具体成果
   • 涉及的主要工件、系统、仓库、环境或用户可见行为
   • 如何通过阅读和逻辑评估以及任何显式要求的证据来确定实际结果
   • 哪些在范围内
   • 哪些在范围外，当模糊性会产生影响时
   • 停止询问用户的边界条件，而不是无休止地执行

3. 使用代表所请求结果的标准。

   • 从请求中推导出成果、工件路径、范围、格式、值和二进制完成条件。
   • 不要为了形式上的可衡量性而发明指标、阈值、验证器或运行次数。
   • 测试、命令、CI、测量和证据计数仅作为显式请求的经验证据或特定采用程序或更高优先级义务的选项。
   • 对于一般的修复、分析或基于架构的性能工作，通过实际结果和逻辑评估来定义完成。

4. 在设置目标之前修复薄弱的目标。

   • 当请求和本地上下文使该解释安全时，将模糊的目标重写为具体的成果标准。
   • 当缺失的细节会改变预期成果或验证时，提出一个简洁的澄清问题。
   • 拒绝纯活动目标，例如“取得进展”、“继续调查”、“改进事物”或“处理 X”，除非它们被精炼为可验证的成果。

5. 在创建目标之前检查活动目标状态。

   • 从 scope_focus_native_context 读取当前的根原生目标快照。验证 conversationId、goalId、objective 和原生状态（0 未指定、1 活动、2 暂停、3 完成、4 清除）。缺少有效的根状态意味着没有目标；未知的身份/状态是未知，而非不存在。子节点不管理根目标。仅在实际提供时使用原生预算字段；不要虚构它们。
   • 使用可用的原生 create_goal/update_goal 工具及其当前模式。Cursor 的 create_goal 接受 objective；不要传递仅限 Codex 的预算字段。缺失所需的原生能力会阻止其依赖的转换；不要模拟目标或声称完全就绪。
   • 如果没有未完成的目标，目标符合质量标准且步骤6允许创建，则调用 create_goal。
   • 根据当前用户指令和原生状态重用匹配的未完成目标；重复选择不会创建重复项或重复已完成的操作。
   • 保留冲突的未完成目标。不要仅为了腾出空间而重置、替换或将其标记为完成。仅通过允许的原生路径或聚焦的用户问题解决实质冲突；不要要求新线程。

6. 仅在目标通过质量标准后才创建目标。

   • 选择此技能本身并不授权 create_goal。遵循实际工具指令和更高优先级的规则。用户对条件自动目标的采纳，或适用的系统/开发者指令，仅在那些规则接受的情况下提供常设请求。技能可用性或普通任务本身不是该权限；如果主机要求单独的显式请求，则不得推断出与要求相悖的权限。
   • 如果原生目标不可用或不允许，不要使用文件或其他控制器模拟它。继续兼容的授权工作；仅在结果或显式请求的目标至关重要时披露具体的限制。
   • 使用一个简洁的目标字符串。
   • 包括足够的完成依据：通过阅读和逻辑评估的请求结果，加上任何显式强制的证据。每个添加的阈值或方法必须遵循请求；将其写入目标并不创造任何权限。
   • 当范围边界约束工作时包括它们。
   • 预算仅在显式请求且实际原生模式支持时提供。如果请求的预算无法由 Cursor 原生目标表示，则停止该依赖转换并披露缺失的能力；不要静默丢弃或模拟预算。
   • 制定一个明确的允许目标，无需仅仅为了启用模式或批准其技术措辞而再次询问。仅当缺失的选择会实质性改变所请求的结果、权限或强制证据时才询问。仅定义请求仍为仅定义请求。

目标质量标准

在 create_goal 之前，目标应回答：

• 完成时，什么具体的事情将会成为事实？
• 哪些实际物质和逻辑依据会确立它，用户显式要求了什么经验证据？
• 什么请求的结果或有意义的二元或定量条件定义了成功？
• 哪些范围边界很重要？
• 什么应该导致代理停止并询问？

好：

在指定设置中用 B 替换 A。当编辑存在且阅读受影响代码确认与请求一致时完成。

好：

从相关来源和逻辑解决指定的设计问题。当结论得到支持且实质性矛盾得到解决时完成。

弱：

让结账更快。

弱：

继续调查 PR 评论。

量化启发式规则

• 对于缺陷，定义所需的更正并通过受影响的代码和逻辑进行解释。重现和失败后通过的验证需要显式请求该证据。
• 对于显式请求的测试，命名有序场景及其通过条件；遵循指定的命令。
• 对于性能，从机制、工作和上下文进行推理。将计算的复杂性标记为计算；仅从实际测量中声明测量的改进。不要发明指标、目标、方法或运行次数。
• 对于质量工作，使用请求的结果，通常通过阅读和逻辑评估；不要自动添加 lint、类型检查或测试。
• 对于研究，定义研究必须支持的决策、范围内的来源或系统以及证据标准。
• 对于操作，定义所请求的结果状态。不要发明监控窗口、阈值或回滚工作。

澄清问题

仅在合理的重写可能导致追求错误成果时才询问。保持问题简短，并围绕缺失的验证器或范围边界展开。

有用的问题形式：

• “这里成功应该用什么指标定义：延迟、成本、准确性还是用户可见行为？”
• “我应该针对哪个环境进行验证：本地、预发还是生产？”
• “在标记此目标完成之前，您想要的最低限度证据是什么？”

当有意义的准则直接从请求中得出时，无需再次确认即可制定。仅当未解决的选择会实质性改变结果或强制证据时才询问。