One Claude that checks the other

What it is and why it matters

When a Claude Code session finishes a job and tells you “done”, the natural move is to ask it to double-check. It doesn't work well. It just wrote that code, it knows why it did it that way, and when it reads it again it sees what it meant to do, not what it actually did.

It's the same blind spot we have when we reread something we wrote. The mistakes that slip through are exactly the ones you didn't imagine while writing: the field left empty, the double click, the user who opens someone else's data.

That's why I have another session do the check, one that starts without the first one's conversation. It sees only the changes and one job: find how to break them. The official Claude Code guide says so too: a session with a clean context reviews code better, because it isn't attached to what it just wrote.

Why it matters: if you build an app without being a developer, you don't have the eye for these holes yet. A reviewer whose job is to attack the code looks for them on your behalf, before your users find them.

1. The reviewer's prompt

This is the prompt I paste into the second session, word for word. As it is, it works before you commit. If you've already committed, add at the end which files to look at.

You are an outside reviewer. You didn't write this code and you don't know why it's built this way: don't ask and don't look for justifications. Look only at the changes just made: run git status and git diff, and read in full the new files that git status lists (the diff doesn't show them). Your only job is to find how to break them. Look for:
- input: empty fields, extremely long text, strange characters, negative numbers, double clicks, duplicate requests;
- permissions: who can see or change data that isn't theirs, what happens without logging in or when logged in as someone else;
- edge cases: empty lists, slow or missing network, two users at the same moment;
- security: keys or passwords in the code, user data used without checks, errors that show too much.
For each problem write: where (file and line), how I break it (the exact steps), what happens, severity (high, medium, low). Sort from the most severe. Don't fix anything and don't change the files: I only want the report.

Every piece has a reason.

• “You didn't write this code”: I take away its role as the author. An author defends their work, an outside reviewer looks for flaws.
• “Run git status and git diff, and read in full the new files”: git diff only shows changes to files git already knows about. Files created from scratch show up in git status, and without this line they'd be left out.
• “Your only job is to find how to break them”: I don't ask whether the code is fine. I ask it to attack it, which is a different question.
• The four areas, that is input, permissions, edge cases and security, are where apps built in a hurry break most often. If your app has a sensitive part, like payments, add it as a fifth line.
• “How I break it (the exact steps)”: a problem that comes with steps is one you can check yourself in two minutes. A “there might be a problem” isn't.
• “Don't fix anything and don't change the files”: the reviewer reports, it doesn't touch. If it fixed things, you'd have two sessions changing the same files and you'd lose track of who did what.

2. How I use it

1. When the first session says “done”, I don't ask it to check itself.
2. I open a new terminal in the same folder and run claude. Or, in the same window, /clear starts a new conversation with an empty context. The old one stays saved and you can pick it up again with /resume.
3. I paste the prompt. Before the commit, git status and git diff show the work that was just done. After the commit, I give it the files.
4. I take the report back to the first session and have it fix things starting from high severity.
5. On login, payments and user data I review the fix too, in yet another new session.

A detail about git diff: it shows changes to files git already knows about, so new files aren't in it. That's why the prompt includes git status, which lists them, and the reviewer reads them in full. If you'd rather see them in the diff too, run git add -N . in the terminal before opening the reviewer: git marks them as files to be added and from then on they show up in git diff.

The reviewer shouldn't be able to write

The prompt says not to change the files, but that's a request, not a lock. If I want to be sure, I open the second session in plan mode:

claude --permission-mode plan

In plan mode Claude reads files and can run commands to explore, like git diff, but it doesn't change the code until you approve a plan. If it ends up proposing a plan of fixes, don't approve it: the report is all you need. If the session is already open, you get in by pressing Shift+Tab until “plan mode on” shows up at the bottom.

Taking the report back

In the first session I paste the report with a prompt like this:

Here is the report from an outside reviewer: [paste the report]. Fix the high-severity problems first, one at a time. For each one, tell me what you changed and how you checked it. Don't touch the low-severity ones: I'll decide on those.

If I had used /clear, I first go back to the original conversation with /resume, so the session doing the fixes has the whole context of the work again.

I keep the low ones for myself for a specific reason. A reviewer you ask to find problems almost always finds some, even when the work is sound, because that's what you asked it to do. If you fix everything, you end up with extra code for cases that will never happen.

3. With a subagent, in the same window

If you don't want to open another window, the reviewer can be a subagent: a helper that works inside your session, with its own context, and doesn't see the conversation. In the guide on subagents I explain how to create a permanent code-reviewer with only the tools for reading.

The upside: the report goes straight back to the session that wrote the code, no copying and pasting. The risk: Claude writes the subagent's task, and Claude knows why it did things that way. If it explains that, the reviewer starts out already convinced. So I ask it to pass the prompt along as is:

Have the code-reviewer subagent review the latest changes. Pass it this prompt word for word, without adding any explanation of how or why you wrote the code: [paste the reviewer's prompt]

For the sensitive parts, though, I prefer the new session: there I paste the prompt myself and I know exactly what the reviewer received.

The golden rule

Nothing from the earlier conversation: if you explain why you did it that way, it ends up agreeing with you.

That goes for you too. When you paste the prompt, don't add “I did it this way because…”. Give it the changes and the job, and that's it. Explanations are useful later, when you decide which problems to fix.

A new session still reads the project instructions (CLAUDE.md) and auto memory, if you use them. That's fine: they're rules, not the story of how that code came about.

Common mistakes

• Asking the same session to check itself: open a new session, or use /clear, so whoever checks didn't write the code.
• Explaining to the reviewer why the code is built that way: give it only the changes and the job, or it ends up agreeing with you.
• Letting the reviewer do the fixing: ask it only for the report and have the session that wrote the code do the fixes.
• Fixing every reported problem: start from high severity and decide on the low ones yourself, or you'll fill the code with useless safeguards.
• Relying only on git diff when there are new files: they don't show up in the diff, so have it run git status too, as in the prompt.
• Not reviewing the fix on sensitive parts: for login, payments and user data, run the review again in a new session.

Checklist

• The reviewer is in a new session
• The prompt is pasted without explanations
• Before the commit: git status and git diff. After: the files you name
• Every problem has where, steps, effect and severity
• The high-severity problems are fixed and checked
• The sensitive parts got a second review

Frequently asked questions