When a developer pushes fixes for review comments and the pipeline re-reviews without prior context, Claude posts the same findings again. It has no memory of what it already flagged. The developer sees 15 comments, 10 of which say the same thing as the first review about issues already fixed.
Three developers mute the review bot. Real issues go unaddressed.
The Fix: Prior Findings as Context
Include the previous review’s findings in the next review’s context. Instruct Claude to report only new or unresolved issues.
| Config | Avg comments per re-review | Duplicates |
|---|---|---|
| No prior context | 8.2 | 62% |
| Prior findings in context | 3.1 | 4% |
Same total unique issues found across all PRs. The incremental approach eliminates noise without sacrificing thoroughness.
The impact on developer engagement:
| Quarter | Comments addressed | Bot muted |
|---|---|---|
| Q1 (no incremental) | 45% | 3 developers |
| Q2 (incremental) | 82% | 0 |
When 62% of comments are duplicates, developers stop reading them. When 96% are actionable, developers act on them.
Implementation Steps
- Store findings — Save each review’s findings in a persistent location (file, database, PR metadata)
- Pass as context — Include stored findings in the next review’s prompt
- Instruct — “Report only new issues or issues from the prior list that remain unresolved”
The first step is storage. Without stored findings, there is nothing to pass as context.
Not Diff-Only Review
A colleague proposes reviewing only the diff between pushes to avoid duplicates. This misses issues where unchanged code interacts with new changes. A fix in one function may resolve or create issues in another function that the diff does not include.
Full review with prior findings maintains complete coverage. The prior context prevents duplicates; the full scope prevents missed interactions.
Managing Context Growth Across Many Iterations
A PR with 5-6 review iterations accumulates a long list of prior findings. By iteration 5, the context is bloated.
The solution: summarize prior findings by category rather than listing each one individually. “3 naming convention issues resolved, 1 error handling issue open” preserves the incremental benefit while keeping context manageable.
Do not discard prior findings after a set number of iterations — that reintroduces duplicates. Do not switch to diff-only review after early iterations — that loses interaction coverage. Compress the context, but keep it.
Combining with Session Isolation (K3.6.4)
A developer argues that session isolation (independent reviewer with no context) and incremental review (prior findings in context) conflict. They do not.
Session isolation means the reviewer has no generation-phase context — it did not write the code it is reviewing. Incremental review means the reviewer has prior review findings — it knows what was previously flagged.
The combined setup: an independent Claude instance receives prior review findings as structured input. It has no bias from having written the code, but it knows what was already flagged. Both practices apply simultaneously.
One-liner: Store review findings between iterations and include them as context — duplicates drop from 62% to 4%, developer engagement rises from 45% to 82%, and nobody mutes the bot.