Review new commits against the previous head, preserve finding identity, detect stale evidence, and update GitHub feedback without repeating the entire first review after every push.
A pull request is a moving target. Authors push fixes, rebase, rename files, and add tests after feedback. If an AI reviewer treats every synchronize event as a brand-new pull request, it repeats unchanged comments and charges again for already-reviewed code. If it reviews only the newest commit without considering affected contracts, it can miss regressions. Incremental review needs an explicit relationship between two repository states.
Store every completed run against an immutable head SHA. When a new head arrives, identify the latest completed ancestor reviewed under a compatible configuration. The incremental input is the change from that head to the new one, plus prior findings and selected context that the delta can affect. If no trustworthy ancestor exists—for example after a complicated force-push—fall back to a fresh review and label it clearly.
Line numbers are not stable enough. A finding identity can combine repository, logical file identity, reviewer or rule, normalized title, and a fingerprint of surrounding code. Keep the original commit and line for traceability. Use similarity cautiously when code moves; merging two different findings is worse than asking a human to resolve one duplicate. The objective is to recognize an unchanged claim, not to prove two sentences mean the same thing.
A two-line fix can alter a public contract used across the pull request. Retrieve definitions, callers, tests, and configuration connected to the delta when the reviewer raises a concrete question. Re-run specialist roles whose previous evidence or domain changed. There is little value in repeating architecture review for a newly added unit test, while a change to an authorization helper should refresh relevant security reasoning even if the helper was not part of the original finding.
GitHub thread behavior should be conservative. Preserve existing discussions when their code still maps. Add a concise update only when the new head changes the status of a finding and the platform cannot represent that status otherwise. Aggregate genuinely new findings into one incremental review. Do not post another top-level summary that looks like a complete first-pass review unless the run was actually fresh.
Several pushes can arrive while a model call is running. Before posting, compare the run head with the current pull-request head. Mark an old run stale and avoid attaching its comments to the newer revision. Use an idempotency key for repository, pull request, head SHA, configuration version, and run mode. Queue or cancel superseded work according to provider behavior, but never let completion order decide which review appears current.
Track how many incremental findings are new, unchanged, resolved, stale, or duplicates, along with the compute avoided compared with a full run when estimable. Read repeated-comment examples because identity logic can fail around renames and refactors. A good incremental reviewer feels continuous: it recognizes prior work, focuses on the new risk, and stays quiet when a commit does not change its conclusions.
Expose a manual fresh-review action for cases where maintainers distrust the ancestry or configuration compatibility decision. It should create a new run with an explicit reason, not rewrite history. Compare fresh and incremental results during development to detect missed impact cones. The incremental path earns trust when teams can inspect its baseline, understand its skips, and deliberately reset it without uninstalling the reviewer.
PR Quorum turns specialist reviewer output into one clean GitHub review, with noise controls and predictable usage caps.