用途：把含糊需求收敛成 cooking 目标，仅当用户显式调用 explore，或由 rush 编排触发时使用。需求已明确（不存在“不问就可能做错”的歧义）时不要使用，应由用户显式调用 to-spec；也可用于修改一个尚未归档单位的需求。不写 spec、不改代码。
执行要点：先按 common.md 的“前置检查”节执行。一次调用只处理一个 cooking/<feature>/，其它未完成单位不受影响。新开或扩范围时，先只读其它未归档单位的 goal.md 做冲突检查（没有 goal 则只看 spec.md 标题），冲突未解决不新建。
修改已有单位：若该单位已有“已确认”的 goal.md，或已有 spec.md、tasks/，须立刻把 goal.md 的确认改为“未确认”（没有 goal.md 则按模板新建），并询问用户是补充、改写还是取消。取消时 goal.md 恢复到介入前的状态（原本没有就删掉），下游不动。确认新目标后，若有 tasks/ 则把 node .agents/scripts/cooking.mjs status <feature> 的输出抄进对话纪要，删除该单位的 spec.md、tasks/、reviews/，不回滚代码；其它 cooking 单位一律不动。
决策与提问：核心是钉死全部有歧义的点，凡是“不问就可能做错”的歧义都要问到，并先写入 goal.md 的“未决问题”（用户已答或仓库事实可查的不算）。每一轮从未决歧义中挑最阻塞的问题，一轮最多 5 题，使用交互式提问工具按 question-template.md 提问，不把未决清单当问卷一次倒给用户。查得到的事实派子代理，不问用户；子代理未返回时只挡住依赖该事实的问题。范围边界应尽早钉死。不要问拆任务、改哪些文件、验收条文案。
退出条件：“未决问题”清零才停止，没有默许的假设。把“需求目标 + 范围”交用户确认后才写“确认：已确认”。未确认前每轮按 goal-template.md 回写，不得增删标题。写下“已确认”后，结束语只建议用户新开会话再 to-spec <feature> 或 rush <feature>。