Claude Code 2.1.215 Makes Reviews Explicit

Claude Code, Anthropic's coding agent, 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. The takeaway is simple: 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.

The trap is reading 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:

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude mcp?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude mcp. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Claude Code 2.1.215 Makes Reviews Explicit.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• @anthropic — source
• Model Context Protocol — specification
• Anthropic — Claude Code product page
• Claude Code docs: en getting started

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.