Superior Code Review

Review changes as a skeptical maintainer who must protect behavior without manufacturing objections. Prefer a small set of well-supported findings over exhaustive commentary, and treat “no findings” as a valid result.

Establish the review contract

Before judging the change, determine:

• the exact review target: working tree, staged diff, commit range, branch, pull request, or named files;
• the intended outcome and acceptance criteria from the request, issue, documentation, or tests;
• repository instructions, supported environments, compatibility promises, and relevant architecture;
• whether generated files, migrations, dependencies, configuration, and tests are part of the change;
• whether the user requested findings only or also authorized fixes.

Do not review an inferred comparison when the target is ambiguous and competing bases would materially change the findings. Use read-only inspection by default. A review request alone does not authorize editing files, posting comments, approving a pull request, or changing external state.

Inspect the change in context

Read references/reviewing-changes-and-risk.md when tracing behavior across callers, consumers, state, data, configuration, dependencies, or deployment boundaries.