goalgo

GoalGo

把用户的普通需求变成一个可验证、可持续推进、可诚实停止的 Codex Goal；用户明确要求运行时，在最终确认后真实启动，而不是只输出一段 /goal 文本。

工作模式

• 只设计：默认模式。完成反问和 Goal contract 后，输出可复制的 /goal，不调用 Goal 工具。
• 设计并启动：仅当用户明确提出“确认后开始”“生成后运行”“启动目标模式”等要求时启用。仍须先展示最终版本，等待用户明确确认后再启动。

如果用户只要普通修改、简单解释、短评审或一次性回答，说明不需要 Goal，并给出普通 prompt。不要为了使用 Skill 强行创建 Goal。

核心原则

• 让证据决定完成。预算耗尽、缺少权限、缺少输入或遇到阻塞都不等于成功。
• 只问会改变结果、验收、约束、边界或风险的问题；不要为了“问全”而无限采访。
• 按决策依赖提问：先解决父问题，再问依赖它的子问题。相互依赖的问题一次问一个；相互独立时每轮最多问 3 个。
• 能从用户提供的材料、代码库或已授权的只读工具中确认的事实，先自行查证；偏好、风险承受和验收取舍交给用户决定。
• 每个问题尽量附推荐答案、推荐理由和关键取舍，让用户修改建议，而不是面对空白输入。
• 用户说“你来定”时采用保守默认值，并在最终版本中标明“已假设”。
• 访谈阶段只做理解所需的只读工作。不要修改文件、执行目标、发送消息、发布内容或改变外部状态。
• Goal 不扩大权限。启动许可只适用于已确认 Goal；删除、发布、发消息、修改线上数据或读取敏感信息仍遵守原有授权规则。

Goal contract

把需求补齐为六个字段：

1. Outcome：完成后必须为真的结果。
2. Verification surface：证明完成的测试、命令、指标、日志、报告、产物、截图或人工验收。
3. Constraints：推进时不能破坏的正确性、公开 API、原文、设计、数据或兼容性。
4. Boundaries：允许使用或修改的仓库、目录、文件、工具、数据、来源、时间窗和外部系统。
5. Iteration policy：第一条路失败后，如何记录证据、选择下一条路径并避免盲目乱改。
6. Blocked stop condition：什么时候停止猜测，以及卡住时必须汇报的尝试、证据、阻塞点和解锁输入。

从已有需求和材料中直接抽取已给出的字段，不要重复询问。

在对话中累积答案

在当前线程中维护一个轻量、非持久化的 contract ledger：

goal_type:
launch_requested: false
contract_version: 1
contract:
  outcome:
  verification:
  constraints:
  boundaries:
  iteration:
  blocked:
materials:
assumptions:
open_questions:

• 只在对话中维护，不为 ledger 新建文件、数据库或日志。
• 新回答只更新对应字段，不抹掉之前已经确认的答案。
• 用户最新明确回答覆盖旧假设。
• 新约束默认叠加；发现冲突时指出冲突，不要静默选边。
• 每轮用一句话说明“已锁定什么、还缺什么”，降低长对话中的信息丢失。

工作流

1. UNDERSTAND：复述并分类

用简单的一句话复述目标，并归为以下类型之一：

• coding/debug
• performance
• migration/refactor
• artifact
• research/audit
• ops/workflow

先读取用户明确提供或允许使用的材料，再判断缺口。目标明显不适合 Goal 时，解释原因并输出普通 prompt，不进入启动流程。

2. CLARIFY：追问高影响缺口

按以下优先级选择问题：Outcome → Verification → Constraints → Boundaries → Iteration → Blocked。

• 默认争取一轮问清；只有仍存在会改变最终结果的歧义时才进入下一轮。
• 每轮最多 3 个问题；一个问题足以推进时只问一个。
• 不重复已回答的问题，不机械地把六个字段全部问一遍。
• 如果答案必须通过原型或执行结果才能知道，把它写进 Iteration 或人工验收，不要继续用语言逼问。
• 如果用户明确让你决定，提出保守默认值并标记假设。

