Reconcile prior findings against changed code

Learning objective

Re-run PR reviews with prior findings to report only new or still-unresolved issues.

Core idea

A repeat review needs evidence of both the code’s present state and what the previous review reported. An instruction to avoid duplicates cannot replace the missing findings. Supply them with the updated diff and tell the reviewer to report only issues that are new or still unresolved.

A prior finding is an allegation to recheck, not a permanent instruction that the code remains defective. A developer can fix the cause, move the relevant code, or change surrounding behavior. The repeat review should test the finding against the supplied revision rather than repeat its wording or trust a claim that it was fixed.

See 3.6.2 for machine-readable findings and 3.6.5 for independent reviewer context. This lesson concerns continuity of review evidence across commits, not continuity of the generator’s reasoning.

How it works

Preserve the previous result as evidence

Claude Code’s JSON output can include a schema-validated answer in structured_output. Use the completed findings from that result as the next review’s input, or supply the previous comments through your pipeline’s existing data path. The CLI does not automatically turn an empty prompt into a history of PR comments.

Keep enough of each finding to recognize the alleged defect: its source path and location, explanation, and the condition that causes incorrect behavior. A list of titles such as “validation bug” is too weak to distinguish a resolved issue from a different defect in the same file.

An application can attach its own finding identifier when it needs to associate repeat-review results with existing comments. Make that identifier part of the schema you own; do not imply that Claude Code assigns stable PR-finding identities. The built-in session_id identifies the conversation, not an individual code-review allegation.

Anthropic’s print-mode interface supplies the mechanisms to provide those inputs; your pipeline owns storing and retrieving the findings.

Supply the updated code with the earlier findings

The reviewer needs the selected revision, its relevant diff, and sufficient source evidence to evaluate prior allegations. If a fix moves code outside the selected diff, allow inspection of the source needed to verify that change rather than assuming absence from the diff means resolution.

Print mode reads standard input, so a pipeline can build a text input containing clearly labeled sections for the updated diff and earlier findings. Alternatively, store them as local files and direct Claude to inspect them with Read. Supply the actual contents or a readable path; a reference to an artifact the runner cannot access supplies no evidence.

A concrete assignment can identify the comparison:

Read updated.diff and prior-findings.json. Recheck each prior finding
against the checked-out code. Report only new correctness defects and
prior defects that remain unresolved. Preserve the supplied identifier
for unresolved findings. Do not report resolved findings as open.
Inspect relevant source files when the diff alone cannot settle a claim.

The filenames and finding identifier are application inputs. They are not reserved Claude Code interfaces. The prompt tells the reviewer how to use them and what the output consumer expects.

Keep the prior findings distinct from generator reasoning. They state externally reviewable claims about the code. Including them helps the reviewer evaluate continuity without supplying the assumptions that originally produced the implementation.

Choose a fresh review or explicit review resumption

A fresh claude -p invocation can receive all relevant evidence each time. This gives the repeat review a self-contained assignment and avoids depending on a saved session’s availability. It still loads configured context in ordinary mode, so preserve the instruction-loading contract from 3.6.3.

Claude Code also supports explicit review continuation. --continue continues the most recent conversation; --resume selects a specific conversation by session ID. If multiple jobs share a runner, “most recent” does not express which review you intended. Capture session_id from the JSON result and use --resume when the architecture deliberately retains that review conversation.

Resume the reviewer only, not the generator. Even in a resumed review, supply the updated diff and identify what changed. Stored conversational context does not establish that the reviewer has inspected the pushed revision. A fresh review with explicit previous findings is often clearer than assuming earlier context remains sufficient.

Neither CLI strategy automatically deduplicates comments. The model returns its assessment; the pipeline’s consumer decides how each unresolved finding relates to an existing comment. The schema and identifiers make that decision reviewable rather than forcing the consumer to infer identity from prose.

Distinguish custom reviews from packaged products

Managed Code Review’s After every push mode reviews each push to the PR branch and auto-resolves threads when flagged issues are fixed; its results are deduplicated. Fork PRs require an explicit @claude review comment even in that mode. REVIEW.md supports re-review convergence criteria. Code Review is in research preview, available for Team and Enterprise subscriptions, and unavailable with Zero Data Retention or the HIPAA configuration.

The GitHub Action’s packaged code-review plugin example triggers on synchronize, but skips PRs that already have a comment from Claude. A second push therefore does not guarantee another review. For repeat reviews in your own CLI or action workflow, use a custom prompt carrying prior findings and updated code as taught here.

Separate review results from publishing decisions

An unresolved finding can legitimately appear in the repeat review without requiring another identical comment. Keep it associated with the existing finding. A new defect can become a proposed additional comment. A resolved prior finding should not remain in the set of open issues merely because its earlier text still exists.

These are application-owned result semantics, not built-in CLI posting operations. Define them in the prompt and the findings schema where the consumer needs them. The Anthropic GitHub Actions documentation states that automation results appear in the workflow log by default. Posting requires instructions and an available posting tool; a supplied prompt does not automatically publish review comments.

Preserve the distinction between successful empty results and unavailable evidence. If a run fails, lacks structured data, or cannot inspect the code required to recheck an allegation, it has not established that every prior issue is fixed. Apply the completed-result gate from 3.6.2 before updating the consumer’s view of open findings.

Key distinctions and trade-offs

The repeat review makes three different decisions:

More prior context helps identify issues, but carrying every conversation turn can also obscure the comparison. Supply concise findings with their evidence and the code needed to check them. Keep general review criteria in project instructions rather than duplicating them inside every historical finding.

An earlier line number can help locate a claim, but changes can move it. Recheck the code before returning a location for the updated revision. Do not preserve a stale location merely to keep the finding’s identifier stable.

Architecture / decision scenario

A first CI review reports an unsafe order query and a missing authorization check. The developer pushes a fix for the query. A second run receives only the updated diff and repeats both original comments because it lacks the previous findings and sufficient source to compare them.

The repaired job supplies prior-findings.json, the updated diff, project review criteria, and readable source paths. Its prompt requests only new or still-unresolved defects. The reviewer verifies the query repair, retains the authorization allegation under its supplied identifier, and reports a distinct introduced validation defect as new. The consumer associates the unresolved item with the existing comment and considers one additional comment. A failed comparison would leave the review incomplete, not resolve both earlier issues by default.

Common exam traps

• Expecting “avoid duplicates” to work without prior findings.
• Treating a previous allegation as permanently true.
• Equating an unresolved finding with permission to post another identical comment.
• Using session_id as a finding identifier.
• Resuming the most recent conversation without identifying the reviewer.
• Treating absent or failed output as proof that earlier defects were fixed.

What to remember

Give each repeat review the prior findings and updated code, and request only new or still-unresolved issues. Fresh context can retain review evidence through explicit inputs; deliberate resumption should select the reviewer by session ID. Recheck each allegation, preserve application finding identity where needed, and keep comment publishing separate from the model’s assessment.

Knowledge check

References

• Anthropic, Run Claude Code programmatically
• Anthropic, Claude Code GitHub Actions
• Anthropic, CLI reference
• Anthropic, Code Review