Learning objectives

By the end of this chapter, you will be able to:

1. Pick the right authentication path for Claude Code (API key, subscription, or third-party cloud) and explain how each is billed and monitored.
2. Drive Claude Code with the everyday slash commands — `/clear`, `/compact`, `/config`, `/usage`, `/hooks`, `/memory`, `/init`, `/rewind`, `/agents`, `/mcp` — and place each setting in the right scope (managed / user / project / local).
3. Build a hook end to end: pick the event, write the handler, register it in `settings.json`, and signal a block with exit code 2 — and explain why hooks are *not* a security boundary.
4. Lay out a CLAUDE.md across the five memory tiers (managed → user → project → rules → local) plus the new auto-memory subsystem, and decide where each kind of instruction belongs.
5. Use `/rewind` (and `Esc Esc`) deliberately — pick between the five restore/summarize actions, and explain what checkpoints capture and what they don't.
6. Author a custom slash command as a Skill — write SKILL.md with frontmatter, scope it with `allowed-tools`, and pass dynamic context via `!`-injection — and explain why the modern Skills shape replaces the older `.claude/commands/` form.

Before we start — billing, hooks, checkpoints, and Skills in plain language

Skim this if you already know what a Claude subscription tier is, what a hook fires on, what a checkpoint is, and what a Skill is in Claude Code. If any of those four terms is fuzzy, read it first — every section below assumes them.

Billing modes. Claude Code costs money — either through a flat-rate Claude subscription (Pro / Max 5x / Max 20x), through pay-as-you-go Anthropic API tokens, or through a third-party cloud (AWS Bedrock, Google Cloud Vertex AI, Microsoft Foundry on Azure). The model is the same; the bill goes to a different place.

A hook is a short script Claude Code runs automatically at specific lifecycle moments — before a tool runs, after a tool runs, when a notification fires, when the user hits enter, when Claude is about to finish answering, and many more. You write a hook once and it runs on every matching event, hands-free.

A checkpoint is a snapshot of your files that Claude Code takes silently before every edit it makes. The /rewind command opens the timeline of those snapshots and lets you jump back — undo the code, undo the conversation, or both. It's local, short-term, and not a replacement for git.