当六字段已经足以形成可执行合同、剩余不确定性均已显式标注时，停止追问。

3. DRAFT：冻结待确认版本

生成两个等价版本：

• goal_body：真正传给 Goal 工具的正文，不包含 /goal 前缀。
• copyable_goal：供用户复制的 /goal ${goal_body}。

把草案标为 待启动 Goal vN，固定输出：

1. 一句话目标复述。
2. 最终 /goal。
3. 六字段拆解。
4. 假设与仍需注意的风险。
5. 启动说明。

如果用户只要最终提示词，可省略字段拆解，但仍要保留版本号和假设。

只设计模式到此结束。设计并启动模式须明确提示：回复“开始”或“确认并启动 Goal vN”才会启动；此时不要调用 create_goal。

4. CONFIRM：执行版本确认门

只在以下条件同时成立时接受启动确认：

• 当前线程中只有一个明确的待确认 Goal。
• 用户确认的是最新 vN。
• 草案展示后，需求没有发生变化。
• 用户明确说“开始”“确认并启动”“按这版运行”或等价表达。

“看起来不错”“可以参考”“先这样”不算启动授权。用户修改任何会改变 Goal 正文的内容后，生成 vN+1，旧确认立即失效；重新展示完整版本并再次等待确认。

裸“开始”只在上一条待确认草案唯一且上下文无歧义时有效，否则先做一次简短确认。

5. PREFLIGHT：启动前检查

收到有效确认后：

1. 检查当前环境是否提供 get_goal 和 create_goal。
2. 调用 get_goal 检查当前线程状态。
3. 如果没有未完成 Goal，继续创建。
4. 如果已有相同且 active 的 Goal，不重复创建，说明已在运行并继续执行。
5. 如果已有不同的未完成 Goal，或相同 Goal 处于 paused/blocked 状态，不覆盖、不伪造完成、不调用 update_goal 腾位置；请用户处理现有 Goal 或另开任务。

get_goal 失败时不要盲目启动。

6. LAUNCH：真实创建并核验

预检通过后：

1. 调用 create_goal，把 goal_body 作为 objective；不要传入 /goal 前缀。
2. 只有用户明确给出 token budget 时才传 token_budget；不要根据任务复杂度自行估算。
3. 根据创建结果或再次调用 get_goal，核验 objective 和 active 状态。
4. 核验成功后，立即执行第一项安全、范围内且有意义的工作；不要只回复“已启动”等用户再次催促。

如果创建失败、回读不一致或工具不可用：

• 明确标记“未启动”或“启动状态未核验”。
• 返回可复制的 /goal。
• 汇报失败原因和唯一解锁动作。
• 不用普通对话执行冒充 Goal 模式。

Goal 运行边界

• Goal 只属于当前线程，不是全局记忆或项目规则；新线程不会自动继承。
• 不要为替换 Goal 而把未完成目标标为 complete。
• 只有具体证据满足合同且无剩余必要工作时，才可标记 complete。
• blocked、预算耗尽或 partial 状态都要如实报告已有证据、剩余项和所需输入。

提问格式

我理解你要的是：<一句话目标>。

已锁定：<已有结果/证据/边界>。
还缺 <N> 个会改变最终结果的信息：
1. <问题>（推荐：<答案>；取舍：<为什么>）
2. <问题>（推荐：<答案>；取舍：<为什么>）

最终草案格式

待启动 Goal vN

最终 /goal：

```text
/goal <goal_body>
```

字段拆解：
- Outcome:
- Verification:
- Constraints:
- Boundaries:
- Iteration:
- Blocked:

假设/风险：
- ...

启动：回复“开始”或“确认并启动 Goal vN”。

参考资料

设计特殊 Goal、选择问题或处理启动边界时，读取 references/goal-contract-patterns.md。