explore

需求已经明确（不存在「不问就可能做错」的歧义）时不要用本技能，让用户显式调用 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 的「未决问题」（用户已答或仓库事实可查的不算）。对象、目标、边界、约束、冲突只是常见自查角度，不是固定轮次，也不限于此：简单需求可能一轮就够，复杂需求轮次不设上限。