The specialist's playbook

TL;DR. Being a Claude Code specialist is knowing which surface to reach for, and there are six: CLAUDE.md for always-on facts, .claude/rules/ for path-scoped guidance, skills for procedures that load on demand, hooks for things that must run no matter what, MCP servers for external tools, and subagents for verbose work you want kept out of the main window. This chapter is the full context-relevant command and configuration reference, plus the decision rule for what goes where and the working habits that follow from it.

Contents

• The command surface
• The settings hierarchy
• Hooks: enforce and preprocess
• MCP servers and tool deferral
• Subagents: isolated context on demand
• What goes where
• Working habits of a specialist
• Further reading
• Takeaways

The first chapter of this part showed what is in a session; the second showed how it persists. This one is the controls. It is a reference, so skim the tables and come back to them, but read the last two sections in full, because they are the judgment that turns the controls into a practice.

The command surface

Claude Code is driven by slash commands inside a session and flags on the claude command that starts one. These are the ones that touch context, memory, and cost. (Commands and behavior move between versions; check claude --version and the docs for your build.)

In-session slash commands:

Flags that start a session (set the context before turn zero):

A claude agents view manages parallel background sessions, and claude --from-pr <n> resumes the session that opened a pull request. The two you will reach for most are -c to pick up where you left off and /context to see where the tokens went.

The settings hierarchy

Configuration is layered, and the layers have a strict precedence. Higher wins:

   1. managed / policy settings        org-deployed, cannot be overridden (not even by a flag)
   2. command-line flags               this invocation
   3. .claude/settings.local.json      your private project settings (gitignored)
   4. .claude/settings.json            team project settings (in source control)
   5. ~/.claude/settings.json          your user settings (every project)

The context-relevant keys: model and thinking configuration; autoMemoryEnabled and autoMemoryDirectory (Chapter 18); claudeMdExcludes to skip ancestor instruction files in a monorepo; permissions (allow / deny / ask) to gate tools; hooks (below); statusLine to show context usage continuously; and claudeMd (managed scope only) to ship organization instructions inside the settings file. Most keys hot-reload when you edit the file; a few apply on the next start.

Remember. Settings are enforced by the client; CLAUDE.md is advisory to the model. If a rule must hold regardless of what Claude decides, encode it as a permission or a hook, not as a sentence in CLAUDE.md. This is the single most common specialist mistake to avoid.

Hooks: enforce and preprocess

A hook is a shell command Claude Code runs at a fixed point in its lifecycle, configured in settings.json. Hooks are the enforcement and preprocessing layer, and two of their uses are pure context engineering.

The first is preprocessing tool output before it reaches the context, which is the cheapest large token saving available. The official example is a PreToolUse hook on Bash that, when the command is a test runner, rewrites it to show only failures, turning a ten-thousand-line log into a few hundred tokens before Claude ever sees it:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [ { "type": "command", "command": "~/.claude/hooks/filter-test-output.sh" } ] }
    ]
  }
}

This is the same idea as RTK from Chapter 3, wired into the agent's lifecycle: shrink the output at the source, so the window never holds the noise. Other useful events: SessionStart (seed context when a session begins), PreCompact (act just before a compaction), InstructionsLoaded (log exactly which instruction files loaded, for debugging the CLAUDE.md hierarchy), and UserPromptSubmit (inspect or augment each prompt).

The second use is enforcement: a PreToolUse hook can block an action outright, which is how you make "never touch src/billing/ without review" a hard rule rather than a hope. That is the job CLAUDE.md cannot do.

MCP servers and tool deferral

An MCP server (Model Context Protocol) is an external program that exposes extra tools to the agent, registered with claude mcp add <name> -- <command> at one of three scopes: local (just you, this project), project (committed in .mcp.json, shared with the team), or user (you, every project). This is how the memory servers in Chapter 9 and the lean-ctx context server in Chapter 5 attach.

The context cost is the catch. Every tool a server exposes has a schema, and schemas live in the window. Claude Code mitigates this with tool-search deferral: by default only tool names are present, and a tool's full schema loads only when the model reaches for it. Still, the official guidance is to prefer a plain CLI tool (gh, aws, gcloud) run through Bash when one exists, because it adds zero per-tool listing, and to run /mcp to disable servers you are not using. /context shows you exactly what your connected servers are costing.

Subagents: isolated context on demand

A subagent is a second instance of the model running in its own separate context window. The main agent spawns one with the Task tool, hands it a focused objective, and receives back only its final summary, not its internal reasoning or the raw output it processed. The verbose middle, the full test log, the directory dump, the long doc page, lives and dies in the subagent's window and never enters yours.

