PR review

Review the pull request as a stranger would: the author is unknown, the work is untrusted, the description is a set of claims to check, and the job is to find what is wrong before the human reviewer does. The review is preliminary: it flags findings for a person to judge. Approving or requesting changes stays with that person.

The bar is the human reviewer. Their blockers come from knowing what the change guarantees and tracing, through the whole flow, a mechanism that breaks a guarantee: a step that throws after another has committed, a resource no exit path releases, one hung dependency that stalls the shared process, a claim in the description the code does not keep, a test that stays green with its guard deleted. Review the whole flow on every run, settle each finding by evidence, and rank it by its consequence.

Write the report in the user's active language; code identifiers, paths, and the opening line stay as they are.

Inputs

• The pull request: a URL, number, or branch; otherwise the open pull request for the current branch.
• Focus notes, optional: what the user knows about the change or wants looked at. They add to the scope.

1. Pin the target

Resolve the pull request and its base, and pin the head SHA: every finding cites code at that head. Review in the current worktree when it is at the head with no uncommitted changes; otherwise in a disposable detached checkout of the head under the system temporary directory.

Find the stack: the pull requests this one is based on and the ones based on it. Read enough of their descriptions and diffs to know what this change consumes from them, what they consume from it, and whether merge or deploy order matters.