Identify real issues that affect user outcomes and verify the evidence. When only a review is requested, deliver findings without directly modifying the code.
Determine the review scope
Read the project rules, original requirements, and acceptance criteria, and confirm whether what is to be reviewed is workspace changes, a specific commit, a branch diff, or a PR. Record the corresponding version and distinguish this change from unrelated pre-existing issues.
Read the diff first, then follow up on related callers, data sources, and the actual code in use. Do not judge whether the entire flow is correct based only on fragments in the changed files.
Check actual behavior
Check from the user entry point: whether the requirement is implemented, whether normal input produces the expected result, and whether errors, boundaries, cancellation, recovery, and resource cleanup are correct. When platforms, protocols, storage, or configuration are involved, check the corresponding differences as well.
Prioritize issues that can lead to incorrect results, data loss, behavioral regressions, or tasks that cannot be completed. Keep style preferences and optional improvements separate from actual bugs, and do not report issues just to pad the count.
When the user requests an independent review, or a high-impact change genuinely requires it and delegation is currently allowed, an independent agent may be used. Give it the original task, the target diff, acceptance criteria, and necessary source materials, and do not pass along the conclusion that "this must be correct." The reviewer reads source code only, and any writes needed for verification go in an isolated location. When there is no independent agent, review directly and state the method truthfully.
Verify each finding
For each issue, clearly state:
- The file and specific location.
- Under what conditions it is triggered, and what consequences the user will encounter.
- The corresponding call or data path.
- Reproduction experiment or complete code path evidence.
- Whether it is an issue introduced by this change or a pre-existing issue.
Run discriminating verification for key findings; when reproduction is inconvenient, provide a checkable code path and clearly state what evidence is missing. Distinguish confirmed, suspicious, and pending confirmation, and merge duplicate findings; agreement among multiple reviewers cannot replace evidence.
Only when fixes have been authorized, modify confirmed issues relevant to the task, then rerun the corresponding failure scenarios and affected paths. After subsequent commits or merges change the code, recheck the relevant changes and do not carry over conclusions from an old version.
Output results
List issues with evidence first, ordered by impact, then briefly describe verification and uncovered scope. When there are no confirmed issues, state the scope that was checked and do not claim to guarantee there are no bugs.
For multiple rounds of review, you can use code review records to save findings, evidence, and recheck results.