When the requirement is already clear (there is no ambiguity that could lead to doing it wrong if not asked), do not use this skill; have the user explicitly invoke to-spec. It can also modify the requirement of a unit that has not yet been archived. Do not write a spec, do not change code. Rambling and pretentious profundity are prohibited.
Pre-checks
Follow the common.md "Pre-checks" section.
Unit
One invocation handles only one cooking/<feature>/. Other unfinished units in the repository are unaffected, and new units can be opened separately. If the user mentions multiple unrelated things at once: clarify which one this session is about.
New or scope expansion: first read-only the goal.md of other unarchived units to do a conflict check (if there is no goal, only look at the spec.md title). If a conflict is unresolved, do not create a new one.
Modify an existing unit(the unit already has the 已确认 of goal.md, or already has spec.md / tasks/): immediately change the goal.md confirmation to 未确认(if there is no goal.md , create one according to the template); ask the user whether it is a supplement, rewrite, or cancel. Cancel:goal.md restore to the state before intervention (delete it if it did not originally exist), leave downstream untouched. After confirming the new goal: if there is tasks/ , copy the output of node .agents/scripts/cooking.mjs status <feature> into the conversation minutes, delete that unit's spec.md、tasks/、reviews/, do not roll back code. All other cooking units remain untouched.
Decision tree
The core is to nail down allambiguouspoints and synchronize the mental model with the user: any ambiguity where "not asking could lead to doing it wrong" must be asked about. At the start, write every ambiguity currently conceivable into goal.md "Open Questions" (those the user has already answered or that can be found from repository facts do not count). Objects, goals, boundaries, constraints, and conflicts are only common self-check angles, not fixed rounds, and are not limited to these: a simple requirement may need only one round, and for a complex requirement there is no upper limit on rounds.
Each round:
- Fromunresolved ambiguities, pick themost blockingto ask; do not ask just to fill a quota; at most 5 questions per round.
- Use the
交互式提问tool to ask according to question-template.md , anddo notdump the open-questions list on the user all at once like a questionnaire. - Only after the user answers can the specific questions for the next round be decided; ambiguities that newly emerge during discussion should be added to "Open Questions" at any time.
- Dispatch a subagent for facts that can be looked up; do not ask the user. When the subagent has not returned: block only the questions that depend on that fact, and ask the rest of this round as usual.
Nail down the scope boundaries (included / not included) as early as possible; "we'll discuss scope later" is prohibited.
Do not ask about task breakdown, which files to change, or acceptance-criteria wording.
Exit
Stop only when "Open Questions" is zeroed out: no tacit assumptions. Only after handing "requirement goal + scope" to the user for confirmation, write 确认：已确认. Before confirmation, write back each round according to goal-template.md , and do not add or remove titles.
After writing 已确认 , the closing words say only one thing: suggest that the user open a new session and then to-spec <feature> or rush <feature>. Multiple rounds of Q&A have already occupied this conversation's context; do not continue here to write the spec or dispatch downstream.