Claude Code 2.1.215 Makes Reviews Explicit
Claude Code listed version 2.1.215 in the @anthropic changelog with a small but sharp behavior change. The release deals with a subtle workflow problem: Claude no longer runs the /verify and /code-review skills on its own. Ask for verification or review when the diff is ready, instead of assuming the agent will decide for you. For engineers wiring a Claude Code mcp server into the same repo workflow, external context can still help, but review is now an explicit command boundary.
Read the changelog as a new boundary
Claude Code 2.1.215 is not a big feature announcement. It is a correction to where responsibility sits in the coding loop.
A Claude Code skill is an on-demand capability that packages instructions, workflows, scripts, or reference material for Claude to use. In this release, two review-shaped skills stop being automatic background behavior: /verify and /code-review.
That matters because review work feels different from implementation work. When Claude changes code, you want its next move to be predictable. A manual /verify says: check whether this satisfies the task. A manual /code-review says: review this diff like a reviewer, not like the author still editing it.
Don't read the changelog as if Anthropic removed review help. It did not. The commands still matter; they are just no longer something Claude decides to run by itself. That small convention belongs with Claude Code team conventions, not buried in a one-off prompt.
Call /verify and /code-review when the diff is ready
The clean workflow is to separate building from judging.
Say you are changing auth middleware in a Next.js app. Claude edits the middleware, updates tests, and explains the patch. At that point, do not wait for an implied review pass. Run /verify when you want the work checked against the original request, then run /code-review when you want a reviewer-style pass over the diff.
This replaces a fuzzy habit: asking Claude to keep working until it somehow decides the work is safe. That habit can hide the moment where the task switches from authoring to review. Version 2.1.215 makes the switch visible.
There are honest limits. The changelog does not say these commands are a security audit, a test oracle, or a substitute for human review. The quality still depends on the skill definition, the repo context, available test output, and the prompt you give right before invoking the command.
If you are comparing this with earlier Claude Code session behavior, the related note on claude-code 2.1.212 splitting forks and subtasks is useful background. The pattern is similar: make the agent's mode of work visible before you trust the result.
Keep MCP context separate from the review trigger
Model Context Protocol is a standard way for an agent to connect to external systems such as repositories, design tools, issue trackers, databases, and internal docs. In Claude Code, MCP can provide the evidence a review needs, but it should not decide when review starts.
That distinction is easy to miss. A Claude MCP setup might let Claude read a GitHub issue, inspect design context, or fetch a runbook. None of that means it should post a PR comment, approve a change, query production data, or run /code-review without you asking.
Use a permission boundary table like this for one repo:
| Boundary | Allow by default | Ask first | Never assume |
|---|---|---|---|
| GitHub MCP | Read linked issue text and PR metadata | Post comments or labels | Approval means the diff is safe |
| Figma MCP | Read frame names, specs, and design notes | Export assets or generate files from designs | Design context replaces product acceptance criteria |
| Database MCP | Read schema docs or local dev data | Query shared staging data | Writes to production are allowed |
| /verify | Check the finished change against the task | Broaden the task scope | Verification means all tests passed unless tests were run |
| /code-review | Review the current diff when invoked | Rewrite the patch during review | Review should start automatically |
Multiple Claude Code MCP servers make this boundary more important, not less. The more places Claude can read from, the more valuable it is to keep the final review command explicit.
Try it in one repo first
Prerequisites: choose one active branch, make sure /verify and /code-review are available in your Claude Code environment, and pick a task with a small diff. If your repo uses CLAUDE.md, add only a short reminder there; do not turn the file into a giant process manual.
Step 1: finish the authoring pass. Ask Claude to make the code change and stop after it summarizes the files it touched. Keep the task small enough that you can read the diff yourself.
Step 2: collect the evidence. Run the normal local command for the repo, such as npm test, pnpm lint, or a targeted unit test. Paste the relevant failure or success output back into the session.
Step 3: invoke /verify. Use /verify after the implementation and evidence are present. Ask it to check the change against the original request, not to invent adjacent improvements.
Step 4: invoke /code-review. Use /code-review after /verify, especially before opening or updating a pull request. Ask for findings, risk, and missed tests; avoid asking for a rewrite in the same breath.
Verification step: prove the boundary held. In the session transcript, you should see that Claude only entered verification or review after your explicit slash command. If review happened before that, tighten the repo note and repeat the experiment on a smaller change.
Make the next review explicit
Pick one branch today and run the new rhythm once: implement, gather evidence, /verify, then /code-review. If the transcript makes the handoff obvious, keep the convention; if not, make the task smaller and try again.