A Skill is a small directory under .claude/skills/<name>/ with a SKILL.md file in it. The SKILL.md has YAML frontmatter on top (name, description, which tools the skill can use) and a prompt body below. From the user's side, a Skill looks like a custom slash command — type /<name> and it runs. From Claude's side, a Skill is a packaged instruction the agent can also invoke on its own when relevant. The older .claude/commands/*.md form still works; Skills are the forward-looking shape.

Why this chapter matters

Chapter 1 was the theory — context engineering and the four strategies. Chapter 2 was the startup pass — CLAUDE.md, permissions, MCP, plan mode. Chapter 3 is the daily operating surface: the commands you type, the hooks that run silently, the memory you accumulate, the undo button you reach for when an edit went wrong, and the Skills you build to package your own repeatable workflows. By the end of this chapter, the rest of the course doesn't have to keep stopping to teach you commands — you'll have them in your hands.

Lesson

1. Pricing, plans, and authentication

Before you do anything else, decide how you'll pay for Claude Code. The choice is consequential, because it determines how you monitor cost and what happens when you hit a limit.

There are three documented paths.

Option A — Anthropic API key (pay as you go). You authenticate Claude Code with an API key from the Anthropic console. Every token you consume is billed at standard API rates. This is the most flexible mode — useful for evaluating Claude Code before committing to a subscription, for shared / CI / batch use cases where a personal subscription wouldn't fit, and for organisations that already centralise billing in the Anthropic console. Two costs to plan for: (1) API keys are credentials. If they leak — committed to a repo, posted in a screenshot, pasted into the wrong chat — someone else can spend on your account. (2) Agentic workflows can fan out fast. If a misconfigured hook spawns sub-agents in a loop, the bill grows in minutes. Mitigate both by setting spending limits in the Anthropic console (https://platform.claude.com/settings/limits) so the API refuses requests past your ceiling, and by rotating keys at the first sign of trouble.

Option B — Claude subscription (Pro / Max 5x / Max 20x). You connect your existing Claude subscription to Claude Code. As of writing, the public tiers are:

Usage limits apply by session window (typically a 5-hour rolling window with a daily cap), so heavy days can still hit a ceiling. Anthropic now offers usage credits: once you've used your subscription quota, you can opt into continuing at standard API rates instead of being cut off mid-flow. This is the option used throughout the rest of this course. Verify current pricing at https://claude.com/pricing — these numbers move.

Option C — Third-party cloud (Bedrock / Vertex AI / Microsoft Foundry). Claude Code can be authenticated through Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry (Anthropic's current name for the Azure-hosted path — enabled with CLAUDE_CODE_USE_FOUNDRY=1 plus ANTHROPIC_FOUNDRY_RESOURCE). Billing and audit live with the cloud provider; the model is still served by Anthropic. This is the path most large enterprises take — centralised cost, region-specific deployment, and the cloud's existing compliance framing all in one place. The Foundry flow is documented at https://code.claude.com/docs/en/microsoft-foundry; Bedrock and Vertex setup at https://code.claude.com/docs/en/third-party-integrations.

Monitoring usage from inside Claude Code

The book introduces /cost as the API-key usage monitor. Current docs make it explicit: /cost and /stats are now aliases for /usage — they all open the same panel. Useful flags worth knowing:

• /usage — opens the usage panel for whichever auth mode you're in. On API-key mode it shows token counts and dollar cost; on subscription mode it shows session-window usage against your plan limit.
• /model — switches the active model for the current session. Run with no argument (/model) to open the model picker, or pass a model name (/model sonnet, /model opus, /model haiku) to switch directly.

A quick mental model for which model to reach for:

• Sonnet is the default coding workhorse. Most edits, refactors, and tool-using work go here. 200K context.
• Opus is the heavy-reasoning model. Reach for it on hard planning, multi-step research, or when a long agentic task keeps going off the rails on smaller models — but expect higher token cost.
• Haiku is the fast, lightweight option for short tasks, formatters, lint-style work, and high-frequency hooks where latency matters more than depth.

Analogy — three ways to buy electricity for the workshop An API key is the smart meter — you pay per kilowatt, and a bad wiring job lights up the bill fast. A subscription is the flat-rate utility plan — predictable monthly cost, with a ceiling that resets each cycle. A third-party cloud is a wholesale industrial contract — the electrons are the same, but the meter, the audit, and the bill all sit with your provider, who already handles ten other utilities for you.

2. Controlling Claude Code with slash commands

Slash commands are the steering wheel. Type / at the prompt and Claude Code shows the list. The chapter focuses on the eight or so you'll use constantly — but it's worth knowing the surface area is wider. Current docs publish dozens of commands, including:

Two commands that older write-ups still mention have been removed: /vim (replaced by Editor mode under /config) and /pr-comments (just ask Claude directly to fetch PR comments). If a tutorial tells you to type one of those, the tutorial is stale.

A useful day-to-day pattern: when a conversation has wandered far enough that /clear would lose too much state but the context window is getting full, reach for /compact first. When the conversation is just wrong — wrong file open, wrong branch, wrong assumption — /clear is faster than steering it back.

The four-tier settings hierarchy

The chapter introduces the three-level configuration system (user / project / local). Current docs name a fourth tier and define a precedence the chapter doesn't:

Precedence (highest to lowest): Managed → command-line args → Local → Project → User. Managed wins; user loses ties.

There is one exception worth memorising: permission rules merge across scopes rather than override. If user-level allows Bash(npm:*) and project-level allows Bash(pytest:*), the session gets both. For every other setting, more-specific overrides less-specific.

Claude Code also hot-reloads these files. Edit settings.json in your editor and the changes take effect on the next prompt — no need to restart. Two exceptions: model and outputStyle require a session restart. Claude Code keeps the five most recent versions of each settings file as auto-backups, which is the friend you didn't know you had the first time you save invalid JSON.

For schema autocomplete in VS Code / Cursor, drop this on the first line of your settings file:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": { ... }
}

IDE integration — one extension, two editors

The book demonstrates Claude Code inside Cursor. In current docs, the same anthropic.claude-code extension serves both VS Code and Cursor (and most other VS Code forks, distributed via Open VSX). You don't pick a separate Cursor variant — the install URL is just different (vscode:extension/anthropic.claude-code vs cursor:extension/anthropic.claude-code).

A few practical IDE niceties:

• Cmd+Esc / Ctrl+Esc toggles keyboard focus between the editor and the Claude Code panel. This is the single shortcut most worth committing to muscle memory.
• Selection is context. Whatever's highlighted in the editor is silently included in Claude's next prompt. The eye-slash icon hides selection if you don't want it sent.
• @-mentions autocomplete. Typing @app.ts#5-10 injects that specific file range as context, the same way @filename works inside the CLI.
• Diff view. Every proposed edit appears in a side-by-side diff before it lands. You can edit the proposed file in the diff view before approving, and Claude is told you modified the proposal.
• Built-in IDE MCP server. The extension exposes a small, hidden MCP server named ide to Claude that exposes exactly two tools: mcp__ide__getDiagnostics (read editor errors / warnings) and mcp__ide__executeCode (run code in an open Jupyter kernel, gated behind a per-call confirmation). The server binds to 127.0.0.1 on a random port — it's not reachable from other machines.

If you started Claude Code in an external terminal, run /ide from inside the CLI to connect it to an open VS Code or Cursor window.

Analogy — the control panel and the wall plates Slash commands are the control panel on the dashboard — the dials and buttons you press during the drive. The settings hierarchy is the wiring behind the wall: managed wiring laid by the building owner, user wiring you ran through every room you live in, project wiring specific to one room, and a local toggle on the wall for tonight only. The dashboard buttons feel like the whole story while you're driving; the wiring is what makes them mean different things in different rooms.

3. Hooks — automation that fires on its own

A hook is a small script Claude Code runs automatically at a specific lifecycle moment. The book lists five event types. Current docs list many more — same shape, much wider surface area. Here are the events you'll reach for first:

The remaining events cover worktrees, MCP elicitations, configuration changes, file changes, permission requests, and more. The full reference lives at https://code.claude.com/docs/en/hooks.

The "play a sound on Stop" hook — start to finish

The chapter walks through configuring a Stop hook that plays a sound whenever Claude finishes responding. The build, end to end:

1. Write the handler. A small Python script (or any executable) that plays an audio file. The book uses uv + pygame; for a one-off, afplay sound.wav (macOS) or aplay sound.wav (Linux) is faster — no Python runtime to spin up.
2. Decide where it lives. Inside the project repo (so the team gets it) or in ~/.claude/hooks/ (so only you do). Project-scoped means it lands in .claude/settings.json; user-scoped lands in ~/.claude/settings.json.
3. Pick the event. Stop for notification-style hooks. PostToolUse if you only want it when Claude edited a file.
4. Register it. Run /hooks, choose the event, choose the matcher ("" matches everything), paste the command. The resulting JSON looks like:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "uv run /abs/path/to/play_sound.py" }
        ]
      }
    ]
  }
}

1. Reload. Hooks are picked up on the next prompt — no restart needed for most edits. (Whole-process restart still needed if you change model or outputStyle.)

Two things the book doesn't say, and you really want to know

(1) Exit code 2 blocks. Exit code 1 doesn't. This is the single most-missed detail about hooks. If your hook is supposed to stop an action — "no, don't write to .env" — it must exit with code 2. Exit 1 is treated as a non-blocking error and Claude proceeds anyway. Anthropic's docs are blunt: "If your hook is meant to enforce a policy, use exit 2."

(2) Hooks are not a security boundary. A hook can warn, log, slow Claude down, even refuse most of the time — but a determined or confused agent can route around a flaky hook. For hard "this must never happen" rules — block writes to .env, block reads outside the repo — use the permission system (project-level deny rules in .claude/settings.json). Hooks are great at "make formatting consistent" and "tell Slack when something interesting happened." They're the wrong tool for "stop a leak."

Hooks for high-frequency events deserve to be lightweight

A PreToolUse hook fires on every tool call. A Python script that loads a 200ms-startup dependency tree on every call will make Claude feel sluggish across the entire session. For high-frequency hooks prefer a one-line shell command, a compiled binary, or — if it must be Python — keep imports thin and avoid heavy frameworks. For the once-per-turn Stop hook, the cost barely matters; for PreToolUse, it does.

Analogy — the safety interlocks on a workshop press A workshop press has interlocks: a light beam that stops the ram if someone reaches in, a chime that fires when a cycle ends, a stamp that logs every press to the maintenance book. None of those interlocks is the purpose of the press — but without them the press is dangerous and the shift runs blind. Hooks are the interlocks. They're not what Claude does for you; they're what makes you trust Claude to do it for you.

4. Memory — CLAUDE.md, the tier ladder, and auto-memory

You already met memory in Chapter 1 (as the Write strategy) and Chapter 2 (the four startup moves). This chapter promotes it from a concept to a system with concrete tiers, a documented load order, and a second subsystem the older chapters didn't mention.

The five tiers (and what each is for)

Claude Code walks upward from your working directory toward the filesystem root, picking up every CLAUDE.md and CLAUDE.local.md along the way. The walk never visits siblings. Memory files inside subdirectories below your launch point are loaded lazily — only when Claude actually reads a file in that subtree.

Two practical details current docs make explicit:

• Imports cap at 4 hops. @path/to/file import syntax is recursive, but the resolver gives up after four levels of indirection — to avoid memory files quietly fanning out into a huge import graph.
• Target under 200 lines per CLAUDE.md. Anthropic's own guidance. CLAUDE.md content is loaded into context on every session start, so size has a direct cost in tokens and attention.

Auto-memory — the second subsystem

Claude Code v2.1.59+ ships a second memory subsystem the book doesn't cover: auto-memory. These are notes Claude writes on your behalf (when you ask it to "remember X"), stored under ~/.claude/projects/<project>/memory/. Three things to know:

• Index file. MEMORY.md is the per-project index. Only the first 200 lines (or 25 KB) of this file load at session start.
• Topic files. Linked from MEMORY.md, loaded on demand when the topic is relevant.
• Toggle. Use /memory to inspect what's loaded and turn auto-memory on or off. Disable globally by setting the environment variable CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

You don't have to choose between writer-authored CLAUDE.md and Claude-authored auto-memory — they coexist. The pragmatic split: rules and conventions belong in CLAUDE.md (you wrote them, the team committed them). Working notes ("the user prefers tables to bullets in standups", "we tried switching to Pydantic v3 last week and reverted") belong in auto-memory.

Three ways to add a memory entry

1. The # shortcut. At the Claude Code prompt, start your line with # and Claude writes the rest of the line into the appropriate memory file. Quick to add a rule mid-session.
2. Natural language to Claude. Say "remember that I prefer pytest in this project" or "add this rule to CLAUDE.md: …". The first lands in auto-memory; the second proposes an edit to CLAUDE.md you approve.
3. /memory directly. Opens the memory file in your editor. Use this for larger edits — multiple rules at once, restructuring sections.

/init — bootstrapping a CLAUDE.md from an existing repo

/init scans the repository, infers stack and structure, and proposes a starter CLAUDE.md. In v2.1+ with CLAUDE_CODE_NEW_INIT=1 set, /init runs an interactive multi-phase flow that proposes CLAUDE.md and relevant hooks and a starter set of Skills before writing anything. For new projects, run /init once, review the proposal carefully, and then edit it down by hand — the auto-generated version is a starting point, not the final shape.

Analogy — the workshop's notebooks The shop has notebooks at four heights on the wall. The top notebook is the shop owner's — house rules nobody overrides (managed). Below it, your personal notebook of preferences (user). Below that, the project notebook everyone working on this build reads (project). Tucked into the project notebook are sticker-flagged pages for specific stations — the lathe page, the welder page (rules). Pinned next to the bench is your sticky note for tonight only (local). The shop's apprentice — that's Claude — reads from the top down every morning and quietly takes notes of its own in a side pad (auto-memory). All of them coexist. None of them lies. The trick is putting each fact at the right height.

5. Rewind and checkpointing — Claude's local undo

Every time Claude Code edits a file, it takes a snapshot first. Every user prompt creates a new checkpoint. Type /rewind (or its aliases /checkpoint and /undo) to see the timeline and jump back.

A subtle keyboard detail: Esc twice opens the rewind menu only when the prompt input is empty. If you've started typing and you double-press Esc, Claude Code interprets it as "clear what I typed and save it to input history" — a different feature. Click the prompt, make sure it's empty, then Esc Esc.

Five actions per checkpoint — not three

The book lists three restore options. Current docs list five:

The two summarize actions are recent additions the book doesn't cover — they're a finer-grained variant of /compact.

What checkpoints don't capture

This is where learners get burned. Checkpoints track file edits made by Claude's file-editing tools (Write, Edit, MultiEdit). They do not track:

• Bash side effects. If Claude runs rm or npm install or git reset --hard or anything else through the Bash tool, those effects are not in any checkpoint and cannot be rewound. Be vocal about denying destructive bash by default in your .claude/settings.json permissions.
• Files edited outside Claude Code. If you opened a file in VS Code and saved it manually between two Claude turns, that save is not in the checkpoint timeline.
• Anything beyond ~30 days. Checkpoints retain by default for 30 days (configurable). They're a local short-term safety net.

The headline from Anthropic's docs is worth quoting verbatim: "Think of checkpoints as 'local undo' and Git as 'permanent history'."

CAIR — and a name correction

The book ties rewind to a metric it calls "Cost of AI Recovery (CAIR)". The canonical post — Assaf Elovic and Harrison Chase, mid-2025 — defines the same acronym slightly differently: CAIR = Confidence in AI Results, with the formula:

$$ \text{CAIR} = \frac{\text{Value}}{\text{Risk} \times \text{Correction}} $$

• Value — what you gain when the AI is right.
• Risk — what you lose when it's wrong.
• Correction — the effort it takes to detect and fix a mistake.

Rewind / checkpointing is a Correction-lowering mechanism. Lowering Correction raises CAIR, which raises adoption, even when Risk is fixed. The post's punchline: "When CAIR is high, users embrace AI features enthusiastically. When CAIR is low, adoption stalls no matter how technically impressive your AI is."

The book's "Cost of AI Recovery" reading is a fair summary of the Correction term — but the canonical name is Confidence in AI Results. Use the canonical name in conversation; the underlying argument is unchanged.

Analogy — the press-the-button undo on a workbench Imagine every cut you made on the bench got photographed and the photo got pinned to a board behind you. If you messed up a cut, you tapped the photo and the bench reset to that moment — the wood un-cut, the saw un-positioned. You'd take riskier cuts. You'd try things you'd normally not try. That is what rewind does for code work. It doesn't make you better with the saw. It makes you brave enough to try the cut.

6. Custom slash commands, now powered by Skills

The chapter's final section builds a custom /commit-code slash command — a small reusable bundle of instructions Claude runs when you type the name. In current docs, this surface has a new name: Skills.

What Skills are, and how they relate to the older form

Anthropic merged custom slash commands into Skills. The blunt summary from the docs: "Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way." Existing .claude/commands/*.md files keep working forever — but Skills are the recommended forward shape because they:

• Can include supporting files (helper scripts, templates, prompts).
• Have frontmatter that controls invocation, allowed tools, and dynamic context.
• Can be invoked by Claude itself when relevant — not only by the user typing /. Claude reads the description metadata, decides if the skill fits the current task, and uses it.

The Anthropic engineering post that introduced Skills calls this progressive disclosure and uses the metaphor of "a well-organized manual that starts with a table of contents". Three levels of loading:

1. Name + description are loaded into context at startup, so Claude knows what skills exist.
2. Full SKILL.md loads when Claude decides the skill is relevant — or when the user invokes it.
3. Linked files (scripts, templates) load only on demand.

This matters because a hundred skills in a project would otherwise eat the context window before you typed your first prompt. Progressive disclosure makes skills cheap to have lying around.

Anatomy of a SKILL.md

A minimal skill file:

---
description: Review changed files and write a concise commit message about the business logic.
---

Review the files that have changed and create a commit. The message should be short, concise, and summarise the business logic of the change.

The body is the prompt Claude runs when the skill is invoked. The frontmatter (between --- delimiters) configures invocation, scope, and tools. Fields worth knowing:

The combined description + when_to_use are truncated at 1,536 characters in the loaded metadata — keep them tight.

$ARGUMENTS and dynamic context injection

The book shows the $ARGUMENTS placeholder — the text that follows the skill name when invoked replaces $ARGUMENTS in the body. Type /commit-code custom code, and $ARGUMENTS becomes custom code in the prompt.

Current Skills add a more powerful trick: shell command injection at expansion time. Inside a SKILL.md body you can write:

## Context
- Current git status: !`git status`
- Current git diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

When the skill runs, each ` !command is executed before the prompt is sent to Claude — the output replaces the placeholder. Claude sees a fully-rendered prompt with real-time context. This is exactly the canonical commit-message skill from https://code.claude.com/docs/en/skills`:

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
description: Create a git commit
---

## Context
- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

## Your task
Based on the above changes, create a single git commit.

Two things make this safer than the naive /commit-code version:

1. allowed-tools pre-approves the tools this task actually needs. It's a grant list, not a restriction list — the listed tools run without a per-use permission prompt while the skill is active. So git add, git status, and git commit go through silently. Anything not in the list (a git push, an rm, arbitrary bash) is not pre-approved, so it falls back to the normal permission flow: Claude asks you before running it instead of running it silently. To hard-block tools rather than just gate them behind a prompt, use disallowed-tools in the SKILL.md frontmatter or permissions.deny rules in .claude/settings.json. allowed-tools and disallowed-tools / permissions.deny work together: the first narrows the silent-action surface; the second hard-refuses.
2. **The context is retrieved, not memorised.** The skill runs git status / git diff / git log fresh every time. Claude sees the current state of the repo, not a stale recollection.

That last move — retrieve fresh context every time — is structurally the same pattern as retrieval-augmented generation (RAG): pull relevant data into the prompt right before the model runs. The book makes this connection explicitly. RAG in a slash command.

Analogy — the workshop's jigs A jig is a small purpose-built fixture you use to make one specific cut perfectly, every time. The first time you cut a dovetail, you measured, marked, sawed, swore, and tried again. Then you built a jig — clamps, guides, a stop block — that produces a dovetail right the first time. Skills are jigs. Each one is a small fixture that runs a workflow you'd otherwise re-measure every time. allowed-tools is the pre-approved tool tray next to the jig — the tools the apprentice can pick up without asking, because they're already cleared for this cut. Other tools on the wall still exist; if the apprentice reaches for one, they have to call you over to ask first. (For tools you want to ban outright, lock that drawer with disallowed-tools or a settings deny rule.) The !-injection is the gauge that re-measures the wood every time you clamp it, instead of trusting your memory of yesterday's piece.

The whole chapter in one image — the workshop tour

Analogy — pedagogical summary, drawing on all six sections

Imagine Claude Code as a small, well-lit workshop. The first thing you decide is how you're paying for power. A subscription is your flat utility bill; an API key is a smart meter you watch nervously; a cloud provider is the wholesale industrial line your company already signed for.

Once the power's on, you stand at the control panel. The dials and buttons — /clear, /compact, /config, /usage, /hooks, /memory, /init, /rewind, /agents, /skills — are the slash commands. Behind the wall plates, the wiring is layered: managed building wiring, your house wiring, the wiring for this room, and a sticky note next to the switch for tonight only. The same button means different things depending on the wiring.

The press has safety interlocks: scripts that fire before a cut, after a cut, when the cycle ends, when a notification dings. Some of them log to the maintenance book. Some of them stop the press cold. The ones that stop the press exit with code 2 — code 1 is a non-blocking complaint Claude shrugs at. None of the interlocks is a security guard; for that you have a locked door (permissions).

The walls hold the workshop's notebooks, in five tiers. Shop owner's at the top, your personal one below, the project's notebook for the team, a clip of sticky pages for specific stations, and a pinned note for tonight only. The apprentice — Claude — reads them top-down every morning and quietly takes notes of its own on a side pad.

On the bench there's a camera that photographs every cut. If you don't like the result, tap the photo and the bench resets. The shutter doesn't reach the saw, the broom, or the wood you carried in from the hallway — those tools and edits happen off-camera. Use the camera for cuts. Use Git as your photo album.

And finally, the workshop has jigs: small purpose-built fixtures that produce one specific result perfectly, every time. Each jig knows which tools it's allowed to use and re-measures the wood every time you clamp it. Build them as you find yourself repeating a setup. Tell the apprentice when to reach for one; let the apprentice reach for one on its own when the work calls for it.

That's the workshop. The recipe (Chapter 1) tells you what to build. The setup (Chapter 2) gets the room ready. This chapter is the rest of the day in the shop.

Activity — Audit your .claude/ directory

Spend ten minutes on a project you already use Claude Code in:

1. Open ~/.claude/settings.json, <project>/.claude/settings.json, and <project>/.claude/settings.local.json (whichever exist).
2. For each rule / permission / hook entry, ask: does this belong in this tier? Personal preferences in project memory pollute the team's shared file. Project conventions in user memory drift between machines. Local tweaks accidentally committed go everywhere.
3. Open <project>/CLAUDE.md. Count the lines. If it's over 200, mark candidates to move to ./.claude/rules/<topic>.md files (path-scoped if relevant).
4. Run /memory inside Claude Code. Note any auto-memory entries that surprise you — they're notes Claude wrote about working with you. Decide which to promote to CLAUDE.md and which to leave informal.

Capture three concrete moves (e.g., "moved API endpoint preferences from project to user memory") in a note for yourself. Reuse them when you start your next project from scratch.

Stretch task

Pick one hook you'd like in your workflow but haven't built. Sketch it on paper before writing code:

• Which event does it fire on?
• Does it need to block an action, or only observe / log it? (If block: exit code 2. If observe: any non-zero is fine but exit 0 is conventional.)
• What's the right scope — user, project, or local?
• Could a permission rule do the same job more safely?

If the answer to the last question is "yes," prefer the permission rule. If it's "no" — e.g., you want to transform something, not just allow/deny — write the hook.

Practical exercise — Drive every surface in this chapter

~30–45 minutes. Hands-on. Bring a terminal, a text editor, and Claude Code installed. You'll work in a throwaway sandbox directory. Nothing in this exercise touches the training repo or any project you care about.

Setup (3 min)

mkdir -p ~/cct-ch3-exercise/.claude/skills/commit-summary
cd ~/cct-ch3-exercise
git init -q
echo "# Sandbox" > README.md
git add . && git commit -q -m "init"
claude

You should land at the Claude Code prompt inside ~/cct-ch3-exercise. Leave it open — every step below runs there or edits a file in your editor.

Step 1 — Settings & slash commands (5 min)

Goal: confirm the four-tier settings hierarchy and see hot-reload work.

1.1 Run inside Claude Code:

/usage

You'll see your current session usage / API cost. (If /usage opens nothing useful, try /cost.)

1.2 In your editor, create .claude/settings.json:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": ["Bash(rm -rf:*)", "Bash(git push:*)"]
  }
}

1.3 In Claude Code (no restart), type:

List the files in this directory.

Expected: Claude calls a tool like ls and answers. No prompt about the new permission rules — they hot-reloaded and weren't tripped.

1.4 Type:

Delete every file in this folder.

Expected: Claude refuses or proposes a much less destructive action, citing the rm -rf deny rule. The settings change took effect without a restart.

Reflection: which tier did your .claude/settings.json count as? (Project — committed to the repo if you git add it. Try renaming to .claude/settings.local.json to confirm the precedence rules don't change behaviour visibly here, since there's no conflict.)

Step 2 — Memory across tiers (7 min)

Goal: see project memory vs user memory vs auto-memory side by side.

2.1 Create CLAUDE.md in the sandbox:

# Sandbox Rules

- This project tracks decisions in `decisions.md` (create it if missing). Every new design decision gets a one-line entry there with today's date.
- Prefer pytest over unittest in any code we write.

2.2 In Claude Code:

What rules apply in this project?

Expected: Claude lists the rules from CLAUDE.md.

2.3 Add a personal preference via the # shortcut:

# I prefer concise commit messages — one line under 60 chars when possible.

When Claude asks which file to save it to, pick user memory (~/.claude/CLAUDE.md). Approve.

2.4 Try the auto-memory path. Ask Claude in natural language:

Remember that in this sandbox we never use the `os.system` Python API — it has security issues.

Claude should propose saving this to auto-memory under ~/.claude/projects/cct-ch3-exercise/memory/.

2.5 Run /memory. Expected: you see at least three files listed — ./CLAUDE.md (project), ~/.claude/CLAUDE.md (user), and an auto-memory file. Inspect each.

Reflection: which of the three rules you just added is the right fit for which tier? (Roughly: project-specific in CLAUDE.md, personal-cross-project in user memory, working-note-ish in auto-memory.)

Step 3 — Build a Stop hook (8 min)

Goal: wire a real hook, prove exit code 2 blocks vs exit code 1 doesn't.

3.1 In your editor, create hooks/say-done.sh in the sandbox:

#!/usr/bin/env bash
# Stop hook — print a marker so we can see it ran.
echo "[hook] Claude finished a turn at $(date -Iseconds)" >&2
exit 0

Make it executable:

chmod +x hooks/say-done.sh

3.2 In Claude Code, run /hooks. Choose Stop, leave matcher empty, set the command to the absolute path of say-done.sh. Save.

3.3 Type any prompt:

What time is it?

Expected: Claude answers, and somewhere in the visible output (or your terminal stderr) you see the [hook] Claude finished a turn at … line.

3.4 Edit say-done.sh to block the turn:

#!/usr/bin/env bash
echo "[hook] refusing to let this turn finish (test)" >&2
exit 2

Type another prompt. Expected: Claude doesn't get to finish — the hook's exit 2 signals stop. (Different Claude Code versions surface this differently; you may see the hook's stderr in the chat.)

3.5 Change exit 2 to exit 1 and try once more. Expected: the turn completes normally despite the non-zero exit. Exit 1 is non-blocking; exit 2 is blocking. This is the single most-missed detail about hooks.

3.6 Restore exit 0 and move on.

Reflection: in production you wouldn't use Stop to block — that's adversarial to the user. The realistic uses are PostToolUse for formatters / linters / tests, PreToolUse for safety checks, and UserPromptSubmit for prompt enrichment.

Step 4 — Use /rewind (5 min)

Goal: feel checkpoints in action. Confirm what they don't capture.

4.1 In Claude Code:

Create a file landing.md with a five-line product landing page for a fake company called "Bench".

Approve the edit.

4.2 Now:

Add an FAQ section to landing.md with three Q&A pairs.

Approve.

4.3 Now break it on purpose:

Add a footer with 200 lines of placeholder text to landing.md.

Approve. landing.md is now a mess.

4.4 Type /rewind. Find the prompt that added the 200-line footer. Pick Restore code. Open landing.md — the footer is gone, FAQ and main content are intact, and the conversation history is preserved, so you can ask:

Add a one-paragraph footer with just the company name and a copyright line.

…and Claude will know exactly what you mean from the conversation context.

4.5 Now do something checkpoints can't undo. In Claude Code:

Run: echo "destroyed by bash" > landing.md

Approve the bash run. landing.md is wrecked again — but try /rewind. Expected: the bash-mediated overwrite is not in the checkpoint timeline. You'd need git checkout landing.md (assuming the file was committed at any point) to recover.

Reflection: checkpoints catch edits made by Claude's file-editing tools. Bash side effects and your own editor saves are invisible to them. Plan accordingly — deny destructive bash by default, and use git for anything that has to outlive 30 days.

Step 5 — Build a Skill (10 min)

Goal: author a custom slash command as a Skill, scope it with allowed-tools, and pass dynamic context via !-injection.

5.1 In your editor, create .claude/skills/commit-summary/SKILL.md:

---
description: Summarize uncommitted changes in this repo as a candidate commit message.
allowed-tools:
  - Bash(git status:*)
  - Bash(git diff:*)
  - Bash(git log:*)
---

## Repo state

- Status: !`git status --short`
- Diff (last 200 lines): !`git diff HEAD | head -200`
- Recent commits: !`git log --oneline -5`

## Your task

Based on the repo state above, propose a single concise commit message (one line, under 60 chars).
Apply the user's commit-message preferences from memory.

If the user provided extra context, weigh it heavily:

$ARGUMENTS

5.2 The new skill should appear immediately — Claude Code watches the .claude/skills/ directory and picks up additions, edits, and removals in-session. If /commit-summary doesn't show up in the / menu, run /reload-skills. A full session restart is only needed if the .claude/skills/ directory itself didn't exist when the session started.

5.3 Make a change in the sandbox so there's something to summarise. In your editor, append a paragraph to landing.md. Don't commit.

5.4 Run the skill:

/commit-summary focus on the FAQ section if it changed

Expected: Claude executes the git status, git diff, and git log commands inline (you'll see them in the output), then proposes a commit message that takes both the repo state and your hint into account. Critically, the user-memory preference you set in Step 2.3 ("concise commit messages — one line under 60 chars") shapes the output.

5.5 See what allowed-tools does and doesn't do. In Claude Code:

Use the commit-summary skill again, but this time also push the commit to origin.

Expected: Claude runs the granted commands (git status, git diff, git log) silently — they're in allowed-tools. When it reaches git push, the tool is not in the allow list, so it falls back to the normal permission flow: Claude asks you whether to allow the push instead of running it silently. allowed-tools is a grant, not a fence. To make git push a hard refusal (no prompt at all), add either disallowed-tools: Bash(git push:*) to the SKILL.md frontmatter or a permissions.deny rule in .claude/settings.json.

Success checklist

• [ ] .claude/settings.json exists with permissions.deny rules; you saw hot-reload work.
• [ ] Three memory files visible under /memory: project CLAUDE.md, user ~/.claude/CLAUDE.md, and at least one auto-memory file.
• [ ] You saw exit code 2 block a turn and exit code 1 not block it.
• [ ] You used /rewind to undo a Claude file edit and saw that a bash-mediated edit was not recoverable via checkpoint.
• [ ] You created .claude/skills/commit-summary/SKILL.md with allowed-tools and dynamic !-injection, and ran it successfully.

What to record (for your own notes)

• The exact moment you saw exit code 1 vs 2 differ. This is the detail that catches everyone.
• Which CLAUDE.md tier a personal preference ended up in by default, and whether that surprised you.
• One thing you'd like Claude to do for you every time it finishes a turn — and whether a Stop hook, a PostToolUse hook, or a permission rule is the cleanest path to make it happen.

Common pitfalls - /rewind won't undo bash side effects. If you let Claude run a destructive shell command, the checkpoint doesn't have it. Git is your permanent history; checkpoints are local undo. - Exit 1 doesn't block. If your hook needs to stop Claude, it must exit 2. Exit 1 is a non-blocking error — Claude proceeds anyway. - Esc Esc only opens rewind when the prompt is empty. If you've started typing, double-Esc clears your input instead. Click the prompt to empty it first. - A new skill doesn't show up in /. Claude Code watches .claude/skills/ and picks up new, edited, and removed skills in-session. If a freshly-added skill is missing from the / menu, run /reload-skills. A full session restart is only needed when the .claude/skills/ directory itself didn't exist at session start. - Hooks are not security. A hook can warn, log, or refuse most of the time — but for hard "this must never happen" rules, use the permission system in .claude/settings.json, not a hook.

Knowledge check — try the quiz

Once you've worked through the lesson and the exercise, take the chapter quiz from the navigation bar. Six questions: five from the book chapter, one synthesis question grounded in the current Anthropic documentation. Passing score 5/6. You can retake the quiz as many times as you like.

Further reading & enrichment sources

• Anthropic docs — Settings (https://code.claude.com/docs/en/settings). Canonical reference for the four-tier configuration hierarchy, hot reload, and the permission-rule merge exception.
• Anthropic docs — Commands (https://code.claude.com/docs/en/commands). Full inventory of slash commands, aliases, and what's been removed (e.g. /vim, /pr-comments).
• Anthropic docs — Hooks (https://code.claude.com/docs/en/hooks). The full hook event catalogue (many more events than the book lists), exit-code semantics (2 blocks, 1 doesn't), and the official "use permissions for hard policy, not hooks" guidance.
• Anthropic docs — How Claude remembers your project (https://code.claude.com/docs/en/memory). The five-tier CLAUDE.md hierarchy, the auto-memory subsystem, @-imports (max 4 hops), and the under-200-lines guidance.
• Anthropic docs — Checkpointing (https://code.claude.com/docs/en/checkpointing). The five rewind actions, the Esc Esc-when-input-empty detail, and the explicit list of what checkpoints don't capture.
• Anthropic docs — Extend Claude with skills (https://code.claude.com/docs/en/skills). The Skills merger, SKILL.md frontmatter (especially allowed-tools as a grant that pre-approves tools without per-use prompts, and disallowed-tools for hard blocks), the canonical commit example with !-injection, and the live-watch behaviour of .claude/skills/ (with /reload-skills as the safety valve).
• Anthropic docs — Microsoft Foundry (https://code.claude.com/docs/en/microsoft-foundry). Current canonical name and setup (CLAUDE_CODE_USE_FOUNDRY=1, ANTHROPIC_FOUNDRY_RESOURCE, Entra ID or API key auth) for the Azure-hosted path.
• Anthropic docs — VS Code & Cursor extension (https://code.claude.com/docs/en/vs-code). One extension serves both editors; the Cmd/Ctrl+Esc focus toggle; the built-in ide MCP server.
• Anthropic engineering — Equipping agents for the real world with Agent Skills (https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills). Source of the "table-of-contents manual" progressive-disclosure metaphor.
• Anthropic engineering — Best practices for Claude Code (https://www.anthropic.com/engineering/claude-code-best-practices). Hooks-as-deterministic-verification framing; "actions that must happen every time with zero exceptions."
• Anthropic news — How Anthropic teams use Claude Code (https://www.anthropic.com/news/how-anthropic-teams-use-claude-code). Real internal patterns for CLAUDE.md bootstrapping and cross-functional adoption.
• Anthropic cookbook — Introduction to Claude Skills (https://platform.claude.com/cookbook/skills-notebooks-01-skills-introduction) and Building custom Skills (https://platform.claude.com/cookbook/skills-notebooks-03-skills-custom-development). Runnable notebooks for the API surface of Skills.
• Claude pricing page (https://claude.com/pricing). Verify current Pro / Max 5x / Max 20x prices before quoting them.
• LangChain — The Hidden Metric That Determines AI Product Success (https://blog.langchain.com/the-hidden-metric-that-determines-ai-product-success/). Elovic & Chase's CAIR = Confidence in AI Results — the correct expansion of the acronym the book cites; the formula Value / (Risk × Correction) is the lens through which to understand why rewind matters.