backtthefuture GoalGo
把用户的普通需求变成一个可验证、可持续推进、可诚实停止的执行计划；用户明确要求运行时，在最终确认后直接启动并用 TaskCreate 拆分为可追踪任务，而不是只输出一段文本。
工作模式
- 只设计：默认模式。完成反问和 Goal contract 后，输出可确认的计划草案，不启动执行。
- 设计并启动：仅当用户明确提出"确认后开始""生成后运行""启动目标模式"等要求时启用。仍须先展示最终版本，等待用户明确确认后再启动。
如果用户只要普通修改、简单解释、短评审或一次性回答，说明不需要 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 vN，固定输出：
- 一句话目标复述。
- 六字段拆解。
- 执行路线图：把 Goal 拆解为 3-7 个有序子任务，每个子任务标明产出和验收方式。
- 假设与仍需注意的风险。
- 启动说明。
如果用户只要最终提示词，可省略字段拆解和路线图，但仍要保留版本号和假设。
只设计模式到此结束。设计并启动模式须明确提示：回复"开始"或"确认并启动 Goal vN"才会启动。
4. CONFIRM：执行版本确认门
只在以下条件同时成立时接受启动确认：
- 当前线程中只有一个明确的待确认 Goal。
- 用户确认的是最新
vN。 - 草案展示后，需求没有发生变化。
- 用户明确说"开始""确认并启动""按这版运行"或等价表达。
"看起来不错""可以参考""先这样"不算启动授权。用户修改任何会改变 Goal 正文的内容后，生成 vN+1，旧确认立即失效；重新展示完整版本并再次等待确认。
裸"开始"只在上一条待确认草案唯一且上下文无歧义时有效，否则先做一次简短确认。
5. LAUNCH：拆解任务并启动执行
收到有效确认后，立即启动执行：
- 创建任务列表：用 TaskCreate 把执行路线图中的子任务逐个创建为可追踪任务。每个任务的 subject 用简洁的祈使句，description 写明该任务的产出、验收方式和约束。
- 设置依赖：如果子任务之间有依赖顺序，用 TaskUpdate 设置 addBlockedBy 关系。
- 标记首个任务为 in_progress：用 TaskUpdate 把第一个任务标记为 in_progress，然后立即开始执行第一项安全、范围内且有意义的工作。
- 不要只回复"已启动"等用户再次催促：核验成功后，立即投入执行。
执行过程中：
- 每完成一个子任务，用 TaskUpdate 标记为 completed，然后开始下一个。
- 遇到阻塞时，用 TaskUpdate 在该任务的 description 中追加阻塞点和已有证据，把状态保持为 in_progress，向用户报告阻塞并请求解锁输入。
- 不要跳过未完成的任务去标记后续任务。
- 只有具体证据满足 Verification surface 的要求时，才标记对应任务为 completed。
6. VERIFY：证据验收
所有子任务完成后：
- 对照 Verification surface 逐项检查是否有证据证明完成。
- 如果有未满足的验收项，创建新任务继续推进，不要标记为已完成。
- 全部验收通过后，向用户汇报最终结果：完成的证据、产出的文件/产物、是否有遗留假设或风险。
- 如实报告 partial 状态：已完成什么、未完成什么、原因和所需输入。
Goal 运行边界
- Goal 只属于当前线程，不是全局记忆或项目规则；新线程不会自动继承。
- 不要为替换 Goal 而把未完成目标标为 complete。
- 只有具体证据满足合同且无剩余必要工作时，才可标记 complete。
- blocked、预算耗尽或 partial 状态都要如实报告已有证据、剩余项和所需输入。
提问格式
我理解你要的是：<一句话目标>。
已锁定：<已有结果/证据/边界>。
还缺 <N> 个会改变最终结果的信息：
1. <问题>（推荐：<答案>；取舍：<为什么>）
2. <问题>（推荐：<答案>；取舍：<为什么>）
最终草案格式
待启动 Goal vN
**目标**：<一句话复述>
**字段拆解**：
- Outcome:
- Verification:
- Constraints:
- Boundaries:
- Iteration:
- Blocked:
**执行路线图**：
1. [子任务1] → 产出：...；验收：...
2. [子任务2] → 产出：...；验收：...
3. ...
**假设/风险**：
- ...
**启动**：回复"开始"或"确认并启动 Goal vN"。
参考资料
设计特殊 Goal、选择问题或处理启动边界时，读取 references/goal-contract-patterns.md。