Claude Code's Core Capabilities
Chapters 6–9 used Claude Code as it comes. This page adds ten features, one at a time, each building on the last: standing instructions, context control, plan mode, permission rules, skills, hooks, MCP, subagents, background sessions and worktrees. For every feature you get the problem it solves, how it works, when to use it, an example from the bookshelf project and its limits.
Ten Features in Learning Order
Anthropic's advice is not to configure everything up front: each feature has a recognisable trigger, and most teams add them in roughly the order below (Source 1). The order here follows that advice and each step reuses the one before.
| You notice… | Add |
|---|---|
| Claude gets a convention or command wrong twice | CLAUDE.md |
| You paste the same playbook into chat a third time | A skill |
| You copy data from a system Claude cannot see | An MCP server |
| A side task floods your conversation with output | A subagent |
| You want something to happen every time, without asking | A hook |
The table paraphrases Anthropic's "build your setup over time" guidance (Source 1). Everything below uses the real bookshelf project.
CLAUDE.md — Standing Instructions
| CLAUDE.md at a glance (Source 2) | |
|---|---|
| Problem it solves | Every session starts with an empty context, so you would re-explain commands and conventions each time. |
| How it works | Markdown files Claude reads at the start of every session: user (~/.claude/CLAUDE.md), project (./CLAUDE.md or ./.claude/CLAUDE.md), local (./CLAUDE.local.md, git-ignored) and managed policy. /init generates a starter; @path imports other files; .claude/rules/ files with a paths: filter load only for matching files. |
| When to use it | When Claude makes the same mistake a second time, or a review catches something it should have known. Add only what it cannot find by reading the repo. |
| Limits | It is context, not enforcement. Aim for under 200 lines; longer files reduce adherence. Imports organise a file but do not reduce its context cost. Conflicting instructions may be resolved arbitrarily. |
Every line passes the test from Chapter 8's best-practices advice: Claude could not infer it by reading the code and would otherwise rediscover it. The commands let it check its own work; the conventions record decisions; the two gotchas are the real failures from Chapter 9. Beside CLAUDE.md, Claude keeps its own auto memory: notes it writes itself, with the first 200 lines or 25KB of its MEMORY.md loaded each session (Source 2). If your repository already uses AGENTS.md for other tools, Claude Code can read that instead.
Context Management
| Context management at a glance (Source 3) | |
|---|---|
| Problem it solves | The context window fills with file reads, logs and history; quality and cost both suffer as it grows. |
| How it works | /context shows what occupies space. /clear starts fresh. /compact [focus] summarises the conversation; Claude Code also compacts automatically near the limit. A "Compact Instructions" section in CLAUDE.md steers what is kept. --continue/--resume reopen sessions. Subagents work in their own window and return a summary. |
| When to use it | Clear between unrelated tasks; compact with a focus mid-task; move bulky exploration to a subagent. |
| Example | /compact focus on the SQL query-count work and the test results |
| Limits | Compaction keeps requests and key snippets but can lose detailed early instructions, so put persistent rules in CLAUDE.md. If one huge output refills context after each summary, Claude Code stops auto-compacting and shows an error rather than looping. |
This closes the loop on Chapter 1's context rot: you now have a tool for each way context goes wrong — rules lost (CLAUDE.md), clutter (/clear), bloat (/compact), noisy side tasks (subagents).
Plan Mode
| Plan mode at a glance (Source 4) | |
|---|---|
| Problem it solves | A wrong first direction on a big change is expensive to unwind after files are edited. |
| How it works | Claude reads and explores but cannot edit until you approve a plan. Shift+Tab cycles modes; /plan prefixes one message; claude --permission-mode plan starts in it; Ctrl+G edits the plan in your editor. Project default: "permissions": {"defaultMode": "plan"}. The opusplan model alias uses Opus while planning and Sonnet while executing (Source 5). |
| When to use it | Multi-file changes, unfamiliar code, anything where you want to agree the approach first. Skip it for one-line edits. |
| Example | The pagination plan in Chapter 8. |
| Limits | A plan is only as good as the exploration behind it and is not a guarantee of the implementation. Read it for assumptions, not just steps. |
Permission Management
| Permissions at a glance (Source 6) | |
|---|---|
| Problem it solves | Constant prompts slow you down, but no prompts is unsafe. You want pre-approved safe actions and hard stops for dangerous ones. |
| How it works | Allow, ask and deny rules in .claude/settings.json (shared) or .claude/settings.local.json (personal); /permissions lists them. Rules are evaluated deny first, then ask, then allow, and the first match wins. Permission rules are enforced by Claude Code, not the model. |
| When to use it | Allow the commands you approve repeatedly (build, test, read-only git); deny what must never happen (reading secrets, pushing). |
| Limits | A broad deny cannot be overridden by a narrower allow. Command-text matching has limits; use the sandbox for OS-level isolation. Rules shape what is allowed; they do not make the model choose well. |
Result: tests and read-only Git run without prompts; pushing and reading .env are blocked in every mode. The syntax (Bash(npm run *), Read(~/secrets/**), Edit(/src/**)) comes from the tools reference (Source 7). The file parses as valid JSON — checked below with jq — but whether each rule behaves as intended was not exercised in a live session.
bypassPermissions is for isolated containers and VMs only. Rules plus Auto or Accept Edits mode give you speed without removing the safety net.Custom Commands and Skills
| Skills at a glance (Source 8) | |
|---|---|
| Problem it solves | You paste the same multi-step procedure into chat repeatedly, or need reference material that would bloat CLAUDE.md. |
| How it works | A directory with a SKILL.md (YAML frontmatter plus instructions) at .claude/skills/<name>/ (project) or ~/.claude/skills/ (personal). Claude sees names and descriptions every session and loads the full text only when used. Invoke with /name, or let Claude load it when the request matches. disable-model-invocation: true makes it user-only. Custom commands (.claude/commands/) are merged into skills and still work. |
| When to use it | Repeatable procedures (release, review, verify) and reference Claude needs only sometimes. |
| Limits | Descriptions drive automatic use: vague or overlapping ones cause misses or wrong picks. A skill instructs; it does not enforce. |
Three details from the frontmatter table matter here: allowed-tools pre-approves the Maven wrapper while the skill runs; the !-prefixed command runs first and its output is inlined (so Claude starts with the working-tree state already in front of it); and the last line makes it a safe, read-only check. Type /verify-build to run it. The frontmatter fields are those the skills page documents; the skill itself was not run in a session.
Hooks — Rules That Always Run
| Hooks at a glance (Source 9, Source 1) | |
|---|---|
| Problem it solves | CLAUDE.md and skills are requests the model may decide not to follow. Some rules must hold every time. |
| How it works | Handlers run at lifecycle events (PreToolUse, PostToolUse, Stop, SessionStart and others) from settings.json. Types: command (JSON on stdin, exit code and stdout), http, mcp_tool, prompt, and an experimental agent type. Exit code 2 blocks an action that can be blocked and shows stderr to Claude; other non-zero codes do not block. |
| When to use it | Things that must happen or never happen: format after every edit, block destructive commands, run tests before Claude may stop. |
| Limits | prompt and agent hooks use another model, so they are not deterministic. Hook scripts run with your privileges — review them before trusting a repository. If a Stop hook blocks eight stops in a row with no tool call between, Claude Code ends the turn. |
Hooks are the one feature here you can test completely outside a session, because a command hook is just a program that reads JSON and returns an exit code. Feeding it the same JSON shape Claude Code sends:
What it proves, and what it does not: the settings and MCP JSON parse; the script allows a harmless command (exit 0) and blocks two destructive ones (exit 2, message on stderr, which Claude would see as the reason). It does not prove Claude Code calls the hook with exactly this JSON — that is documented behaviour, but the hook was not wired into a live session. The Stop hook's command was run directly against the passing project and exited 0.
MCP — Connecting External Systems
| MCP at a glance (Source 10) | |
|---|---|
| Problem it solves | Some of what Claude needs lives in another system — a tracker, a database, a dashboard — and you are copying data into chat by hand. |
| How it works | The Model Context Protocol is an open standard for connecting AI tools to external services. Claude Code is the client; you add servers. Transports: HTTP (recommended), stdio for local processes, WebSocket; SSE is deprecated. Scopes: local (default), project (.mcp.json, shared via version control) and user. /mcp shows status and handles OAuth sign-in. Tool definitions are deferred, so idle servers cost little context. |
| When to use it | When the system has no good CLI. If a CLI exists (gh, aws), it is usually more context-efficient. |
| Limits | Servers that fetch external content can expose you to prompt injection; use servers you trust. Project servers in .mcp.json need your approval; a cloned repo cannot approve itself. Anthropic does not security-audit MCP servers. |
The file parses as valid JSON (checked above). A url entry without a type is a configuration error, because Claude Code reads it as stdio (Source 10). Use ${VAR} expansion for secrets instead of writing them into a file that is checked in. Real tokens and real servers were deliberately not used on this page.
Subagents
| Subagents at a glance (Source 11) | |
|---|---|
| Problem it solves | A side task — searching many files, running tests, reading logs — floods your main context with output you will not reuse. |
| How it works | A subagent runs in its own context window with its own system prompt, tool access and permissions; only a summary returns. Defined as Markdown with YAML frontmatter in .claude/agents/ (project) or ~/.claude/agents/. Required fields: name, description; common: tools, model. Built in: Explore (read-only search), Plan and a general-purpose agent. Claude delegates when a task matches the description, or you ask. |
| When to use it | Context isolation, parallel research, specialised reviewers, cheaper models for simple work. |
| Limits | A subagent starts fresh: it does not see your conversation. Results come back as text and still use context. By default subagents can spawn subagents up to three layers deep and up to 20 run concurrently. Token use scales with the number of agents. |
This agent can only read and search (tools: Read, Grep, Glob) and uses the cheaper Sonnet tier — Anthropic's cost advice suggests smaller models for simple subagent work (Source 3). It encodes Chapter 9's lesson, so the next person who adds an entity gets an N+1 check. Ask for it by name: "use the sql-reviewer subagent on my changes". The file uses the documented fields; it was not invoked in a session.
Background Tasks and Sessions
| Background sessions at a glance (Source 12) | |
|---|---|
| Problem it solves | A long task blocks your terminal while you wait, and you would like several tasks in flight. |
| How it works | claude --bg "task" or /bg in an open session starts a background session run by a supervisor process, so it keeps working after you close the terminal. claude agents opens agent view to monitor, peek, reply and attach; claude attach|logs|stop|rm manage sessions. By default a background session moves into its own git worktree before editing. /loop repeats a prompt within a session. |
| When to use it | Well-specified, long-running tasks with a clear check, such as investigating a flaky test. |
| Limits | Agent view is a research preview, so the interface and shortcuts may change. Each session uses your subscription quota independently. Sessions needing input will wait on you; an expired login stops unattended work. |
The docs separate this from subagents: subagents split work inside one session; background sessions are independent sessions you check on later. Pick background sessions only when the task is self-contained, and give it a check it can run unattended — an unattended agent cannot ask you a clarifying question.
Git Worktrees
| Worktrees at a glance (Source 13) | |
|---|---|
| Problem it solves | Two sessions editing the same checkout collide. |
| How it works | A git worktree is a separate working directory and branch sharing one repository. claude --worktree feature-auth creates .claude/worktrees/feature-auth/ on a new branch worktree-feature-auth. Subagents can run in their own worktree (isolation: worktree). A .worktreeinclude file copies git-ignored files such as .env into new worktrees. |
| When to use it | Parallel features or fixes; background sessions; subagents that edit files. |
| Limits | A worktree is a fresh checkout, so install dependencies in it. It shares the main repository's .git. "Yes, don't ask again" approvals are saved to the main checkout's settings and apply to every worktree. Cleanup: a clean unnamed worktree is removed on exit; one with work prompts you. |
Claude Code's flag wraps ordinary git worktree; the plain-Git equivalent can be run and inspected directly. This is the real command sequence on the bookshelf repository (the worktree and its branch were removed afterwards):
What it shows: a second directory with the same files (including the committed CLAUDE.md) on its own branch, both pointing at the same commit. The claude --worktree flag itself was not run, so naming, locking and cleanup behaviour come from the documentation. Add .claude/worktrees/ to .gitignore (the project does) so worktree contents do not appear as untracked files.
Which Feature for Which Problem
Anthropic's best-practices page frames the split as deterministic versus non-deterministic instructions: your prompt, CLAUDE.md and skills are read by the model, which usually follows them but may not; hooks, deny rules and managed settings are applied by Claude Code every time (Source 1, Source 14). The bookshelf setup follows it:
| bookshelf need | Feature used | Deterministic? |
|---|---|---|
| Know the commands and the H2 gotcha | CLAUDE.md | No — guidance |
Never push, never read .env | Deny rules | Yes |
Never run rm -rf or a force push | PreToolUse hook | Yes |
| Don't finish with a failing build | Stop hook | Yes |
| Check the build on request | /verify-build skill | No — Claude follows the steps |
| Catch N+1 queries in new code | sql-reviewer subagent | No — a reviewer's judgement |
| Read tickets | MCP server (illustrative) | Tool access: depends on server |
Configuring Claude Code
Bash(*) approves everything, including what you did not think of. Allow specific commands.claude -p runs that never show a trust dialog (Chapter 13). Read .claude/ and .mcp.json before you run Claude in a repository you did not write.Key Takeaways, Exercises and Sources
- Build the setup over time: add a feature when its trigger fires, not before.
- CLAUDE.md is guidance; hooks and deny rules are guarantees.
- Control context deliberately:
/clear,/compact, subagents. - Plan mode and permission rules let you trade prompts for autonomy without losing the safety net.
- Skills package procedures; MCP connects systems; subagents isolate noisy work.
- Background sessions and worktrees add parallelism — a research preview and a Git feature respectively.
- Test your configuration. Hook scripts are programs; run them.
Exercise 1 Beginner
Run /init in the bookshelf project and compare the generated CLAUDE.md with the one on this page. Delete every line Claude could have worked out from the code.
Learning outcome: distinguish what Claude can discover from what it must be told.
Exercise 2 Intermediate
Create .claude/hooks/block-destructive.sh and test it with the three echo | script commands from Section 6. Add a fourth pattern (for example git reset --hard), and write the test that proves it is blocked.
Learning outcome: build and verify a deterministic guardrail without a live session.
Exercise 3 Advanced
Design a minimal Claude Code setup for a team repository: one CLAUDE.md (under 40 lines), three permission rules, one hook, one skill and one subagent. For each, write the trigger that justifies it and the failure it prevents. Then remove the one you could defend least.
Learning outcome: choose the lightest mechanism that guarantees the behaviour you need.
- Anthropic, Extend Claude Code — feature comparison, build-over-time triggers, hook versus skill, context cost.
- Anthropic, How Claude remembers your project — CLAUDE.md locations,
/init, imports, rules, auto memory, AGENTS.md. Read in part. - Anthropic, How Claude Code works and Manage costs — context, compaction, subagents, model choice for subagents.
- Anthropic, Permission modes — plan mode.
- Anthropic, Model configuration —
opusplanalias. - Anthropic, Permissions — allow/ask/deny, evaluation order, rules enforced by Claude Code.
- Anthropic, Tools reference — rule syntax examples.
- Anthropic, Skills — SKILL.md layout, frontmatter fields, locations, invocation, merge with commands.
- Anthropic, Hooks — events, handler types, exit codes, example.
- Anthropic, MCP — transports, scopes,
.mcp.json, security, OAuth. - Anthropic, Subagents — format, frontmatter, built-ins, limits.
- Anthropic, Agent view and background sessions — research preview; commands; isolation.
- Anthropic, Worktrees — flag, location, cleanup, sharing,
.worktreeinclude. - Anthropic, Best practices — deterministic versus non-deterministic instructions; Stop-hook pattern.
Executed on this machine, 2026-10-30: jq validation of settings.json and .mcp.json; three runs of the hook script (exit 0, 2, 2); the Stop-hook command against the passing project (exit 0); and git worktree add/list. Not executed: claude mcp, claude --bg, claude agents, claude --worktree, /init, and any live session — so skill, subagent, permission-rule and hook integration behaviour is as documented, not observed. The MCP URL is a placeholder.