Claude Code 2.0 Complete Builder's Guide

Claude Code 2.0 Complete Builder's Guide

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. Always verify your installed version with claude --version and the official changelog.

When should I use /btw instead of a subagent?

Use /btw when the answer depends on the current conversation and does not need tools. Use a subagent when Claude needs to inspect files, run commands, search logs, or explore something without filling the main context.

What is /loop best for?

/loop is best for repeated, observable checks: deploy status, flaky tests, queue completion, cleanup scans, or periodic maintenance. Avoid vague loops like “keep improving this,” because they create work without a finish line.

Which /effort level should I use?

Use lower effort for mechanical changes with cheap verification. Raise effort for architecture, debugging, security, data migrations, and anything where a wrong answer is costly. Maximum effort is a tool, not a default.

Do Agent Skills replace CLAUDE.md?

No. CLAUDE.md is for persistent instructions and rules. Skills are for repeatable procedures that should load only when relevant. If a checklist is long or task-specific, it probably belongs in a skill, not memory.

Can multi-agent code review replace human review?

No. It is a second line of defense. Claude Code review can surface bugs, security issues, edge cases, and regressions, but the team still owns the decision to merge.