Claude Code Review Is Now Generally Available — Its REVIEW.md Rules Only Count Once Merged, and Branch Protection Decides the Rest (2026)

The general availability announcement describes three changes. Reviews are faster than during the preview. Findings are written to be shorter, stating the problem, what triggers it, and the fix. And admins now pick a review level per repository: "Admins choose Quick, Standard (default), or Deep for each repository, so routine codebases get a quick pass and the most critical ones get a deep review."

The shape of the product is the same: several agents read each change, a verification step filters their findings, and results arrive as inline comments plus a check run named Claude Code Review. Two properties matter before anything else:

• It doesn't merge or block. The documentation says "A review never approves or blocks the pull request, so the decision to merge stays with your team."
• It reads, it doesn't run. A review "works from reading the diff and the surrounding code, without building or running your code." Inside a review, "access to your repository is read-only, and a review doesn't push commits."

So the reviewer's judgment rests on what it reads, including your instruction files.

Code Review takes guidance from two kinds of file in your repository.

CLAUDE.md is the project instruction file Claude Code already uses. Anthropic describes it as "project instructions that Claude Code reads for every task, reviews included. Code Review reads them as project context and flags changes that violate them." The review doesn't read every CLAUDE.md in the repository. "A review reads the CLAUDE.md at your repository root and the CLAUDE.md files in the parent directories of each changed file. A subdirectory's CLAUDE.md is read when the pull request changes a file under that path."

REVIEW.md is specific to Code Review. It's "instructions for reviews alone. Use it to say what your team wants flagged, at what severity, and what to skip." You can place one at the repository root and add more in subdirectories to add checks for changes under those paths. Its contents reach every stage of the review: "The agents that find issues and the agents that verify them receive its contents as your repository's review instructions, alongside Code Review's default review guidance. The step that writes the final review consults it before settling severity and writing the summary."

The split Anthropic recommends is simple: "Keep REVIEW.md to instructions that change review behavior, and leave general project context in CLAUDE.md." By default, Code Review focuses on correctness, meaning bugs that would break production rather than formatting or test coverage. REVIEW.md is how you move that line for your repository: redefine what counts as Important, cap the nits, list paths to skip, add checks your team cares about, or require a file and line as evidence for certain kinds of finding.

In a post on how the Claude Code team does code review, Anthropic writes that "CLAUDE.md tells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so in a large codebase we keep it short and point to other docs from there." And "REVIEW.md, written by code owners, tells the reviewer what matters in their part of the code. We check separately whether the reviewer actually follows it."

Anthropic doesn't assume the file is followed. The rules below explain why a rule you wrote might not be in effect.

The documentation is unambiguous: "Code Review reads REVIEW.md from the pull request's base branch or from the default branch, never from the pull request's own changes. To change review behavior, merge the REVIEW.md change first."

In practice, this catches a natural workflow. A developer notices the reviewer flagging generated files, adds a skip rule to REVIEW.md in the same pull request that triggered the comments, and pushes. The next review runs against the copy of REVIEW.md on the base or default branch, which doesn't have the new rule yet. The comments keep coming until the change is merged.

Likewise, the pull request that first introduces REVIEW.md is reviewed without it.

The documentation states the rule without giving a reason. Its effect is that a pull request's own edits to REVIEW.md can't lower the severity of its findings or exclude the files it changes. That decision stays with whoever controls merges to the branch the review reads from.

The practical consequence: treat REVIEW.md changes as their own small pull requests, merged before the work they're meant to affect.

Merging REVIEW.md isn't the end of it. Code Review checks whether the branch it reads from is protected, and the answer changes what it reads and what it honors.

Anthropic's guidance is to "Keep REVIEW.md on your default branch and protect that branch." When the review reads the copy on a protected default branch, it honors three kinds of instruction from the root file:

• Lowering a finding's severity
• Excluding paths, files, or classes of issue
• Capping nit comments

Those are three of the five kinds of instruction the documentation suggests writing in the first place. A REVIEW.md that says to ignore lockfiles and keep nits to a handful depends on branch protection to take effect.

The documentation lays out four situations:

Two rows deserve attention. In the third, subdirectory REVIEW.md files aren't read at all, so per-directory checks drop out. In the fourth, no REVIEW.md is read. The documentation notes that this case "includes an unprotected default branch with a base branch that has only a classic rule".

What counts as protection is also specific. For the default branch, Code Review accepts "a classic branch protection rule or a ruleset". For any other branch, it's "a ruleset only". And not every ruleset qualifies: "A ruleset counts when it restricts updates or requires pull requests with at least one approval. If it requires pull requests, it must also dismiss that approval on a new push or require the approval to come after the last push."

The check run tells you when this is happening. One message reads "This review applied the repository's review instructions (REVIEW.md) from its default branch, which is not protected against direct pushes." That one means only the root file was read. Another says the instructions "were not applied to this review: branch protection could not be confirmed", meaning none were.

Code Review has a sibling that runs in your own session. The documentation calls out the difference directly: "The Code Review service and the local /code-review command are two separate tools, and they read different files."

The service reads both CLAUDE.md and REVIEW.md. The local command follows your CLAUDE.md, "including in a non-interactive -p run. It doesn't read REVIEW.md."

