Skip to content

Feature Delta Re Review

Jump to bottom
amirbena edited this page Sep 17, 2026 · 2 revisions

Feature: Delta & SHA-Aware Re-Review

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

When the same reviewer re-reviews a PR after a push, and that reviewer's immediately preceding completed review's exact SHA can be established reliably, github-pr-review scopes the new pass to previously reviewed SHA → current PR HEAD, plus enough surrounding context to confirm the fix, check for regressions, and re-check the prior review's assumptions. If the previously reviewed SHA already equals current HEAD, it returns NO NEW DELTA instead of manufacturing a duplicate review.

Why it exists

Re-reading an entire large PR after every small fix push is wasteful and error-prone for the reviewer. Scoping a re-review to the actual delta — while still re-checking assumptions the fix might have invalidated — keeps re-review both fast and safe.

When it applies

Conditional and automatic — never requested via a flag. It applies only when the current authenticated reviewer is the same identity as the immediately preceding completed review, and that review's reviewed SHA resolves to a real commit in the PR's history. A different reviewer, no prior review, or any ambiguity falls back to a normal full review — it always fails conservative.

local-code-review has no GitHub review history to key off; its analogues are the staged-delta fingerprint short-circuit and reconciling an associated PR reference's prior findings (see Review-Context-and-Existing-Evidence).

How it works

Just re-run the review as the same reviewer — the Skill reports which mode it used: Review mode: Delta re-review (with the previous and current SHAs) or Review mode: Full review (with the reason). A delta re-review escalates to a full review whenever the delta materially changes the implementation, expands scope, invalidates prior assumptions, or adds substantial new behavior.

Important options / modes

None to set. A different reviewer inherits PR/repository state and prior discussion, but never another reviewer's judgment — prior findings remain investigation evidence, not verified facts. A changed HEAD re-classifies every prior human finding; an old approval never authorizes a new HEAD.

Example

re-review PR #812

Related features

Canonical references

Wiki Page Map

Page What it covers
Home Wiki entry point: what the two Skills are and where to go next.
Getting-Started First steps to package and run either Skill.
Choosing-a-Review-Skill How to decide between local-code-review and github-pr-review.
How-the-Review-Model-Works Concept-level walkthrough of the review pipeline shared by both Skills.
Architecture-Overview Component-level map of how the repository's pieces fit together.
Specialist-Depth-Review When and how a review goes deeper than its base pass.
Local-Code-Review-Guide Usage guide for reviewing local, not-yet-PR'd Git changes.
GitHub-PR-Review-Guide Usage guide for reviewing an existing GitHub Pull Request.
Review-Context-and-Existing-Evidence How optional requirements/context and prior review evidence are supplied.
Feature-Pages Index of per-feature capability pages and their shared template.
Feature-Delta-Re-Review How a re-review scopes itself to only what changed since the last pass.
Feature-GitHub-Publication-and-Authorization What a PR review publishes to GitHub and under what authority.
Feature-Human-Style-Review-Output The senior-engineer-voice prose summary output option.
Feature-Requirement-Coverage How supplied requirements are checked and reported as covered or not.
Feature-Runtime-Validation-Evidence How a review can execute commands or reproductions as evidence.
Severity-and-Decision-Model The P0/P1/P2 severity levels and how the merge decision is derived.
Packaging-and-Portability How the Skills go from source repository to a standalone archive.
Development-Workflow Contributor guide for working on this repository itself.
Benchmark-Testing Orientation to this repository's own review-quality benchmark pipeline.
Repository-Documentation-Map Where each concern's canonical, authoritative source lives.
AI-Code-Review-Landscape Neutral snapshot comparing this project against other AI code-review products.
FAQ Short, practical answers to common questions.

Clone this wiki locally