review

review

The two paths are not mixed. The review must be done in a sub-agent: the main conversation only dispatches and only hears conclusions, does not read the diff, does not write reviews/. Do not automatically enter just because review-related words are mentioned.

The executing party does not commit. After passing, the dispatching party git-commit auto; if not passing, no changes, or with defer-commit: do not commit. Do not dispatch sync-docs。

1. Execution identity

• Executing party: the first line of the task specification is 执行评审:. Continue from section 2, dispatching sub-agents is prohibited.
• Dispatching party: all other cases. Performing any review axis in this conversation is prohibited.

The dispatching party only does:

1. Do the section 2 pre-checks.
2. Determine the path solely from the parameters (section 3), identifier,Pn、defer-commit, git base point. Stage path determination Pn: if the caller specified it, use it; if not specified, run node .agents/scripts/cooking.mjs status <feature>, take the stage of the "pending review" row, if multiple ask the user, if none stop; do not read each P*.md. If only P<n> was given without an identifier: look at node .agents/scripts/cooking.mjs status(without identifier) overview to see which units list that stage, if 0 stop, if 1 use it, if multiple ask; do not ls, do not read directory contents.
3. According to subagent-prompt.md fill in the task specification and start. Do not write this conversation's process into the task specification.
4. No sub-agent tool: stop, do not degrade to reviewing in this conversation.
5. After the sub-agent returns, only relay: conclusion, blocking items.
6. Not passing or no changes: end (when orchestrated by rush, rush automatically enters the rework closed loop).
7. Passing:
   • With defer-commit: do not commit.
   • Otherwise git-commit auto (source:skills/tools/git-commit/SKILL.md): only commit files that should be stored (code,CODE-MAP.md, skills changed this round / AGENTS.md in the package / ACCEPTANCE.md). If that skill does not exist, stop, do not write another commit process.

2. Pre-checks

Execute according to the "Pre-checks" section of common.md .

3. Choose path

For identifier and matching rules see common.md。

• Stage review: matches the identifier; or after removing the identifier it is a standalone P<n>。
• git review: all others (including empty parameters). Even if cooking has a reviewable stage, do not automatically go review.git rev-parse treat the parseable parameters as the comparison base point.

Parameters contain defer-commit: do not commit after passing. The executing party follows the path specified by the task specification.

4. Existing documents

Both paths do this. Read only, do not modify documents, do not run on behalf of sync-docs. Compare against this diff (see details in persistent-docs.md）：

• Existing skills / AGENTS.md in the package / ACCEPTANCE.md are contradicted by the diff and not changed → block. If the corresponding document does not exist, do not block.
• Code category: the diff touches code-map-update.md entries in the "to change" section but CODE-MAP.md the corresponding line is not changed → block. Non-code does not require CODE-MAP.
• Extra for the stage path: for cooking spec.md run node .agents/scripts/spec-files.mjs parse; if it fails, or some file actually changed in this stage (added / deleted / modified) is not matched by any entry of the same category (glob:* does not cross directories,** cross-directory) → blocking. Base it on the current spec after parsing: entries appended by implement per item 4 of implement "Implementation" are considered covered, not counted as gaps.

5. Review axes

Compare against the diff. If there is any blocking item, conclude "fail"; suggestions are not blocking. If .agents/docs/ACCEPTANCE.md exists, evaluate both paths by it: check whether its must-run items have been run and exited with code 0; for those not run or failed, rerun once this round, and a non-zero exit code → blocking; items marked as skipped are not evaluated. For rework reviews, rerun only the must-run items covering the files changed in the rework, and for the rest just check the exit codes reported in the previous round. If it does not exist, evaluate only according to the table below.

Axis	Stage	git
Spec	spec.md + that Pn.md completion criteria; whether there is anything out of scope; whether "affected files" covers the actual changes in this stage	None
Standards	See below	See below
Correctness	whether the changes are self-consistent, whether there are obvious bugs, whether they satisfy the behavioral semantics of that Pn.md completion criteria; check the test commands and results reported by implement	whether the changes are self-consistent, whether there are obvious bugs, whether they are consistent with the commit message / the intent of this conversation

Standards

• Standards: for code, compare against DEV-STANDARDS.md; for non-code, compare against PROJECT.md, do not fabricate DEV-STANDARDS.
• Existing documentation: the results of Section 4.
• Project skills (code only): spot-check whether the key items of the skills corresponding to the languages / frameworks / roles touched by the diff are followed. The review basis is limited to langs/ / frameworks/ / roles/ -type skills (process-type skills do not count); read only their SKILL.md main text,references/ is read only when the diff directly touches its jurisdiction; if there is no corresponding skill, it is not blocking.
• Bad-smell baseline (code only): compare against .agents/docs/SMELLS.md；DEV-STANDARDS.md ; if it has provisions, they prevail; heuristic, not blocking; skip what tools have already checked.

6. Stage review

node .agents/scripts/cooking.mjs status <feature> output goal.md：未确认: stop, currently exploring. Do not read goal.md judgments.

1. Read that Pn.md、spec.md relevant sections, the files changed in this stage, and the test results in the task book; do Sections 4 and 5.reviews/Pn.md 's "review record" is not "none" → this round is a rework review; additionally read the existing record and execute according to "rework review narrowing".
2. According to review-template.md write .agents/cooking/<feature>/reviews/Pn.md。
3. write back "review":node .agents/scripts/cooking.mjs set <feature> <Pn> 评审 通过|不通过, do not manually edit Pn.md. If the script errors (e.g., implementation not complete): stop, report the original text.
4. Fail: list blocking items (with B<n> numbers), state clearly that rework is needed for the blocking items (when invoked independently, prompt the user implement <feature> <Pn>; in rush orchestration it is triggered automatically by rush). Do not modify code. Subsequent stages that depend on this stage cannot start.
5. Pass: if there are still stages that can be done, list them; if all stages pass, prompt that you can archive <feature>。

Rework review narrowing (only for rework rounds; the first round is full):

• First check item by item whether the existing B<n> has been fixed, and write the closure results (fixed / not fixed) into the "review record"; newly discovered blocking items continue the numbering.
• Only run the three axes of Sections 4 and 5 for the "changed files" in the task book (the changes made in this rework): rework fixes may introduce new problems, so these files are reviewed in full.
• Parts not touched by the rework are not re-reviewed, and each axis may state "carried over from round N-1: <conclusion>". If existing blocking items are not all fixed, or the rework changes introduce new problems → fail.

The review scope is based on the "changed files" in the task description. When you need to collect it yourself using git as a fallback: the working tree may contain uncommitted changes from other parallel stages; files whose attribution to this stage cannot be confirmed are not included in the review and do not block it on that account—note this in "Suggestions".

7. git review

Do not read cooking spec/tasks, do not write reviews/, do not change Pn status.

Determine the diff (the base point must git rev-parse succeed; do not invent scope):

1. The user provided a parseable base point:git diff <基点>...HEAD; if the working tree or staging area still has changes, layer them on.
2. Otherwise, if the working tree or staging area has changes:git diff and git diff --staged。
3. Otherwise, relative to @{upstream}; if there is no upstream, relative to the merge-base of main(or master):git diff <base>...HEAD。
4. If there is still no diff: stop.

Do sections 4 and 5. Produce the conversation according to the git section of review-template.md .