This is the orchestration lever in its most useful form, and three properties make it powerful:

• Isolation. A 3,000-token log read by a subagent costs your main window one summary line.
• Parallelism. The main agent can spawn several subagents at once (research three options, scan three directories) and collect their summaries, instead of doing the work serially in one window.
• Cheap models for cheap work. A subagent can run on a smaller model (model: haiku in its configuration) when the sub-job does not need the main model's depth.

Subagents are defined in .claude/agents/, can be given inline with --agents, and can keep their own persistent memory. The Explore subagent in plan mode is the canonical "look without polluting the main context" pattern. The cost to respect: each subagent is a full instance with its own window, so a wide fan-out multiplies tokens. Delegate verbose reads; do not spawn an army for work one window could do.

What goes where

Here is the judgment that ties the six surfaces together. When you have something you want Claude to know or do, this table says where it belongs, and why.

Don't be confused. CLAUDE.md, a rule, a skill, and a hook can all hold "instructions," but they differ on when they load and whether they are enforced. CLAUDE.md and unscoped rules load always (advisory). Path-scoped rules load when matching files are touched (advisory). Skills load when invoked (advisory). Hooks run at lifecycle events (enforced). Choosing the wrong one is how a window fills with instructions that only mattered once, or how an "always" rule quietly gets skipped.

Working habits of a specialist

The controls only pay off as habits. These are the ones that compound, and they are the same moves as the capstone workflow, now grounded in the exact commands.

• Two-tier your instructions. A thin, stable ~/.claude/CLAUDE.md for how you work; a focused ./CLAUDE.md for what this repo needs. Keep both small; push specifics to .claude/rules/ and procedures to skills.
• Watch the gauges. /context before you optimize, /usage when the bill climbs. Optionally put context usage in your status line so it is always visible.
• Keep the prefix stable. Do not edit CLAUDE.md mid-session unless you mean to; each edit forfeits the prompt cache until the prefix settles (Chapter 17).
• Compress at the source. A PreToolUse hook (or RTK) that filters test and log output is the highest-leverage token saving, because the noise never enters the window.
• Delegate verbose reads. Send the test run, the log scan, the doc fetch to a subagent. The cheapest token is the one that never enters the main window.
• Clear and compact deliberately. /clear between unrelated tasks, /compact with a focus instruction when a thread runs long, /rewind when a path goes wrong.
• Plan before large changes. Plan mode (Shift+Tab) spends tokens on a reviewed approach instead of on re-work.

Do these and a long, multi-project practice stays fast and cheap. Skip them and the symptoms are predictable: a bloated CLAUDE.md taxing every turn, a window full of stale tool output, a cache that never reads because the prefix keeps moving, and a bill that climbs for reasons /context would have shown you in a glance.

Further reading

• Claude Code, CLI reference (code.claude.com/docs/en/cli-reference): every flag, exact and current.
• Claude Code, commands and slash commands (code.claude.com/docs/en/commands): the in-session command set.
• Claude Code, hooks (code.claude.com/docs/en/hooks) and settings (code.claude.com/docs/en/settings): the enforcement and configuration layers.
• Claude Code, sub-agents (code.claude.com/docs/en/sub-agents) and MCP (code.claude.com/docs/en/mcp): delegation and external tools.
• Anthropic, "Building effective agents" (anthropic.com): the principles behind these mechanics.

Takeaways

• A specialist reaches for the right surface: CLAUDE.md (always-on facts), .claude/rules/ (path-scoped), skills (on-demand procedures), hooks (enforced and preprocessing), MCP or CLI (external tools), subagents (isolated verbose work), auto memory (learned facts).
• Know the two gauges (/context, /usage) and the session controls (/compact, /clear, /rewind, --continue, --resume) cold; they are how you see and steer the context.
• Settings are enforced and layered (managed beats flags beats local beats project beats user); CLAUDE.md is advisory. Enforce with permissions and hooks, advise with CLAUDE.md.
• Hooks that filter tool output at the source, and subagents that isolate verbose reads, are the two highest-leverage context savings in the tool.
• The "what goes where" table is the core judgment: match each piece of knowledge to the surface whose load timing and enforcement fit it.

👉 You know the controls; the next chapter is the practitioner's reality check: which of the popular token-saving tools actually pay off, how the savings are measured, where they backfire, and how to roll all of this out across a team. Continue to Field notes: what actually saves tokens.