A reviewer agent is useful when it produces findings you can verify. A green check or confident summary alone does not tell you whether the change meets the request.
1. Establish intent before reading the diff
Read the issue, acceptance criteria, and PR description. Write down the behaviors the change should add or preserve. If the PR has no testable goal, ask for one before judging implementation details. This keeps review from turning into a collection of unrelated style comments.
2. Scan the change surface
List changed files, commits, dependencies, data migrations, configuration, and generated files. Notice any file outside the stated scope. In Canopy, the Agent Workspace joins the session to its checkout, files, diff, branch, and PR so you can trace the change. Check the actual PR on the latest commit.
3. Test the risky paths
Reproduce the intended behavior and inspect error paths. For authentication or permissions, test both allowed and denied cases. For a UI change, run the app and check the relevant viewport and interaction, not just the build. For an API change, test a bad input and a normal one. Record any check you could not run.
4. Use an independent reviewer carefully
Give a reviewer agent the goal, branch or PR, and a request for concrete bugs with evidence. Ask it to distinguish confirmed findings from hypotheses and avoid changing code during the review. Canopy's read-only review task stages draft findings for a person to vet. Open each cited line or reproduction before posting a comment.
5. Recheck after fixes
When an agent addresses comments or CI failures, read the new diff, rerun relevant checks, and confirm that the fix did not weaken a test or move the bug. Resolve threads only when the specific concern is answered. GitHub's review workflow treats comments, requested changes, and approvals as distinct decisions.
6. Make the merge decision explicit
Summarize verified behavior, remaining risk, test evidence, and who approved the final state. A review is complete when the latest commit has been checked, not when an earlier agent message said 'done.' Keep the PR and session history available for a later regression investigation.
Copyable resources
Copyable reviewer prompt
Use in a separate review session. Keep it read-only until findings are vetted.
Review PR [number or branch] against this goal: [observable behavior and acceptance checks].
Inspect the latest diff, changed files, tests, CI status, and relevant call sites.
Find concrete correctness, security, data-loss, compatibility, or missing-test risks.
For each finding, give file and line, a failure scenario, how to reproduce or reason about it, and severity.
Separate verified bugs from hypotheses. Say when evidence is insufficient.
Do not edit code, post comments, approve, or merge during this review.
Finish with: acceptance checks verified, checks not run, and questions for the author.Final human review checklist
Use this on the latest commit, after fixes.
[ ] The PR still matches the original request.
[ ] Every changed file is understood or explained.
[ ] The running behavior was inspected where relevant.
[ ] The main happy path and a meaningful failure path were tested.
[ ] CI passed on the latest commit; no test was weakened to get green.
[ ] Review comments are answered by the current diff.
[ ] Permissions, data changes, dependencies, and configuration were checked if touched.
[ ] Remaining risks and unrun checks are documented.
[ ] A person owns the merge decision.Frequently asked questions
Should an AI reviewer automatically post every finding?
No. Verify each finding against code or a reproduction. Canopy stages read-only review findings as drafts so a person can vet them.
Is passing CI enough to approve an AI-written PR?
No. CI covers the checks it runs. Compare the latest diff and actual behavior with the request, including paths the tests may miss.