backtthefuture GoalGo
把用户的普通需求变成一个可验证、可持续推进、可诚实停止的 Codex Goal；用户明确要求运行时，在最终确认后真实启动，而不是只输出一段 /goal 文本。
工作模式
- 只设计：默认模式。完成反问和 Goal contract 后，输出可复制的
/goal，不调用 Goal 工具。 - 设计并启动：仅当用户明确提出“确认后开始”“生成后运行”“启动目标模式”等要求时启用。仍须先展示最终版本，等待用户明确确认后再启动。
如果用户只要普通修改、简单解释、短评审或一次性回答，说明不需要 Goal，并给出普通 prompt。不要为了使用 Skill 强行创建 Goal。
核心原则
- 让证据决定完成。预算耗尽、缺少权限、缺少输入或遇到阻塞都不等于成功。
- 只问会改变结果、验收、约束、边界或风险的问题；不要为了“问全”而无限采访。
- 按决策依赖提问：先解决父问题，再问依赖它的子问题。相互依赖的问题一次问一个；相互独立时每轮最多问 3 个。
- 能从用户提供的材料、代码库或已授权的只读工具中确认的事实，先自行查证；偏好、风险承受和验收取舍交给用户决定。
- 每个问题尽量附推荐答案、推荐理由和关键取舍，让用户修改建议，而不是面对空白输入。
- 用户说“你来定”时采用保守默认值，并在最终版本中标明“已假设”。
- 访谈阶段只做理解所需的只读工作。不要修改文件、执行目标、发送消息、发布内容或改变外部状态。
- Goal 不扩大权限。启动许可只适用于已确认 Goal；删除、发布、发消息、修改线上数据或读取敏感信息仍遵守原有授权规则。
Goal contract
把需求补齐为六个字段：
- Outcome：完成后必须为真的结果。
- Verification surface：证明完成的测试、命令、指标、日志、报告、产物、截图或人工验收。
- Constraints：推进时不能破坏的正确性、公开 API、原文、设计、数据或兼容性。
- Boundaries：允许使用或修改的仓库、目录、文件、工具、数据、来源、时间窗和外部系统。
- Iteration policy：第一条路失败后，如何记录证据、选择下一条路径并避免盲目乱改。
- 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，固定输出：
- 一句话目标复述。
最终 /goal。- 六字段拆解。
- 假设与仍需注意的风险。
- 启动说明。
如果用户只要最终提示词，可省略字段拆解，但仍要保留版本号和假设。
只设计模式到此结束。设计并启动模式须明确提示：回复“开始”或“确认并启动 Goal vN”才会启动；此时不要调用 create_goal。
4. CONFIRM：执行版本确认门
只在以下条件同时成立时接受启动确认：
- 当前线程中只有一个明确的待确认 Goal。
- 用户确认的是最新
vN。 - 草案展示后，需求没有发生变化。
- 用户明确说“开始”“确认并启动”“按这版运行”或等价表达。
“看起来不错”“可以参考”“先这样”不算启动授权。用户修改任何会改变 Goal 正文的内容后，生成 vN+1，旧确认立即失效；重新展示完整版本并再次等待确认。
裸“开始”只在上一条待确认草案唯一且上下文无歧义时有效，否则先做一次简短确认。
5. PREFLIGHT：启动前检查
收到有效确认后：
- 检查当前环境是否提供
get_goal和create_goal。 - 调用
get_goal检查当前线程状态。 - 如果没有未完成 Goal，继续创建。
- 如果已有相同且 active 的 Goal，不重复创建，说明已在运行并继续执行。
- 如果已有不同的未完成 Goal，或相同 Goal 处于 paused/blocked 状态，不覆盖、不伪造完成、不调用
update_goal腾位置；请用户处理现有 Goal 或另开任务。
get_goal 失败时不要盲目启动。
6. LAUNCH：真实创建并核验
预检通过后：
- 调用
create_goal，把goal_body作为objective；不要传入/goal前缀。 - 只有用户明确给出 token budget 时才传
token_budget；不要根据任务复杂度自行估算。 - 根据创建结果或再次调用
get_goal，核验 objective 和 active 状态。 - 核验成功后，立即执行第一项安全、范围内且有意义的工作；不要只回复“已启动”等用户再次催促。
如果创建失败、回读不一致或工具不可用：
- 明确标记“未启动”或“启动状态未核验”。
- 返回可复制的
/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。