Claude Code 2.0 Complete Builder's Guide: From Side Questions to Multi-Agent Review

Claude Code 2.0 is best understood as a working system, not a bigger autocomplete box. The useful upgrade is the operating model around the agent: side questions that do not poison the main thread, repeated checks that keep running while you work, effort controls for matching reasoning to risk, skills that load procedures only when needed, memory that survives fresh sessions, and review agents that can inspect a pull request from several angles.

As of August 11, 2026, the local Claude Code install checked for this guide is 2.1.227. The official Claude Code changelog lists v2.1.227 as the current release in the docs, with reliability fixes around feature flags, GitHub Action Bash execution, /tui, slash-command menu behavior, and performance. The product is moving fast, so treat this as an implementation guide for the current 2.1.x line, not a frozen manual.

If you are still evaluating whether an agentic coding workflow belongs in your team, start with the baseline: Claude Code can read a repo, run commands, edit files, and verify results inside an agent loop. The question is no longer "can it write code?" The question is whether you have enough process around it to keep that loop useful. That is the same reason we separate agent implementation from prompt experimentation in our AI agent implementation guide and our work on agentic coding workflows.

The mental model: protect the main thread

The central mistake with coding agents is treating the conversation like an endless scratchpad. Every side question, pasted log, failed guess, half-formed plan, and "while you are here" request competes for context. Claude Code 2.0 gives builders more ways to split that work:

• Use /btw when the answer should not become part of the main transcript.
• Use a subagent when something needs tools, file reads, or exploration in a separate context.
• Use /loop when a check should repeat without you manually poking it.
• Use skills when a workflow is repeatable enough to deserve a local procedure.
• Use memory when a rule or correction should survive the next fresh session.

That is the practical shift. A good Claude Code setup is not "one giant CLAUDE.md." It is a set of small, scoped channels for the right kind of context.

/btw: ask without polluting history

The official Commands reference describes /btw [question] as a quick side question that does not add to the conversation. The Interactive Mode docs make the distinction sharper: /btw sees the full conversation but has no tools, while a subagent has tools but starts with empty context.

That makes /btw perfect for questions like:

/btw what did we decide about the migration order?
/btw is this error likely from the test runner or the database?
/btw summarize the risky parts of the diff so far in one paragraph

Use /btw when you need an answer based on what Claude already knows. Do not use it to investigate a file, inspect logs, call an API, or verify a claim. That is subagent work. The clean rule is simple: if the aside should not change the plan and does not need tools, use /btw. If the answer could affect implementation, pull it back into the main thread or assign a subagent.

This matters for long sessions. Claude Code can now reopen the recent /btw overlay without a new question, so the side-channel becomes a lightweight notebook for transient reasoning. It is not a replacement for project memory. It is a way to keep your working transcript from becoming a junk drawer.

/loop: make waiting explicit

The same Commands reference defines /loop [interval] [prompt] as a skill that runs a prompt repeatedly while the session stays open. The interval is optional; Claude can self-pace. The prompt is optional where autonomous maintenance or .claude/loop.md is available. The alias is /proactive.

Useful loops are boring:

/loop 5m check whether the preview deploy finished and report only if the status changes
/loop 10m rerun the flaky test and stop after one clean pass
/loop check the repo for obvious unfinished work before I return

Bad loops are vague:

/loop make the project better
/loop keep optimizing this

A loop needs an exit condition. Otherwise you have created a tireless intern with no definition of done. The lazy senior-engineer version is to ask for the smallest repeated check that removes your own polling. Watch a deploy. Re-run a single test. Check whether a long migration finished. Do not turn /loop into a background product manager.

For production agent systems, this is the same pattern we use in AI automation services: repeatable checks are useful when the state is observable and the action is constrained. They are dangerous when the goal is fuzzy.

/effort: match reasoning to risk

/effort [level|auto] lets you set model effort. The docs list low, medium, high, xhigh, max, and ultracode, with availability depending on the model. It can be changed through an interactive slider and takes effect immediately.

Use effort levels like engineering gears:

Do not leave every task at maximum effort. That is not rigor; it is an expensive default. The better habit is to raise effort only when the decision surface widens. If a task touches money, auth, data loss, deployment, or multiple packages, increase effort. If the task is mechanical and the tests are fast, stay lower and verify.