That has a consequence for how you write rules. A check that lives only in REVIEW.md will appear in pull request reviews and not when a developer runs /code-review before opening the pull request. Anthropic's advice: "Put guidance you want applied in both places in CLAUDE.md, and keep REVIEW.md for rules specific to pull request review."

Developers who review locally before pushing will see two reviewers working from overlapping but different instructions.

Assuming a new REVIEW.md works as soon as it's pushed. It works once it's merged to the branch Code Review reads from, and fully only when that branch is protected. Our guide to why agents ignore your instruction files covers the same kind of gap in coding sessions.

Assuming replies teach the reviewer. Replying to a finding is a conversation with the next review of that pull request, not a lasting rule. "Replying alone doesn't dismiss a finding." The next review "reads the replies on its earlier findings, and can resolve the thread or post one follow-up reply." The documentation's advice for a finding that keeps recurring is to "ask a maintainer to add a rule to REVIEW.md."

Assuming CLAUDE.md is only for coding sessions. Code Review reads it as project context and flags violations. Anthropic's team notes that its own reviewer "also flags code that breaks a convention in it, and changes that make a line in it out of date." Once a reviewer reads CLAUDE.md, keeping it current matters for reviews, not just sessions. Our guide to conflicting CLAUDE.md layers covers how to find and fix those.

Step 1: Protect the default branch and confirm which copy is read

Check your branch protection against the table above. Give the default branch a classic rule or a ruleset. If pull requests target other long-lived branches, those branches need a ruleset for their own REVIEW.md copies to count.

Then open a small test pull request and read the check run. If it says instructions came from an unprotected branch, or weren't applied, fix that first.

Step 2: Split your rules between CLAUDE.md and REVIEW.md

Go through the rules you want enforced and sort them:

• Rules about the project itself go in CLAUDE.md: conventions, architecture boundaries, the non-goals a change shouldn't drift toward. These apply in coding sessions, in local reviews, and in pull request reviews.
• Rules about reviewing go in REVIEW.md: what counts as Important in this repository, how many nits to post, which paths to skip, which checks to always run.
• Rules for one area of the code go in a subdirectory CLAUDE.md or REVIEW.md. Subdirectory REVIEW.md files depend on branch protection.

Merge the REVIEW.md change on its own. If you're writing CLAUDE.md rules for the first time, our guide to making Claude stick to your coding style covers how to phrase conventions so they're followed.

Step 3: Turn repeated findings into merged rules, and keep the reasons

Anthropic's own process is the model here. "When the automated reviewer keeps flagging the same thing, we fix it at the source", the team writes. Their recommended rollout is to add an AI reviewer to one repository, "tune REVIEW.md for a few weeks, then widen." And when a review misses something, "we ask what the model didn't have in front of it and put the fix into a CLAUDE.md, a skill or a new check."

Each of those fixes is a decision: why a path is excluded, why a class of finding is Important here and a Nit elsewhere, which incident led to a check. The rule goes in the file. The reason is worth keeping too, because the next person to edit REVIEW.md needs it to know whether the rule still applies. Our guide to Claude Code forgetting your corrections covers the same pattern for coding sessions: the corrections that matter most belong in a file the whole team can read.

REVIEW.md holds the rule. The history behind it, such as the incident, the debate, and the alternative you rejected, lives wherever that discussion happened: a pull request thread, a chat, one person's memory. MemoryLake is a memory layer for keeping that kind of decision record in one list you maintain, available to Claude Code and the other assistants you connect while you write the code a review will later read.

You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from your repository's CLAUDE.md or REVIEW.md files, your pull requests, Code Review's findings, or any vendor's store. The Code Review service reads only what's in your repository, so the rules it applies still belong in those files. Check your organization's policy before storing project details outside the repository.

Step 1: Create an API key

Sign in and generate a key from the dashboard. The key belongs to your MemoryLake workspace and is separate from your Anthropic and GitHub accounts.

Step 2: Upload your first memories

Start with the reasons behind your review rules: why a path is skipped, why a finding class is Important in this repository, which incident led to a check. One decision per entry, dated, with a pointer to the rule it explains.

Step 3: Connect your AI & agents

Connect Claude Code and any other assistants you use. The reasoning behind your rules is then available while code is being written, before a pull request ever reaches the reviewer.

The first change is fewer surprises in the check run. Once branch protection is confirmed, the exclusions and nit caps you wrote take effect. The second is consistency: rules that should apply everywhere sit in CLAUDE.md, so a local /code-review and the pull request review expect the same things. The third is a setup that improves on purpose, with recurring findings turned into rules whose reasons are written down. Our look at what coding agents actually read covers why that written context matters across tools.

Merge REVIEW.md changes on their own. A pull request is reviewed with the base branch's copy.

Protect the default branch. Severity changes, exclusions, and nit caps depend on it.

Read the check run messages. They say when only the root file was read, or none.

Put shared rules in CLAUDE.md. The local command doesn't read REVIEW.md.

Keep both files short. Anthropic's own verdict on review files: "The good ones are short."

Code Review's general availability makes AI review on every pull request a default option for Team and Enterprise organizations. What it reviews against is still up to the team: REVIEW.md is read from the base or default branch, never from the pull request's own changes; branch protection decides whether subdirectory files count and whether severity changes, exclusions, and nit caps are honored; and when protection can't be confirmed, no REVIEW.md is read. Protect the branch, split project rules from review rules, and turn repeated findings into merged rules with their reasons recorded.