Claude Code in Action

This is what you actually type to Claude Code to make it plan before it touches any code. The > at the start of each line is just the prompt shown in the terminal — you type the words after it. The whole message is one instruction.

1. The first two lines state the goal precisely: extract the retry logic from api.py into a reusable decorator. A vague goal gets a vague plan.
2. "List the files you'll touch and the risks" asks Claude to show its thinking first so you can catch a bad idea before it happens.
3. "Do NOT write code yet — I'll approve the plan first" is the key line: it puts Claude in plan mode, so it explores and proposes but waits for your OK before editing.
4. The # comment underneath is a note for you, the reader — it explains that Claude will explore, propose, and pause. You approve or correct before any files change.

What the output means: Claude replies with a written plan (files, steps, risks) and then stops. Nothing on disk changes until you say go.

Try this: Whenever a task is bigger than a one-line fix, add "plan first, don't code yet" to your request. Reading a plan takes seconds; undoing twelve wrong edits does not.

CLAUDE.md is a plain text file you put in your project. Claude Code reads it automatically at the start of every session, so it's how you tell Claude the things you'd otherwise have to repeat every single time — your commands, your rules, your guardrails.

1. The ## Commands section lists how your project runs its test, lint, and start commands. Now Claude runs pytest -q instead of guessing.
2. ## Conventions encodes house style: Python 3.12, type hints, never edit vendor/, prefer the standard library. These stop Claude from writing code that doesn't fit your repo.
3. ## Guardrails are hard don't rules: don't commit or push unless asked; ask before deleting files or changing the database. These are the safety limits.
4. The headings (##) are Markdown — just a readable way to organize the file. Claude reads the whole thing as context, so clear, short bullets work best.

Try this: Add one line to the Conventions section for a rule you keep repeating to Claude. That one line means you never have to say it again — and everyone on your team gets it too.

This file (.claude/settings.json) is where you decide what Claude may do without stopping to ask you. It's JSON — a list of names and values in curly braces. Two lists do all the work: allow and deny.

1. "allow" lists safe actions Claude can take freely. Bash(pytest:*) means "any pytest command"; Read(*) means "read any file"; Edit(src/**) means "edit anything under src/". The * is a wildcard — it matches anything.
2. "deny" lists actions Claude must never do: Bash(rm -rf:*) (dangerous deletes), Bash(git push:*) (pushing code), and Edit(vendor/**) (editing generated files).
3. Anything not on either list falls through to "ask me first" — the safe default. You widen the allow-list as you learn which actions are safe.

What the output means: With this file in place, Claude runs tests and edits src/ without interrupting you, but stops and refuses to push or delete.

Try this: The next lab turns these exact rules into runnable code so you can see how a single action gets matched to ALLOW, DENY, or ASK.

This tiny Python program is the decision logic behind the allow/deny lists you just saw — written out so the rules are unambiguous. Given an action, it returns one of three answers: DENY, ALLOW, or ASK.

1. fnmatch is a standard-library tool that matches text against a wildcard pattern (so Bash(pytest*) matches Bash(pytest -q)). It's the same idea as the * in the settings file.
2. The function checks the deny list first: if any deny pattern matches, it returns DENY immediately. This is the "deny wins over allow" rule from the docstring.
3. Only if nothing denied it does it check allow → ALLOW. If neither list matches, it falls through to ASK — hand the decision to a human.
4. The for loop at the bottom runs five sample actions through decide() and prints the verdict for each, lined up in a neat column.

What the output means: Five lines: pytest and editing src/ are ALLOW; editing vendor/ and rm -rf / are DENY; the unknown curl command is ASK — exactly matching the settings you'd expect.

Try this: Add "Bash(curl*)" to the deny list and re-run. The curl line flips from ASK to DENY — proof that adding a deny rule tightens the gate.

The most important habit in agentic coding is verify, don't trust: an agent saying "done" proves nothing. This function turns "is this change acceptable?" into a clear yes/no with reasons, so you can't wave work through on vibes.

1. accept_change takes three facts about the change: did the tests pass, did you review the diff, and did it touch a forbidden path?
2. Each if adds a human-readable reason to the reasons list when something is wrong. No reasons means nothing is wrong.
3. It returns a pair: (not reasons) is True only when the reasons list is empty (accept it), plus the list of reasons so you know why if it was rejected.
4. The two print calls test it: one perfect change, one broken change (diff not reviewed and a forbidden path touched).

What the output means: The first line is (True, []) — accepted, no problems. The second is (False, ['diff not reviewed', 'touched a forbidden path']) — rejected, with the exact reasons spelled out.

Try this: Flip the first True to False (tests failing) and re-run — watch "tests not green" appear and the change get rejected. This is how you make "done" mean "actually verified".

A tech lead wants every engineer's Claude configured safely, not just their own. This function audits a repo's config and returns a list of problems — an automated check that the safety pieces are actually in place.

1. It's handed a cfg dictionary describing the repo's setup, and builds a problems list as it finds gaps.
2. The four checks map to the four safety habits from this chapter: is there a deny-list? is git push denied? is there a CLAUDE.md? is there a test-on-stop hook (automatic verification)?
3. Each missing piece appends a plain-English problem explaining the risk, e.g. "no CLAUDE.md -> conventions not shared".
4. It's run on two repos: a weak one (allow-everything, no CLAUDE.md) and a strong one that follows every rule.

What the output means: The weak repo prints a list of three problems; the strong repo prints compliant (its problem list was empty, so [] or "compliant" shows the word instead).

Try this: Delete one good setting from the strong dictionary (say remove stop_hook_tests) and re-run — that repo stops being "compliant" and the matching problem appears. That's the audit doing its job.