/dataviz: charts need design rules, not just SVG

The Commands docs describe /dataviz [request] as a skill for charts, graphs, and dashboards. It chooses chart form, assigns color by role, validates palettes for colorblind safety and contrast, and applies mark, interaction, and accessibility rules.

The important word is "skill." /dataviz is not magic chart taste. It is a packaged procedure that helps Claude make better decisions about chart type, color, and accessibility. Use it for engineering reports, release dashboards, regression summaries, cost curves, benchmark comparisons, and incident timelines.

A good request looks like this:

/dataviz turn this latency CSV into a before/after chart for an engineering review. Show p50, p95, and p99. Make the regression obvious without using red/green only.

A bad request is "make a cool chart." The useful constraint is the decision the chart should support. If a visualization does not change what a reader understands or does next, do not make one.

Agent Skills: move repeatable work out of chat

The Skills docs explain the core mechanism: a skill is a SKILL.md file with instructions that Claude can load when relevant or when invoked directly. Unlike always-loaded memory, the body of a skill loads only when used. Custom commands and skills have effectively converged: a command file and a skill can both create slash-command behavior.

That is a big deal for teams. It means you can stop pasting the same checklist into every session:

• "How we review migrations" becomes a migration-review skill.
• "How we prepare a release note" becomes a release-note skill.
• "How we debug payment webhooks" becomes a payments-debug skill.
• "How we run visual regression checks" becomes a verification skill.

Keep skills short at the top and put bulky examples, templates, and scripts in supporting files. The docs explicitly support templates, examples, scripts, and reference documentation next to SKILL.md. That gives you a clean pattern: the skill decides what to load, not your system prompt.

For a deeper strategy on this, see our context engineering for AI agents article. The principle is the same: context is budget. Spend it only when it changes the next action.

Memory: CLAUDE.md is not a dumping ground

The Memory docs say each Claude Code session starts with a fresh context window. Continuity comes from two mechanisms: CLAUDE.md files and auto memory. CLAUDE.md contains user-written instructions and rules at project, user, or organization scope. Auto memory contains Claude-written learnings and patterns, stored per repository and shared across worktrees, with the first 200 lines or 25KB loaded into every session.

The practical memory hierarchy should be:

1. Hard rules: put them in CLAUDE.md or hooks.
2. Repeatable procedures: put them in skills.
3. Discovered preferences: let auto memory capture them, then curate if they become important.
4. Temporary session facts: keep them in the conversation or /btw, not memory.

Do not write architecture tours into memory if Claude can inspect the repo. Do write rules that are not obvious from code: "never run the destructive reset script in production," "offers use cents, not euros," "LinkedIn posts must go to the company page." Those are the details that prevent expensive mistakes.

Multi-agent code review: second line, not final authority

The Code Review docs describe the managed review feature as a research preview for Team and Enterprise. It reviews GitHub pull requests, posts inline comments, and uses a fleet of specialized agents to inspect the full codebase context for logic errors, security vulnerabilities, broken edge cases, and regressions. Findings are tagged by severity and do not approve or block the PR. On other plans, local /code-review is still available in the terminal.

That last constraint is healthy. Multi-agent review should not replace ownership. It should catch what humans miss when the diff is large, the reviewer is tired, or the edge case is buried in another file.

Use it before a human review when:

• the change crosses package boundaries,
• the branch touches auth, payments, permissions, or data deletion,
• the diff contains generated code,
• the implementation was mostly agent-written,
• the reviewer needs a risk map before reading every line.

Do not use it as a rubber stamp. A review agent can surface risk, but your team still owns the merge.

A practical setup for a team

If you are adopting Claude Code 2.0 across a team, start small:

1. Install and confirm the version with claude --version.
2. Add a minimal CLAUDE.md with only non-obvious rules.
3. Create one skill for the most repeated workflow.
4. Teach engineers when to use /btw versus a subagent.
5. Define effort defaults by risk category.
6. Add /code-review before human review on large branches.
7. Use /loop only for observable checks with clear stop conditions.

This is enough. You do not need a full platform on day one. The first win is a cleaner loop: gather context, act, verify, and keep noise out of the main thread.

Definition of Done for Claude Code 2.0 adoption

