Review changes without the authoring history

Learning objective

Review generated changes in a separate session without the generator’s reasoning context.

Core idea

A review should test the implementation against requirements and source evidence, rather than inherit the reasoning that produced it. Asking the generating session to review its own change leaves its plan, assumptions, and explanations in the same conversation. A separate reviewer can examine the artifact without that authoring history.

Anthropic’s best-practices guidance documents a Writer/Reviewer pattern: Session A implements the change, Session B reviews it, and Session A receives B’s feedback for repair. The multiple-sessions guidance states that a fresh context improves review by avoiding bias toward code Claude just wrote. In CI, implement that separate-session pattern with an independent claude -p invocation and a deliberately selected input package.

This is context isolation, not a guarantee that every finding is correct. The reviewer still needs enough project evidence to evaluate the change, and its allegations still need verification.

How it works

Define what crosses the review boundary

Pass the generated diff, the requirements or plan it should satisfy, relevant source and tests, and review criteria. A reviewer cannot establish correctness from changed lines alone if the failure depends on a caller, fixture, or configuration elsewhere in the repository.

Exclude the generator’s conversational transcript and self-justifying explanation. That history can frame the review around why the generator thought its choices were appropriate. The reviewer should instead establish whether the code meets the stated behavior and where source evidence contradicts it.

Distinguish a requirement from an implementation rationale. “Reject an expired customer token before reading an order” is a testable criterion the reviewer needs. “I reused this helper because it seemed to check expiration” is a hypothesis the reviewer should verify from the helper itself. Passing the criterion preserves the task; passing the rationale can preserve the unchecked assumption.

The evidence crosses to the reviewer; the authoring history does not.

Anthropic recommends naming the work to inspect, the plan to check, and what counts as a finding. Ask for correctness and requirement gaps, with concrete evidence, rather than an obligation to criticize every change. The guidance warns that reviewers prompted to find gaps can produce findings even when work is sound, encouraging unnecessary abstraction and defensive code.

Start an independent invocation

A plain claude -p command starts the review assignment without explicitly continuing the generator’s conversation. Keep the review prompt distinct from the authoring prompt and give it access to the produced artifacts. Apply the read-only permissions in 3.6.1 and the result contract in 3.6.2 when the pipeline consumes structured findings.

Avoid --continue, which continues the most recent conversation, and --resume, which selects a specific saved conversation. Interactive --continue skips print-mode sessions, but claude -p --continue includes them and can restore a print-mode generator’s history. Both flags are useful for a follow-up within one assignment, but resuming the generator recreates the history you intended to exclude.

--fork-session with continuation or resumption creates a separate session ID while retaining the source conversation. The CLI describes it as forking instead of reusing the original ID. A different identifier alone is not proof that the reviewer lacks authoring history. See 1.3.7 for the distinction between history-based forks and fresh specialist contexts.

Use --no-session-persistence when a print-mode job should not save a resumable session on disk. This controls persistence; it does not remove context already supplied in the invocation. A review that receives the generator’s explanation through its prompt remains influenced by that input even if nothing is saved afterward.

Separate history from persistent context

Claude Code’s memory documentation states that sessions begin with a fresh context window, while project instructions and auto memory can carry knowledge across sessions. Ordinary print mode loads configured context. Therefore “separate process” should not be interpreted as “no persistent inputs.”

Project review standards are appropriate shared context. They define the behavior the reviewer should evaluate. Auto memory on a reused runner is a different input: it can contain learnings from prior work. If the pipeline requires review context independent of such notes, disable auto memory with CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 or the autoMemoryEnabled: false setting.

Bare mode also skips automatic memory and instructions, but then you must supply the required review standards explicitly; see 3.6.3. Do not discard useful project criteria merely to make the reviewer ignorant of everything. The intended boundary excludes authoring rationale while retaining the specification and evidence necessary to judge the artifact.

The control choices affect different kinds of context:

Use a fresh subagent when that architecture fits

Anthropic also documents a reviewer running in a fresh subagent context. The bundled /code-review skill performs a correctness review of the diff in a fresh subagent and returns findings to the implementing session. That can support an implementation-and-repair loop without requiring a person to copy results between windows.

The important property is the reviewer’s actual context, not whether orchestration lives in one pipeline job or two. This unit’s CI pattern uses a separate session because it makes the artifact handoff explicit. A fresh subagent can provide the same kind of separation when its assignment contains the diff and criteria rather than the full authoring reasoning.

Do not turn this into a rule that only another model or another machine can review. The documented pattern changes context. A different model with the author’s transcript still receives the same assumptions; the same model with a fresh review assignment can evaluate the result independently.

Key distinctions and trade-offs

Isolation removes authoring history, but it also removes explanations that might contain useful facts. Convert genuinely required facts into requirements or source evidence before passing them to the reviewer. Do not hand over a reasoning transcript as a substitute for a clear specification.

Self-checks remain useful during generation: tests, type checks, and comparing work with requirements can catch errors quickly. They do not replace independent review. Conversely, an independent reviewer should not claim to have run a test that its permissions prevented it from executing. Its output should distinguish inspected evidence from unavailable verification.

Architecture / decision scenario

A Claude Code implementation job changes token handling and explains that an existing helper validates expiration. Its own follow-up review reports no problem. The pipeline adds an independent review invocation with the generated diff, the requirement to reject expired tokens, and access to the helper and existing tests.

The reviewer receives neither the explanation nor a resumed generator session. On a reused runner, the job disables auto memory while retaining project review criteria. It inspects the helper and finds that it validates signature but not expiration. The finding cites the concrete missing requirement and source location. The implementation job receives that finding for repair; the reviewer did not need the generator’s original rationale to establish the defect.

Common exam traps

• Treating “review critically” in the generating session as isolation.
• Resuming the generator because it already knows the code.
• Assuming a fork’s distinct session ID implies empty history.
• Treating no session persistence as removal of supplied context.
• Removing project requirements together with authoring reasoning.
• Assuming an independent reviewer must produce at least one finding.

What to remember

Give the reviewer the artifact, requirements, and criteria, then start a separate context without the generator’s conversation. Avoid accidental resumption and account for persistent memory on reused runners. Fresh review improves independence; it does not guarantee correctness or replace verification of findings.

Knowledge check

References

• Anthropic, Best practices for Claude Code
• Anthropic, Run Claude Code programmatically
• Anthropic, CLI reference
• Anthropic, How Claude remembers your project