Never Let Claude Review Its Own Work: Use a Fresh Context

When Claude finishes something and you ask "is this good?", the answer is almost always yes. The work looks reviewed. In reality the same conversation that produced it is now grading it, with all the same assumptions still loaded. It is the same reason you never catch the typo in your own email.

The fix is simple and I use it every day when I build: the one who checks should never be the one who made it. Here is how to set that up, in the Claude app and in Claude Code.

Why a fresh context works

Anthropic's Claude Code best practices say it directly: "A fresh context improves code review since Claude won't be biased toward code it just wrote." The same page recommends adding an adversarial review step before you count work as done, because a reviewer in a fresh context sees only the result and the criteria, not the reasoning that produced it.

That second part is the whole trick. The original conversation is full of explanations for why each choice was fine. A cold reviewer has none of those excuses available. It only sees what is on the page.

In the Claude app: the blank chat method

1. Finish the work in your normal chat.
2. Open a new chat. If you use memory, start an incognito chat instead, which does not use your existing memory or chat history. Look for the ghost icon when you start a new chat.
3. Paste only the output and your criteria. Leave out the original request and the back and forth. The less the reviewer knows about how you got here, the more honest it is.
4. Ask for a review against those criteria only.

Here is the prompt I use:

You are reviewing work you did not create. You have no stake in it.

<work>
[paste the output]
</work>

<criteria>
[3 to 5 specific, checkable criteria]
</criteria>

Review the work against these criteria only. For each problem:
quote the exact part, say which criterion it breaks and why, and
give a concrete fix. If a criterion is met, say so in one line.

Report only problems that would stop the work from reaching its goal.
Skip style preferences. If the work is solid, say it is solid.

The last paragraph matters more than it looks. The same best practices page warns that a reviewer asked to find gaps will usually report some, even when the work is sound. Chasing every one of those leads to over-engineering. Telling it to flag only real problems, and explicitly allowing "this is fine," keeps the review useful.

Writing criteria that actually catch things

Vague criteria get vague reviews. "Is it clear?" produces an opinion. Checkable criteria produce findings. Compare:

• Vague: "The landing page copy is compelling." Checkable: "A first time visitor can say what the product does after reading only the headline and subline."
• Vague: "The report is accurate." Checkable: "Every number has a source, and the source says what the report claims it says."
• Vague: "The code is good." Checkable: "Every function that calls the payments API handles a timeout and a declined card."

Three to five of these are enough. If you cannot write a checkable criterion for something, that is often a sign you have not decided what you want yet.

In Claude Code: let a subagent do it

In Claude Code you do not need to copy anything between windows. Three options, from least to most setup.

Use the built-in review

/code-review

This bundled skill reviews your current diff for correctness bugs in a fresh subagent and returns the findings to your session. You can pass an effort level such as /code-review high, or add --fix to apply the findings. The code review docs list every option.

Ask for a reviewer against your plan

/code-review looks for bugs. If you want to check the work against a spec, write the prompt yourself:

Use a subagent to review the changes against SPEC.md. Give it only the
diff and the spec. Check that every requirement is implemented, the edge
cases in the spec have tests, and nothing outside the task changed.
Report only gaps that affect correctness or the requirements.

Subagents start with their own clean context and do not see your conversation, which is exactly what you want from a reviewer.

Save a permanent reviewer

If you review the same kind of work often, define the reviewer once. Create .claude/agents/cold-reviewer.md in your project, or in ~/.claude/agents/ to use it everywhere:

---
name: cold-reviewer
description: Reviews finished work against stated criteria with no
  knowledge of how it was made. Use after a task is complete.
tools: Read, Grep, Glob
---
You review work you did not write. You receive the work and the
criteria. Check the work against the criteria only.

For each problem, point to the file and line, name the criterion it
breaks, and suggest a specific fix. Report only issues that affect
correctness or the stated requirements. If everything passes, say so
plainly. Never edit files.

Limiting the tools to reading keeps the reviewer from quietly fixing things itself, so you see every finding. Call it with @agent-cold-reviewer followed by what to check, or just ask Claude to use the cold reviewer. The subagents docs cover the other fields, including setting a different model for the reviewer.

Close the loop

A review is only useful if something happens next. Paste the findings back into the original session, or in Claude Code let the main session read them directly, and ask it to fix only the issues you agree with. Then run the reviewer once more. Two rounds is usually enough. If the third round still finds real problems, the brief was probably unclear, and it is worth rewriting it before going further.

Try it on the next thing Claude makes for you that someone else will see. Write three checkable criteria, open a blank chat and paste only the work. The first time a cold reviewer catches something you both missed, you will not go back.