PR Review

PR review to convergence

Loop: review → triage → fix → verify → commit, until a review finds nothing new or the round cap is hit. Everything stays local until the end: no pushes and no PR comments during the loop.

Arguments: optional PR number (defaults to the current branch's PR), and --rounds N (default 5, counting every review including the final full pass).

0. Setup

1. Refuse to run on main. The working tree must be clean. If it isn't, stop and ask; do not git stash (the user keeps real work in the stash).
2. Resolve the PR: gh pr view [PR#] --json number,title,baseRefName,headRefName. Run git fetch origin <baseRefName>.
3. FULL_BASE=$(git merge-base origin/<baseRefName> HEAD).
4. Ledger: .claude/pr-review/<branch-with-slashes-as-dashes>.md (gitignored). If it exists, resume: read it, continue the round numbering, and keep every recorded outcome. Otherwise create it from the template at the bottom.
5. Upstream sources (UPSTREAM_SOURCES): if the branch mirrors, parses or calls code that lives outside this repo, have that code available at the version the branch targets. That covers a package's runtime (next itself, @next/routing), a restated upstream function (extractEtag), and upstream code no package ships, such as the next.js test harness whose @force-gate pragmas screen.mjs evaluates. Packages are in node_modules/<pkg>. Anything else needs a shallow clone at the matching tag, for example git clone --depth 1 --branch v<version> https://github.com/vercel/next.js /tmp/nextjs-<version>. Reuse a clone that already exists. Record the paths in the ledger header.
6. Collect recorded decisions: read the project memory index (MEMORY.md) and every memory describing a deliberate design choice (e.g. "X chosen over Y", "X is kept", "Y rejected"). Add a one-line summary of each to the ledger's Recorded decisions section. The triage step checks findings against these.

1. Review (fresh subagent every round)

Pick the range:

• Round 1, and the final pass: FULL, i.e. FULL_BASE..HEAD.
• Rounds in between: DELTA, i.e. <HEAD sha when the previous review started>..HEAD, which covers just the fix commits.

Spawn one new general-purpose subagent each round. Never reuse an earlier reviewer, because it would anchor on its own earlier findings. Give it this prompt, filled in:

Review the changes in <RANGE> on branch <branch> (PR #<n>: <title>) for correctness bugs. Invoke the code-review skill with args high. Do not pass --comment or --fix. That skill may pick its own diff range (it tends to use @{upstream}...HEAD, or the remote PR, which lacks local commits). Compare the files it reviewed with git diff --name-only <RANGE>. If they differ, or the skill doesn't say, also review git diff <RANGE> yourself at the same rigor: read the surrounding code, not just the hunks. Do that review while the skill runs, then wait for the skill's results before you report. You can't send anything after you hand back, so results that arrive later are lost. Upstream sources, at the version this branch targets: <UPSTREAM_SOURCES>. A finding about how code outside this repo behaves must cite that code. Don't infer the behaviour ("presumably", "as in JS"). Filter the skill's findings; don't discard them wholesale:

• In range: on lines <RANGE> changes. Verify each against the code and report it with your own findings.
• Outside range: elsewhere in code this branch changes (git diff <FULL_BASE>..HEAD). Verify each one too, and report it in a separate "outside range" list.
• Noise: in uncommitted or unrelated files. Drop these. For a DELTA range: also check that each fix actually resolves the ledger finding it cites, and doesn't break callers outside the diff. Already decided. Don't re-raise these unless the code shows the fix is wrong or incomplete; if so, cite the ledger ID: <paste ledger rows (ID, location, finding, status) + Recorded decisions> Return a list. For each finding give: file:line, a one-sentence defect, a concrete failure scenario, severity (high/medium/low), and the ledger ID it relates to (if any). Make no edits. If you find nothing, say so explicitly.

Record in the ledger: the round number, range type, range SHAs, and the raw count of findings. Outside-range findings are triaged in the same round as the rest and count toward its totals. If a reviewer reports without the skill's results anyway, note it in the ledger and make the next review a FULL pass.