What Anthropic teaches in this course
Claude Code in Action is a tour of the eight integration surfaces that take Claude Code from "a chat box that reads files" to "a build-time tool every engineer on the team uses the same way." The eight: /init and CLAUDE.md, @ file mentions, custom slash commands, MCP servers, GitHub integration, hooks (Pre and Post), the SDK, and the settings hierarchy that lets each layer be team-shared or personal. The course is short on theory and heavy on "here is the file you put it in". Treat it as an integration manual, not an introduction.
The CLAUDE.md hierarchy is the load-bearing primitive. Three locations: CLAUDE.md at repo root (committed, shared with the team), CLAUDE.local.md (gitignored, personal overrides), and ~/.claude/CLAUDE.md (user-global across every project). Claude reads all three on every request, layered. The /init command bootstraps the repo-root file by analyzing your codebase. The # memory-mode shortcut merges new instructions into the right tier without you opening the file. @file mentions inline file contents on demand, and you can put @-mentions inside CLAUDE.md so referenced files load on every turn.
Custom slash commands live in .claude/commands/<name>.md. The filename becomes the command, the body is the prompt, and $ARGUMENTS is the placeholder for whatever the user types after the command name. A write_tests.md file becomes /write_tests <path>. This is the cleanest way to encode a team's repeatable workflows; audit, ship, refactor, write_tests, lint-fix; without each engineer reinventing the prompt every time. Restart Claude Code after creating a new command file; discovery is at startup, not live. Personal commands live in ~/.claude/commands/ and shadow project commands of the same name, so each engineer can override a team-shared command locally without forking the file. The pattern matters: what slash commands are to ad-hoc prompting, custom commands are to your team's shared engineering vocabulary.
Hooks are where Claude Code stops being a chat assistant and becomes part of your build pipeline. PreToolUse runs before a tool is executed (matcher targets Read, Edit, Bash, etc.) and can block by exit code; PostToolUse runs after and can only react. Real uses: auto-format with Prettier on every Edit, run pnpm typecheck after Write, block reads from .env files, log every Bash call to a security audit trail. The hook is just a shell command receiving a JSON payload on stdin. Configuration lives in the same three-tier settings system (global, project, project-local) so you can ship team hooks via .claude/settings.json while letting each engineer add personal ones in .claude/settings.local.json.
MCP servers in Claude Code extend the tool surface beyond the built-ins. Claude Code is an MCP client; you point it at MCP servers via /mcp or settings JSON, and those servers expose their tools, resources, and prompts to the session. Install GitHub, Sentry, Postgres, Playwright, Linear, or Notion in one line of config and Claude can query and act against them. The gh CLI is often the simpler GitHub path: Claude Code calls gh directly through the Bash tool, no MCP wiring needed. The Claude Code GitHub Action lets the same harness run on PRs and issues from CI.
The Claude Code SDK is the same Claude Code, just runnable from your own scripts. The TypeScript and Python packages expose a query() async iterator; you give it a prompt, and it streams the same tool-call conversation you'd see in the terminal. Default permissions are read-only; the SDK can Read, Grep, Glob, Bash (read-only commands), but cannot Edit or Write unless you opt in via allowedTools. Use cases: pre-commit hooks that review diffs, CI checks that summarize changes, batch refactors that apply Claude Code across many repos, custom slash commands inside other tools.
The implicit thread through the whole course is the settings hierarchy. Three tiers (global at ~/.claude/settings.json, project-shared at .claude/settings.json committed, project-personal at .claude/settings.local.json gitignored) apply to MCP servers, hooks, custom commands, and permissions in exactly the same way. Think of .claude/settings.json as your team's contract for how Claude Code behaves in this repo, and .claude/settings.local.json as your personal overrides on top. The deeper layers shadow earlier ones, never silently. Once you see the pattern in one surface (hooks), you see it in all of them, and the course's eight topics collapse into one coherent integration model. The exam-relevant takeaway: Claude Code is not a chat box; it is a configurable harness whose every surface obeys the same three-tier hierarchy, and an architect designing rollout strategy works at that meta-layer rather than at any single surface.
You'll walk away with
- How /init bootstraps a project and where the three CLAUDE.md tiers live (project, local, user-global)
- How to author custom slash commands in .claude/commands/ and pass arguments via $ARGUMENTS
- How PreToolUse and PostToolUse hooks insert before or after tool execution, and what each can or cannot block
- How to wire MCP servers into Claude Code and when to reach for the gh CLI for GitHub workflows
- How the Claude Code SDK runs the same Claude Code programmatically from TypeScript, Python, or the CLI
21 lessons, with our annotations
6 ideas to carry into practice
Lines worth keeping
PostToolUse: format on Edit
Match Write|Edit|MultiEdit and run prettier --write or ruff format on the changed file. Removes the entire "Claude wrote ugly code" class of complaints in one config block.
Related concept →PostToolUse: typecheck on Edit
Run pnpm typecheck or mypy after edits; the hook can echo errors back to Claude as feedback. Claude self-corrects without the user mediating.
Related concept →PreToolUse: block .env reads
Match Read and reject any path matching .env* with a non-zero exit. Never trust prompt-only constraints when you have a hook contract you can enforce.
Related concept →PreToolUse: log every Bash
Match Bash and append the command + cwd to an audit log before letting it run. Cheap forensics for any "what did Claude do?" investigation.
Related concept →Notification hook on Stop
Match the Stop event and play a sound or send a webhook so you know when a long task finishes. Removes the "is it still running?" tab-switching tax.
Related concept →Project commands
The exact dev, build, test, typecheck, lint commands. Claude defaults to npm if you don't tell it you use pnpm/yarn/bun.
Related concept →Architecture sketch
A 5-10 line description of the app's shape: frontend, backend, database, auth, deploy target. Saves Claude from grepping the same files every session.
Related concept →House rules
"Never edit db/migrations/", "Use Tailwind utilities, not CSS modules", "Run typecheck before claiming done". Concrete rules, not platitudes.
Related concept →How this course shows up on the exam
Direct prep for D3 task statements on Claude Code workflow integration: CLAUDE.md hierarchy, custom slash commands, hooks, MCP servers in Claude Code, GitHub Actions, and the Claude Code SDK. Also reinforces D1 agentic-loop framing and D2 tool whitelisting.
Blueprint weight20% (D3) + spillover into D1, D2Check the pattern
Cross-task context like a vendor matrix path should live in: project Instructions or session messages?
Frequently asked
What is the difference between CLAUDE.md, CLAUDE.local.md, and the user-global CLAUDE.md?
Three tiers, all read on every request. CLAUDE.md at repo root is committed and shared with the whole team; put project commands, architecture, house rules here. CLAUDE.local.md is gitignored and holds your personal overrides for this repo. ~/.claude/CLAUDE.md is user-global and applies across every project on your machine. Claude layers all three; later tiers do not overwrite earlier ones, they accumulate.
How do I create a custom slash command in Claude Code?
Create .claude/commands/<name>.md in your repo. The filename becomes the command (audit.md → /audit), the body of the file is the prompt Claude runs when invoked, and $ARGUMENTS is the placeholder substituted with whatever the user types after the command name. Restart Claude Code after creating the file; discovery happens at startup, not live.
Can a PostToolUse hook block a tool call from running?
No. Only PreToolUse hooks can block; they run before the tool executes and a non-zero exit code rejects the call. PostToolUse runs after the tool has already executed, so it can only react: format the file, run tests, log to an audit trail, or echo feedback back to Claude. If you need to enforce something, use PreToolUse.
Why does my custom slash command show up in /help but doesn't run?
Most likely you forgot to restart Claude Code after creating or editing the file. Discovery happens at startup, not live. Other common causes: the file is in the wrong directory (must be .claude/commands/, not .claude/command/ or commands/), or the filename has spaces or uppercase letters that are getting stripped. Use lowercase-hyphenated names.
Do I need MCP to integrate Claude Code with GitHub?
No, the simplest path is the gh CLI. Claude Code can call gh directly through its Bash tool; no MCP wiring needed for issues, PRs, comments, or repo operations. Use the GitHub MCP server when you want stricter tool boundaries, structured outputs, or features the CLI doesn't expose. Use the official Claude Code GitHub Action when you want Claude to run on PRs and issues from CI.
Is the Claude Code SDK the same thing as the Anthropic Messages API?
No. The Anthropic Messages API is the raw messages.create() endpoint; you build the agent loop yourself. The Claude Code SDK wraps the *full Claude Code harness*; same tools, same agentic loop, same MCP servers, same CLAUDE.md reading; and exposes it as a query() function in TypeScript or Python. Use the SDK when you want Claude Code's capabilities programmatically; use the raw API when you're building a different harness from scratch.
What does /init actually do when I run it in a new project?
Claude Code analyzes the codebase; reads the package manifest, samples key directories, checks for tests, infers the framework; and writes a starter CLAUDE.md at the repo root summarizing the project's purpose, architecture, key commands, and important files. Treat the output as a draft, not the final; almost every team rewrites it after the first week as they learn what Claude actually needs to know.
Are hooks safe? Can a hostile prompt make Claude run a destructive shell command via a hook?
Hooks run as your shell user with full filesystem and network permissions; that's by design. Claude does not invoke hooks; the harness does, on tool events Claude triggers. The risk is your own hook logic: a Bash hook that pipes the command into a shell evaluator without sanitization is dangerous. Treat hooks like cron jobs you wrote: review them, scope tightly, and never accept hook configs from untrusted sources.