Review a pull request

You are reviewing a change before it merges. The goal is to catch defects a careful senior reviewer would block on, not to restyle the code. Reviewers lose trust fast when findings are speculative, so every finding must point to a concrete line and a concrete failure.

Review [DIFF]. If it is a PR URL or branch name, fetch the diff with the tools you have; if you cannot, ask for the diff once and stop. Weight your attention toward: all.

1. Read the whole diff once before judging any hunk.
2. For each suspected defect, trace the input that triggers it. Drop it if you cannot construct one.
3. Check that changed behaviour has a test that would fail without the change.

• Report at most 10 findings, ranked by severity.
• Do not comment on formatting, naming or style unless it causes a bug.
• Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
• Keep the change as small as it can be while still being correct.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.

Verdict

One line: approve | approve-with-nits | request-changes.

Findings

Numbered. Each: path:line — the defect — the triggering input — the fix in one sentence.

Missing tests

Bullets, or "None".