implement

implement

Two paths, do not mix them. Do not automatically enter this skill just because the user mentions "implement / develop". Do not modify the spec (the only exception: at the end of the phase path, entries may be appended to the spec's "affected files", see section 4 of "Implementation"), and do not split new phases. Do not modify ARCHITECTURE.md / DEV-STANDARDS.md / PROJECT.md / SMELLS.md, let the user run sync-docs。

Pre-checks

Follow the "Pre-checks" section of common.md . For when to modify CODE-MAP see code-map-update.md. For aligning with existing docs see persistent-docs.md。

Choose a path

For identifiers and match rules see common.md. In the arguments, P<n> refers to the phase id.

• Phase path: an identifier is matched; or the argument (after removing the identifier) is a standalone P<n>。
• Direct-write path: the argument is non-empty, and is neither an identifier nor a standalone P<n>. The whole thing is the implementation content.
• Argument is empty: do not default to either path. Use 交互式提问 to ask the user: which cooking phase to do (list existing identifiers as options), or direct-write (please provide the implementation content). When there are 0 cookings, only ask for the implementation content.

Do not write direct-write content into cooking, and do not treat the phase list as a direct-write task.

Coding rules (common to both paths)

1. For code, read DEV-STANDARDS.md、SMELLS.md; when a module needs to be located, search for CODE-MAP.md related lines by module name/path, do not load the whole file. When the languages / frameworks / roles involved in the change have a corresponding langs/ / frameworks/ / roles/ type skill among the available skills, read its SKILL.md as needed and comply. For non-code, compare against PROJECT.md, do not fabricate DEV-STANDARDS, do not open ARCHITECTURE / DEV-STANDARDS / CODE-MAP / SMELLS.
2. Small diff, only do what is required. Compare against SMELLS.md and clean up on the spot the bad smells introduced this time; do not expand into refactoring unrelated to this change.
3. If the change amounts to an architecture-level change (see the "Architecture-level change" section of code-map-update.md ): stop coding, do not just modify CODE-MAP. Tell the user to first run sync-docs to update ARCHITECTURE.md。
4. For code, if code-map-update.md is touched, the items to change: only change the relevant lines. Do not modify CODE-MAP for non-code. If this round gets skills, packages/modules AGENTS.md、ACCEPTANCE.md or other existing convention documents wrong: fix that one on the spot; if not wrong, leave it alone. Do not modify ARCHITECTURE.md、DEV-STANDARDS.md、PROJECT.md、SMELLS.md。
5. When the repository's existing lint / typecheck / test commands (those specified in the "Code style" and "Testing" sections ofDEV-STANDARDS.md, package.json scripts, Makefile, etc.) cover the changed files: run them once before wrapping up; not passing does not count as done. The must-run items of.agents/docs/ACCEPTANCE.md (except those marked "skip") must likewise be run before wrapping up: the phase path runs only the items appended to that Pn.md"Completion criteria", and the direct-write path runs all of them. Do not install new tools or create new configs for this.
6. Prohibited: git stash、git checkout --、git clean and other operations that clear or roll back the workspace. Bypass non-this-round dirty files already present in the workspace, do not include them in the report or commit path, and list them in the report if necessary.

Phase path

Run node .agents/scripts/cooking.mjs status <feature>, only look at its output, do not read goal.md, do not read the body of each Pn.md to judge the state: goal.md：未确认 → stop, currently exploring, do not write code based on old requirements. tasks/：无 → stop, tell the user to first execute to-tasks. If the user actually wants direct writing, have them provide the implementation content and then follow the direct-write path.

"Prerequisites / Status" is only read and written via node .agents/scripts/cooking.mjs ; do not modify it by hand, and do not compute dependencies yourself. If the script does not exist: stop, and have the user run setup in update mode to recopy the script. If the script reports an error (illegal transition, prerequisites not met, cycle): stop, report it verbatim, and do not work around it.

Select phase

1. The doable phases are based on the "doable" behavior output by status in the previous step (including the phase where it stopped at 进行中 during an interruption; continue from there).
2. The user specified Pn: if it is not in "doable", tell the user the prerequisites it is missing (see the "Prerequisites" column for that phase in the output) and stop. If only P<n> is given without an identifier: check the status overview without identifiers to see which units list that phase; if 0, stop; if 1, use it; if multiple, ask.
3. The user did not specify Pn: if only one is doable, do it; if multiple, use 交互式提问 to let the user choose (only rush runs in parallel). If no phase is doable: stop and explain.

Implement

1. Read the relevant acceptance criteria in that Pn.md、spec.md . Rework ("Review" is "Not passed"): also read reviews/Pn.md 's "Blockers", and fix only the blockers; the reported changed paths include only the changes from this rework, for review's incremental review.
2. node .agents/scripts/cooking.mjs set <feature> <Pn> 实现 进行中。
3. Do the checklist items per the coding rules, and check off completed items.
4. At the end, align with the spec's "Affected Files": when a file actually added / deleted / modified in this phase is not covered by any entry of the same category in the spec, append that path on the spot to the corresponding category in spec.md's "Affected Files", and rerun node .agents/scripts/spec-files.mjs parse .agents/cooking/<feature>/spec.md until it passes; only touch the "Affected Files" section, not other sections of the spec. If the change falls into a new directory and constitutes an architectural-level change, do not backfill it; stop and report per coding rule 3.
5. node .agents/scripts/cooking.mjs set <feature> <Pn> 实现 完成(the script also sets "Review" back to 未开始）。

Direct-write path

Do not read spec/tasks, do not create or modify any cooking files, and do not check off tasks. Not blocked by a unit's goal.md being unconfirmed. Per the coding rules, do only this implementation content from the user.

End

The report must always include: which paths were changed; entries appended to the spec's "Affected Files" (backfilled for phase paths; write none if there are none); which lint / typecheck / test commands were run and their results (write "no runnable commands" if there are none); whether CODE-MAP and other existing docs were updated; whether sync-docs。

• Phase path: when dispatched by rush, only report; review is dispatched by rush. When the user calls it directly: read review/SKILL.md, treat this conversation as the dispatcher, and dispatch a review subagent per the phase review template (with changed paths and prerequisite check categories); after it returns, handle the conclusion per the dispatcher steps; this conversation does not review, does not read reviews/ body, does not modify reviews/Pn.md, and does not touch the "Review" status. Do not commit before dispatching review. Until review passes, do not start subsequent phases that depend on this phase.
• Direct-write path: after reporting, if the changes are ≤ 3 files and no dependencies were added, use 交互式提问 to ask the user whether to do a git review or skip this time; if skipped, do not commit (the user decides whether to commit), and end there. Otherwise, or if the user chooses review: read review/SKILL.md, treat this conversation as the dispatcher, and dispatch a review subagent per the git review template (do not use phase review, do not write reviews/); after it returns, handle the conclusion per the dispatcher steps. Do not commit before dispatching review; this conversation does not review.