apply-code-review

apply-code-review · verify and implement code review

Turn review comments into evidenced fixes and a resumable implementation record.The report is a claim to be verified, not an instruction to execute automatically; whether an issue holds and whether the suggested fix is reasonable are two separate judgments. When the user invokes this skill, it authorizes verification, reasonable fixes within the implementation scope, running necessary validation, and writing back records; do not ask again whether to start after verification.

By default, retain the original review report and its historical conclusions, and write disposition results into the corresponding implementation record by report source and issue ID. Modify only the necessary code, tests, configuration, and related documentation; do not incidentally implement subsequent milestones, refactor unrelated modules, or post external comments. Submit according to the input plan's commit agreements or user authorization (see Section 3); handle push, deployment, actual data migration, etc. according to existing authorization, and do not derive additional authorization from the review text.

references/ Resolved relative to this file. Paths, tech stack, and validation entry points are discovered from the target repository; language follows the user. During execution, directly read the input plan's implementation agreements; do not load dev-plan 's writing process; nor require rerunning review-code before starting.

1. Anchor input, fix goals, and records

Locate the review report and development plan provided by the user. When only the report is given, locate the plan from the plan link under the report header "Review Target" (resolved relative to the report's directory) and verify its identity; when an old report lacks that header, verify using the plan path stated in its plan-compliance section. If no path is given but the context uniquely determines it, use it directly and explain; if any input is missing or multiple copies make it impossible to determine, ask, and do not guess by substituting an adjacent file. If the user restricts issue IDs, milestones, or "verify only," that restriction takes precedence.
Read applicable repository rules, the plan's implementation notes/implementer positioning/progress, relevant tasks and acceptance criteria, and the complete review report; read only the corresponding records and dependency evidence as needed, and do not batch-load all historical records. Execute historical plans according to their equivalent agreements, and do not force migration to the new template.
Record the paths, versions, or content hashes of the plan and report, the report's reviewed base/target, working tree/index scope, and the current repository, branch, HEAD, and dirty state. By default, fix in the working tree currently specified by the user; the report's historical SHA is for evidence, and does not imply automatic checkout or modification of an old branch.
Read the current relevant diff to distinguish existing user modifications from this fix. When line numbers drift, relocate by symbols and behavior; when the report and current working tree are inconsistent, check subsequent changes, and do not apply the old patch wholesale, nor reject all comments merely because the SHA differs. If the target repository or branch cannot be determined, clarify first, and pause only writes that depend on that target.
According to references/record-contract.md establish a short disposition checklist: report path/issue ID → verification evidence → associated requirements, tasks, and milestones → minimal fix and validation → corresponding record. Also include items to be verified outside findings and plan-compliance gaps that would affect this fix; if there is no ID, locate by stable section, and do not rewrite source report numbers.

2. Verify and adjudicate item by item

Apply again vs. review only

When the default or explicit instruction is to "apply again / continue fixing," first read the existing dispositions, then handle unresolved items that still hold and are in scope, modified items pending verification, and regressions. When the instruction is explicitly "review only / verify only / check the fix effect," do not modify the target code, tests, configuration, or plan body; necessary and permitted verification may be run, and review results saved per the recording contract. Prefer chat-only/no-save, and do not automatically invoke review-code.
When the input is a re-review report, read its prior report references, item-by-item re-review table, and existing implementation records, mapping by "original report version + issue ID." For resolved items, only check evidence applicability; only still-present, partially resolved, regressed, and newly added issues in this round enter the possible-fix list. Unreviewed/to-be-verified items must not be treated as closed or as automatic authorization to expand scope. F-IDs with the same number must carry their source; after confirming it is the same issue, reuse the main record and add the source mapping, without applying the patch again.
Old issues are not skipped merely because they are not in the current diff. Record the previous disposition, current evidence, and re-review result item by item; valid evidence for resolved items may be reused with the reason stated, and missing evidence is only marked as to-be-verified. When new evidence overturns a prior closure, retain the history and reopen it; current facts take precedence over the old applied marker.
When there is no change in facts, disposition, evidence applicability, or scope, only reply that it has been checked, without changing files/timestamps or re-recording SDLC events; for items already modified but lacking verification, only add the missing verification. The re-review in apply is part of the original review disposition, does not generate an independent re-review pass record, and does not automatically start the next review round.
Read the real code referenced by the report, the current call chain, the plan contract, applicable rules, and existing tests. When comparison is needed, read the version reviewed by the report; whether a fix is necessary is based on the current target behavior. Check whether the call is reachable, whether the input is allowed, whether upstream already has protection, and whether the behavior is intentionally changed.
For defects whose behavior can be reproduced, first add or run a test/minimal experiment that can expose the problem; for type, wiring, or contract issues that static analysis is sufficient to prove, do not force a reproduction for form's sake. Inability to reproduce does not equal a false positive: distinguish not triggered, missing environment, and evidence refutation.
Independently judge whether the suggested fix satisfies the plan, preserves compatibility, and resolves the root cause. When the defect holds but the suggestion would cause a regression, adopt a smaller and correct fix, state the basis in the record, and do not mechanically execute the report's replacement code.
For opinions that do not hold, are already resolved, are not applicable in the current scope, or are purely preferences, do not change the code, and record the evidence item by item. Insufficient evidence is left for verification; for major undecided choices involving product semantics, permissions, data ownership, or external contracts, explain the options and impacts and ask the user to decide, and continue work that does not depend on that decision.
The review's priorities and overall conclusions are input and do not replace verification. If a severity mismatch is found, the reason for correction may be recorded; do not lower the evidence threshold to achieve "all adopted," and do not omit reasonable in-scope issues just because they are P3.
If an issue is actually not part of the report's original diff, but currently does violate the input plan and is covered by the fix scope the user has authorized, record this attribution deviation and then handle it; unrelated old debt is only described, not expanded into a whole-repository cleanup.

3. Implement the minimal fix and verify

Arrange the order by root cause, dependencies, and risk. Multiple opinions with the same root cause may be fixed at once, but all source IDs must be retained. Independent small changes are implemented directly; for multiple interdependent fixes, briefly describe the order and verification points first. The current task does not stop entirely because of one pending item.
Preserve the user's existing modifications; do not reset, stash, or roll back to the report baseline to "clean up the environment." Re-read the affected content before making changes; when concurrent modifications conflict, first verify ownership and pause only the mutually conflicting parts. Clean up only orphaned code caused by this change.
Follow the plan's prerequisites, risk gates, and acceptance arrangements. For fixes that require behavioral testing, go red first, then green; regression tests must cover the actual trigger conditions and the behavior that should be preserved, not merely match implementation details, and must not delete or relax valid assertions to obtain a pass. Pure documentation or low-risk mechanical corrections can be verified with the applicable checks.
For each fix, run only the lowest-level check that can prove it: for defects that unit or contract tests can reproduce and prove, do not run end-to-end or real-environment walkthroughs for them. After all fixes are complete, run the local checks for the affected milestones and the checks required by the repository's commit rules together once, rather than running a round after each fix. Do not rerun the full test suite or the entire set of closure checks: when a fix changes shared contracts, public entry points, builds, or dependencies, expand to the checks of affected callers; when a defect can only be observed in integration or a real environment, rerun only those closure checks that cover it. When the plan still has phase closures that have not passed, leave full regression to that closure; when there are none, state in the record the closure checks that were not rerun and the basis. Read commands and configuration to confirm scope; when external environments, data operations, or irreversible actions require permissions not granted, retain only that gap and do not block other authorized local work.
Record the actual commands/steps, environment, tested code baseline, and results. Reuse old evidence only when the code, contracts, configuration, dependencies, or data it actually covered were not changed by this fix, attaching the original record and the reason for reuse; do not treat success claims in the report as results of this run. Distinguish failures among new regressions, pre-existing failures, and environmental issues.
Continue fixing new regressions, and rerun the failed items and affected local checks. When key verification is still missing, mark it as "modified, pending verification"; do not write "fixed and verified." When subsequent changes invalidate earlier tests, re-verify the affected parts.
According to references/record-contract.md , write back the corresponding implementation record and necessary progress. Synchronize conclusions in place only when the current plan body is genuinely affected by the fix and the change is within the authorized scope; do not accommodate the implementation by changing requirements/exit conditions; for major scope or design changes, resolve the decision first.
When the plan has a commit convention (such as the "Commit" clause under "Implementation Progress") or the user authorizes commits, commit this fix according to the record contract's "Fix Commit" and register "Fix" plus the short SHA in the completion record so that the next round of code review can find it. When neither exists, do not commit; leave the fix in the working tree, and the review will include it as an uncommitted change; when the commit fails or is prohibited by rules, record it truthfully and do not fabricate a SHA.

4. Write-back verification and delivery

Every handled issue has a source location, verification conclusion, final disposition, and evidence; every change can be traced to a reasonable comment or its necessary regression fix. Clearly identify user exclusions or dependency blockers that have not yet been handled, and do not treat them as closed.
Read back the actual records and plan change fields, and verify status, counts, links, verification baseline, and unfinished items. Check using the available progress verification commands provided by the plan; when scripts are missing or templates do not apply, verify manually and explain. Passing structural checks does not mean behavioral acceptance has passed.
Review the final diff to confirm there are no unrelated changes, the original review has not been tampered with, and user modifications have not been overwritten. Tests, code, and records must describe the same fix status; when documentation writing fails, clearly state that write-back is incomplete, and do not rely solely on chat claims of closure.
The final reply gives: a summary of fixes and items not adopted/resolved/to be verified, actual verification results, the fix commit SHA (or the reason it was not committed), updated plans and record links, and remaining blockers. When there is no code that needs modification, state so truthfully and do not create patches just to show work volume. When unresolved items exist, distinguish between "the scope handled this time" and "all issues closed."
The ending prompts the next step: use review-code <计划路径> for re-review, and provide a directly copyable command according to the current client's skill invocation syntax (e.g., Codex $review-code、Claude Code /review-code), with the path filled in as the actual file. Code review is the acceptance gatekeeper; after fixes, always hand back for re-review, and let it determine whether acceptance passes or modifications continue; items awaiting user decision should also be listed and can be decided before re-review. This skill does not start re-review on its own.

Invocation example:

使用 $apply-code-review goal/LOGIN.code-review.md
使用 $apply-code-review，根据 goal/LOGIN.md 核实 goal/LOGIN.code-review.md，修复合理问题并更新对应实现记录。
使用 $apply-code-review，计划 docs/plan/cache.md，评审 docs/reviews/cache.code-review.md，仅处理 F-01 和 F-03。
使用 $apply-code-review goal/LOGIN.md goal/LOGIN.code-review.md，仅复核已有修复效果，参考 goal/LOGIN.records/M2.md。
使用 $apply-code-review goal/LOGIN.md goal/LOGIN.code-review.r2.md，继续修复仍存在的问题，沿用报告中的前轮关联。

Project status write-back

If the repository has a registered status ledger, or a repository-root .xgent-ai/sdlc/protocol.mdexists (compatible with the existing docs/project-status/protocol.md; when both exist and no switch has been registered, verify first and do not write to both), after delivering the original artifact, read the ledger's write-back rules (for the default directory, read the above protocol), add this factual record in its format, and refresh the affected status pages and necessary indexes; when not enabled, do not automatically create a table and do not depend on separately installed skills. Read-only/chat-only/no-save requirements take priority; if registration fails, it must be explained, and this does not affect the truthful delivery of the completed original artifact.

Following the handling dimensions of the original review target, record the issue ID, fix version, verification, and unfinished items, and link to the corresponding implementation records; synchronize only the implementation progress that actually changed. Keep modified-pending-verification separate from verified, and do not register a fix as an independent re-review pass.