Writer, reviewer, and the findings that are not real

The diff is finished and you have spent an hour getting it there. Lesson 5.5 already made the argument that the grader must not be the writer, and handed you /code-review for the correctness case. This lesson is the other case: the check you want is not "are there bugs" but "does this do what we agreed", so you have to arrange the second reader yourself.

Level 8 changes two things about that. The reviewer's context is now something you choose rather than something you get. And its report lands in your main window and is paid for out of it, which makes the brief a budget as well as an instruction.

Two contexts, one change

The docs give the pattern two shapes, and the difference between them is who carries the findings back.

In the two-session version, Session A gets Implement a rate limiter for our API endpoints, Session B gets a brief naming the file, and then Session A gets a third message — Here's the review feedback: [Session B output]. Address these issues. That third message is you, acting as the transport. The subagent version removes it:

Because the reviewer runs as a subagent, the implementing session receives the gaps directly and can fix them and re-review without you copying findings between windows. — Best practices

Neither shape is better in general. Two sessions when the review is a separate piece of work you want to sit with; a subagent when the point is a round trip that ends with the gaps closed.

Why the author is the wrong reviewer

The reason is not that the writing context is careless. It is that it is convinced. A fresh context reviews better precisely because Claude is not biased toward code it just wrote — Lesson 5.5 quoted the mechanism, that a reviewer in a fresh subagent context sees only the diff and your criteria, not the reasoning that produced the change, and Lesson 8.3 aimed that same sentence at forks. Read it against Lesson 8.2 and it inverts. Everything 8.2 listed as missing from a subagent — the conversation history, the skills already invoked, the files Claude already read — is here the entire point. Isolation was the thing you had to write a brief around. In a review it is the product.

Which makes one option in Lesson 8.3 the wrong one. A fork inherits the entire conversation instead of starting fresh, dropping exactly the input isolation this section is asking for; 8.3 has the definition and the trade in full. So a fork inherits the argument you had about why this approach was chosen. It is an excellent way to hand off a side task without re-explaining the situation, and a poor reviewer, because the thing you wanted withheld is exactly what it starts with. Do not review your own diff in a fork.

The brief that produces useful findings

The documented example is four clauses long, and every clause is load-bearing:

Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.

The second row is where 8.2's rule bites. The reviewer has no conversation history, so "check it against what we agreed" names a standard it cannot open — and nothing in the arrangement makes it say so. What comes back is a review against whatever standard the diff itself implies, which is the one you were trying to check. A file path is a fact it can act on; a memory of your afternoon is not.

The correctness variant is more specific still:

Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns. — Best practices

Three named classes of problem rather than "look for problems". That is Lesson 2.3's pattern-anchoring applied to a delegate: an unscoped reviewer searches the space of everything that could be wrong, which is exactly the space where invented findings live.

Scope the reviewer's tools too

The doc's own code-reviewer example is "a read-only subagent that reviews code without modifying it", with "limited tool access that excludes Edit and Write" (Subagents):

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---

The point of that list is not what the reviewer will do, it is what it can. A tools list containing Edit leaves nothing between a finding and a fix, and a fix made during the review is a second change inside the one you were about to review — unreviewed, because its author was the reviewer. Lesson 8.4 called a permissive tools list the standing temptation; this is the case where it costs you the whole exercise.

The adversarial-review caveat

Lesson 5.5 taught you to discount findings after they arrive. Level 8's version of the same fact is that the discount belongs in the brief, before any finding exists.

A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering: extra abstraction layers, defensive code, and tests for cases that can't happen. Tell the reviewer to flag only gaps that affect correctness or the stated requirements, and treat the rest as optional. — Best practices

Two instructions in one paragraph. Flag only gaps that affect correctness or the stated requirements goes in the brief. Treat the rest as optional is a disposition you need afterwards, because a bounded brief reduces manufactured findings without eliminating them.

Now put that together with 8.1's warning about fan-out — many subagents each returning a detailed result consume significant context, because every one of those results lands back here. Three reviewers on an unbounded brief is not three times the assurance. It is three sets of findings you did not need, each one paid for in the window you still have to do the fixing in.

Triaging what comes back

Every finding is a claim. The reviewer read the diff; unless its brief and its tools let it run something, it did not execute anything, and a claim about behaviour that nobody ran is a hypothesis with a confident voice. Lesson 5.1's distinction applies unchanged to a delegate's report.

The last row is worth staring at. A brief bounded to "the stated requirements" produces findings you can check against a document, which is the only kind of finding that closes cleanly.

Asking for the second pass

You rarely want one review. You want a review, some fixes, and a re-read of the same diff by the same reader. Ask Claude to continue rather than describing the job again:

Use the code-reviewer subagent to review the authentication module
[Agent completes]

Continue that code review and now analyze the authorization logic

Claude resumes the subagent with the full context from the previous conversation rather than spawning a cold one. One limit to know before you build a habit on it: "the built-in Explore and Plan agents are one-shot and return no agent ID, so Claude can't resume them. Use general-purpose or a custom subagent when you need to continue the work" (Subagents). Explore is the natural reflex for a read-only task and the wrong one here.

What you are actually arranging

Independence is not a quality the reviewer has. It is four decisions you make before it starts: a context that never saw the reasoning, a standard that lives in a file, a definition of a finding narrow enough to be checkable, and a tool list that cannot turn a review into an edit. Get those wrong and the review still runs, still returns a tidy list, and still costs you the window — which is why this one fails quietly rather than loudly.