• CLAUDE.md exists and contains only current, non-obvious project rules.
• At least one team workflow has moved from pasted prompt to skill.
• Developers know the /btw vs subagent rule.
• Effort levels are documented for low-risk, normal, and high-risk tasks.
• /code-review is part of the PR checklist for risky or agent-heavy diffs.
• A loop prompt includes a concrete interval, observable condition, and stop rule.
• Memory is reviewed monthly so stale rules do not become hidden debt.

FAQ

Is Claude Code 2.0 the same as Claude Code v2.1.227?

Not exactly. "Claude Code 2.0" is the product generation people refer to; v2.1.227 is the current checked release for this guide on August 11, 2026. The version number increments frequently — sometimes daily — with reliability fixes, new slash commands, and feature flag adjustments. Always verify your installed version with claude --version and cross-reference the official changelog before relying on a specific feature. If you are writing documentation or team guides, pin the version you tested against and note the check date.

When should I use /btw instead of a subagent?

Use /btw when the answer depends on the current conversation context and does not need tools. For example, if you want a quick summary of what was decided so far, or a sanity check on whether an error pattern matches something already discussed, /btw is the right call. Use a subagent when Claude needs to inspect files, run commands, search logs, or explore something without filling the main context. A subagent starts with an empty context window but has full tool access, making it ideal for investigative work that should not pollute your working transcript. The rule of thumb: if the aside should not change the plan and does not need tools, use /btw. If the answer could affect implementation, pull it back into the main thread or assign a subagent.

What is /loop best for?

/loop is best for repeated, observable checks: deploy status, flaky tests, queue completion, cleanup scans, or periodic maintenance. The key is that each iteration should have a clear exit condition — "stop after one clean pass" or "report only if status changes." Avoid vague loops like "keep improving this," because they create work without a finish line and consume tokens indefinitely. A well-designed loop replaces manual polling: instead of checking a deploy every 5 minutes yourself, you delegate that to Claude and get notified only when something changes. For production agent systems, this is the same pattern we use for automated monitoring — repeatable checks are useful when the state is observable and the action is constrained.

Which /effort level should I use?

Use lower effort for mechanical changes with cheap verification — renames, formatting, simple test fixes. Raise effort for architecture decisions, debugging complex issues, security review, data migrations, and anything where a wrong answer is costly. The effort slider is not about quality; it is about matching reasoning depth to risk. A rename at max effort wastes tokens without improving the result. A data migration at low effort saves tokens but risks subtle data loss. The practical approach is to define team defaults by task category: low for mechanical changes, medium for normal feature work, high for debugging, and xhigh/max for anything touching auth, payments, or data integrity. Review your defaults monthly as the model and tooling evolve.

Do Agent Skills replace CLAUDE.md?

No. CLAUDE.md is for persistent instructions and rules that apply to every session — coding standards, project conventions, safety rules. Skills are for repeatable procedures that should load only when relevant — a migration checklist, a release-note template, a debug workflow. If a checklist is long or task-specific, it probably belongs in a skill, not memory. The two mechanisms complement each other: CLAUDE.md sets the baseline rules, and skills provide step-by-step procedures that activate on demand. Think of CLAUDE.md as the team handbook and skills as the runbooks. Auto memory captures discovered preferences and patterns that neither the handbook nor the runbooks cover yet.

Can multi-agent code review replace human review?

No. It is a second line of defense, not a replacement for human judgment. Claude Code review can surface bugs, security issues, edge cases, and regressions that a tired reviewer might miss on a large diff. But the team still owns the decision to merge. Multi-agent review is most valuable before a human review when the change crosses package boundaries, touches auth or payments, contains generated code, or was mostly agent-written. In those cases, the review agents produce a risk map that helps the human reviewer focus on the highest-stakes areas first. Treat it as a force multiplier — it catches what humans miss, but it does not have the context to decide what is acceptable for your product.

Sources

• Claude Code Changelog — Version history and release notes for the 2.1.x line
• Claude Code Commands Reference — Official documentation for /btw, /loop, /effort, /dataviz, and other slash commands
• Claude Code Interactive Mode — Subagent and /btw behavior, context isolation rules
• Claude Code Skills — SKILL.md format, supporting files, and skill invocation
• Claude Code Memory — CLAUDE.md hierarchy, auto memory, and session continuity
• Claude Code Code Review — Multi-agent PR review, severity tagging, and managed review feature