to-spec

to-spec

Do not split tasks or modify business code. explore is not a prerequisite: without goal.md you can also write a spec. If the requirement still cannot be written as decidable acceptance criteria: stop, suggest the user first explore, and do not open a decision tree in this skill.

Pre-check

Follow the "Pre-check" section of common.md .

Parameters

For identifiers and matching rules, see common.md。

• Matched identifier: write that unit. The text after the identifier is treated as the requirement description.
• Not matched and the parameter is non-empty：
  • Only one segment of kebab-case(no spaces, no Chinese): treat it as a new identifier; the requirement comes from this conversation, do not treat the slug as the requirement body.
  • Otherwise the whole segment is the requirement description; generate a kebab-case slug and start a new one.
• Parameter is empty: if there are 0 cookings, generate a slug from the conversation and start a new one; if there is 1, write it; if there are multiple, ask which one to write or whether to start a new one. After settling on a unit, its "next step" in the overview is explore（goal 未确认）: stop.

Workflow

1. Determine <feature>. When starting a new one, only read the goal.mdof other cookings (if none, look at the spec.md heading) for conflict checking.
2. Input priority: this requirement description > confirmed goal.md > requirements already clearly stated in this conversation. Do not expand the scope beyond what is in these sources.
3. Read docs per the root AGENTS.md: for code-related work, read ARCHITECTURE.md、DEV-STANDARDS.mdwhen needed, and search CODE-MAP.mdby module name/path; do not load the full text; for non-code work, do not open these three.
4. Write spec-template.md per spec.md. Do not add or remove headings.
5. Acceptance criteria must be decidable. "Good experience" and "improve as much as possible" are prohibited.
6. Write "Affected files" per impact-files.md : list only repository-relative paths or globs of files that this spec adds / deletes / modifies (one per line, wrapped in backticks). It is a scope declaration, not an exhaustive list: for specs expected to touch about 10 or more files or with uncertain boundaries, use a directory-level glob narrowed to a module (such as src/sheet/**); only narrow changes use exact paths. Do not read through candidate files just to enumerate precisely; use CODE-MAP search plus spot checks to locate them. At least one addition or modification; if there are no deletions, omit the deletion line. Do not write module names. After writing, run node .agents/scripts/spec-files.mjs parse .agents/cooking/<feature>/spec.md; if it fails, fix it until it passes before finishing.
7. "Architecture impact" is determined here, not left for implement to discover midway. Code-related: inspect each "added" path one by one (for a glob, take the first directory segment); for any whose directory is not under any path in the CODE-MAP.md module table, determine whether it is a new module within the same layer (it does not count; add a CODE-MAP line during implement) or an architecture-level change (it counts; see the definition in the "Architecture-level changes" section of code-map-update.md ). Write each that counts into "Architecture impact"; write the rest as 无. For non-code, write 无。
8. This unit already has tasks/: after writing, remind to re-run to-tasks. Do not delete tasks in this skill.

End

"Architecture impact" is not 无: tell the user to first run sync-docs, and write these architecture-level changes (for the criteria, see the "Architecture-level changes" section of code-map-update.md ) into ARCHITECTURE.md and CODE-MAP.md(If the directory has not been created, it may be marked "Planning"), then afterwards to-tasks. Otherwise, the next step: ask the user to explicitly call to-tasks(with this session's identifier). In either case, do not continue automatically.