Set up Claude Code one layer at a time.
What to build first, what each layer guarantees, and the answers that hold up when someone who knows the product asks a follow-up. Pictures first, then the detail, then a quiz to check it stuck.
CLAUDE.md asks. Skills teach. Hooks enforce.
Start at the bottom and climb only when the layer below stops being enough. Each rung trades a little more setup for a little more certainty. Pick one.
CLAUDE.md
Instructions you write once and Claude reads at the start of every session: build commands, conventions, house rules.
Day one. It is the cheapest layer and pays off first.
All of it, every session
/init reads the codebase and writes a first draft for you.
Claude usually follows it. Usually.
It is guidance, not enforcement. And all of it loads every session, so a bloated file costs tokens and dilutes the rules that matter.
Auto memory
Notes Claude writes for itself when you correct it, loaded back at the start of the next session.
Early. Correct it once instead of every session.
Loaded every session
/memory opens your memory files and turns auto memory on or off.
Claude usually follows it. Usually.
Same as CLAUDE.md: it shapes behavior, it does not guarantee it.
Skills
A folder with a SKILL.md: a short description that says when to use it, and instructions Claude follows when it does.
The third time you explain the same process.
Only the description, until it is used
/skills lists what you have. Type /name to run one, or let Claude pick it when a request fits.
Claude usually follows it. Usually.
A skill is still guidance. A rule that must always hold belongs in a hook, which a skill or plugin can carry.
MCP servers
Connections to your other systems (issue trackers, databases, internal APIs) through the open Model Context Protocol.
When you keep pasting data in from another system by hand.
Tool names only, with tool search
claude mcp add, then /mcp to sign in and check each server.
Grants reach, not rules.
Every server is a trust decision: code you did not write, handing Claude text other people wrote.
Permissions and sandbox
Rules that allow, ask about or deny specific actions, plus an OS-level sandbox around every shell command.
Before you let it run with fewer approval prompts.
None
/permissions to see and edit rules, /sandbox to turn the sandbox on.
Limits what can happen at all.
A Bash rule matches the text of a command, so bash -c slips past it. The sandbox is the hard boundary.
Hooks
Commands Claude Code itself runs at fixed points: before a tool call, after one, when Claude stops. Exit code 2 blocks the action.
When a CLAUDE.md rule gets broken twice. That is the promotion path.
None, unless it prints to Claude
/hooks shows every hook that is configured and where it came from.
Runs every time, whatever the model decides.
Exit 1 is only a warning. A hook enforces only if it blocks with exit 2 and is set to block when it breaks.
Six real requests. Pick where each one belongs.
Claude keeps forgetting which command runs the tests.
Type a slash command, land on the module.
No command matches. Try a word like "cost" or "review".
Sixteen modules in four phases.
Each phase builds on the one before it. The ring on each module fills as you get its quiz cards right.
Foundations
What a customer asks in week one.
Control
What Claude may do, and what makes it stop.
Working at scale
Cost, safety nets, parallel work and automation.
Enterprise
Rolling it out to a whole organization.
Progress is saved in this browser only.