菜单
Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, and, when approved, run a batched sequential review-fix loop using isolated sub-agents before finalization.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Plan coding work as a compact implementation-step bundle with a conservative research decision, high-level overview first, and planning artifacts written only under .project_planning/YYYY-MM-DD_FEATURE_NAME/. This skill plans only — it never writes, edits, or refactors implementation code, and never skips ahead to building. If only the skill name is given, ask for a high-level description first before writing planning files.
Execute an approved coding plan as serial-first implementation steps with tight scope control, planner-defined verification strategy, and mandatory sub-agent/worktree execution.
Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, run approved isolated fix passes, then close the loop with optional planning-doc cleanup and PR/MR creation.
Execute an approved coding plan in staged steps with tight scope control, planner-defined verification strategy, deferred automated verification by default, and mandatory isolated sub-agent dispatch when the runtime supports safe worktree execution.
Close out a completed coding loop by validating final chain readiness, checking for leftover repository state, and optionally preparing and creating a PR or MR when the remote provider is supported.
Plan coding work in stages with a mandatory research-decision checkpoint, a high-level overview first, and planning artifacts written only under .project_planning/YYYY-MM-DD_FEATURE_NAME/. If only the skill name is given, ask for a high-level description first before writing any planning files.
| name | coding-loop-reviewer |
| description | Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, and, when approved, run a batched sequential review-fix loop using isolated sub-agents before finalization. |
Use this skill after execution to compare the implemented tree against the approved plan, the recorded execution, and the actual repository state. Surface concrete findings, and, when needed and approved, run a tightly scoped sequential review-fix loop before handing off to finaliser.
Treat the planning folder and the current feature branch as the authoritative sources of truth for the task during review.
overview.md, plan.yaml, and execution.md.overview.md for the original request, high-level overview, decision log, and verification strategyplan.yaml for the approved implementation contract, step order, and parallelismexecution.md for completed steps, deviations, verification strategy usage, and verification performedresearch.md or research_*.md files for background assumptions and technical findingscl/YYYY-MM-DD_FEATURE_NAME from the planning folder.execution.md shows execution did not reach reviewer handoff readiness, stop and report incomplete executor handoff.Follow this sequence strictly:
Do not skip forward. Do not reorder these phases.
These gates are mandatory:
overview.md, plan.yaml, and execution.md exist.pass or pass_with_notesreview.md has been updated with the final reviewer statereview.md update has been committedThe reviewer itself owns orchestration-only work and must not hand it to review-fix sub-agents:
review.md updatesReviewer-owned work does not include:
Those belong to sub-agents whenever safe isolated sub-agent execution is available.
During review, treat overview.md, plan.yaml, and execution.md as immutable chain-owned inputs.
Do not edit overview.md, plan.yaml, or execution.md during review unless the user explicitly requests replanning or correction of chain artifacts.
Do not use uncommitted planning or execution changes as review input.
The reviewer owns one required review artifact under the planning folder:
review.md: the authoritative review logCreate review.md at the start of review if it does not already exist.
If review.md already exists, treat it as prior reviewer state. Attempt to resume only when its recorded state is consistent with the feature branch, current planning artifacts, and current repository state. If they conflict materially, stop and report the mismatch instead of guessing.
Update review.md throughout review. At minimum, record:
review.md should use these sections:
## Scope Reviewed## Inputs Reviewed## Findings## Fix Plan## Fixes Applied## Verification## Final StatusPreserve prior review passes and resolutions clearly. Do not silently overwrite earlier findings history.
cl/YYYY-MM-DD_FEATURE_NAME from the planning folder.review.md if it does not already exist.review.md before proceeding.Review by comparing these four things together:
overview.md for original intent, constraints, boundaries, and verification strategyplan.yaml for the approved implementation contractexecution.md for what the executor claims was done and how it was verifiedTreat them as follows:
overview.md defines original intent and boundariesplan.yaml defines the approved implementation contractexecution.md defines what executor claims was done and how it was verifiedReviewer findings come from mismatches between these, plus obvious correctness issues.
The reviewer must check:
Focus review on files and subsystems touched by the approved plan, execution record, and reviewer-fix changes, plus directly adjacent regression-risk areas.
Prefer evidence over speculation. Every finding should be supported by concrete evidence from code, diffs, plan mismatches, missing verification, or reproducible behavioural reasoning.
Keep the review focused on the current chain step. Do not reopen planning decisions unless the implementation clearly violates the approved plan in a way that cannot be resolved within reviewer scope.
Classify findings into these levels:
blocking - must be fixed before finaliser handoffnon_blocking - does not block handoff but should be recorded in review.mdinformational - useful note with no required actionMap findings to review status as follows:
fail if any blocking findings existpass_with_notes if no blocking findings exist but non-blocking findings remainpass if only informational findings or no findings remainOnly fixable blocking findings enter the reviewer fix plan by default.
A non-blocking finding may be included in the fix plan only when it is directly adjacent to a blocking fix and can be resolved safely with negligible additional scope.
Non-fixable blocking findings must be reported as blockers and stop the chain.
During each review pass:
overview.md, plan.yaml, execution.md, relevant research artifacts, and the actual repository state.review.md.fail if blocking findings existpass_with_notes if no blocking findings exist but non-blocking findings remainpass if only informational findings or no findings remainIf the review status is pass or pass_with_notes, skip the fix-plan checkpoint and proceed to finaliser handoff preparation.
If a review pass identifies one or more fixable blocking findings:
review.md.Do not edit code before the user approves the fix plan.
One review pass produces at most one consolidated reviewer fix pass unless a real dependency boundary makes a single safe review-fix pass impossible.
The feature branch is owned by the reviewer during the review stage. Review-fix sub-agents must never work directly on the feature branch.
When the runtime supports safe isolated execution, every approved reviewer fix pass must run in its own dedicated git worktree attached to its own temporary review-fix branch created from the current feature branch.
The reviewer is fully responsible for the isolated branch lifecycle:
review.mdReview-fix sub-agents must not:
Do not skip worktree creation, temporary branch creation, or sub-agent commits merely for convenience.
The review-fix loop is sequential. Do not parallelize review-fix work.
When the user approves a reviewer fix plan:
overview.mdexecution.md when relevantA review-fix pass is not complete until:
review.md was updated with the new stateIf safe isolated sub-agent execution is unavailable, the reviewer may perform the approved fix plan directly, but only as a fallback. Direct review-fix execution is not allowed merely because the work appears small, routine, or convenient.
If direct fallback is required:
review.mdReuse the verification strategy recorded in overview.md by default.
Reuse the executor's recorded verification behaviour from execution.md when possible.
Do not rediscover verification commands from scratch unless the overview strategy is missing or clearly wrong, or the executor's recorded verification behaviour is clearly invalid.
After a reviewer fix pass:
review.mdPrefer token-conscious validation. Do not rerun broad expensive checks casually when narrower checks provide sufficient signal.
Block on missing verification only when the gap materially undermines confidence in changed behaviour or violates repo policy. Otherwise record it as a non-blocking note.
After each approved review-fix pass:
overview.md, plan.yaml, execution.md, review.md, and the actual repository statereview.md with the new findings and statusIf new blocking findings exist and they arise directly from the approved reviewer fix pass or from still-unresolved prior review findings, another fix-plan checkpoint may begin.
If new issues would require broader replanning, scope expansion, or unrelated cleanup, stop and report the blocker instead of quietly widening scope.
plan.yaml or reinterpret approved scope expansively during review.pass or pass_with_notes and the final review.md update is committed, transition immediately into handoff mode.review.md, and then hand off again.During review, output should be structured as follows:
Always confirm that review.md was updated with the current review state.
If review passes, confirm that the passing review.md update was committed before handoff.
The next step of the chain is finaliser.
When review is complete:
pass or pass_with_notesreview.md is up to datereview.md update has been committedUse the verbatim runtime-specific handoff sentence exactly as written below, with only the planning folder path substituted.
Please run /clear then /coding-loop-finaliser .project_planning/FEATURE on an empty context.Please run /clear then $coding-loop-finaliser .project_planning/FEATURE on an empty context.