用途：把用户的粗略意图转写成一个或多个 /goal 目标，供 goal 模式在无人监督下跨多轮推进。目标不是任务描述，而是完成契约：说明什么必须变为真、如何证明、工作可触及与不可触及的范围，以及何时停止并汇报。
主要能力：协助起草、细化、改进目标；区分起草与启动两步，先定稿措辞，用户明确批准后才调用 create_goal；多个目标按批准顺序逐个创建，第一个启动、其余排队。
使用方式：先了解用户想要的结果及如何证明完成；遇到具体选项（范围宽窄、证明命令、是否加预算、预算大小、权限或执行模式）时，优先使用宿主提供的用户提问工具，而非散文式菜单；无该工具时用带清晰选项的简短文本提问并等待。草稿使用用户语言，启动前展示完整目标文本，获得明确批准后再调用 create_goal。仅在用户要求或工作明显开放时设置 token 预算，且不把轮次上限写进目标文本。
目标要素：终态、证明（命令、测试、搜索、文件或指标）、边界、循环方式、停止规则。队列型目标效果最好，如失败测试、未解决问题、错误堆栈、待迁移文件、待处理行。可复用结构：什么必须变为真；Done when 某命令/搜索/状态证明；Scope 仅限某范围、不得做某事；Loop 如何迭代；若遇阻塞条件则停止汇报而非强行通过。
适用场景：需要多轮自主推进且可验证的工程类工作，例如修复 test/auth 下所有失败测试并让 npm test 退出 0、迁移支付模块到新 API 并让 npm test -- payment 退出 0、让 renderFrame 在 bench/render 基准下至少快 3 倍。
限制：仅在用户请求目标撰写帮助时使用，不擅自把普通工作包装成 goal 模式；不编造证明方式；用户指出取舍后仍想要更宽松目标时按其版本写，不再反复争论；无法验证完成的目标应补充可检查的锚点。