101 Claude Code Tips

1No check, no victory

The first answer is the most direct one: give Claude a way to check itself. The book gives a broad definition: "Anything Claude can run and read is verification" (module 6). An automated test is one. A type check verifies that every value has the type it claims: that's one too, and so is a screenshot to compare against a target. When no verification is possible, you shrink the task until you find one, or you don't delegate it.

The verification goes into the prompt itself. The book's template relies on bun, a JavaScript tool that runs the tests. Here it is, preceded by the bare prompt:

✗ BEFORE (my own example)
Add a rate limiter in src/limiter.ts.

✓ AFTER (the book's template)
After implementing the rate limiter in src/limiter.ts:
- Run `bun test src/limiter.test.ts` and confirm all tests pass.
- Run `bun run typecheck` and confirm zero new errors.

If verification fails, do not declare success. Try again.

Without that last line, the book says, "Claude will frequently produce a confident summary even when the verification step failed."

Two setups with two sessions reinforce this check. In the first, one session writes the change and a fresh one reviews the diff (the list of modified lines) without knowing the first one's reasoning. In the second, one session writes the test and the other writes the code that makes it pass.

2A fifty-line CLAUDE.md, mostly about what's off limits

Checking afterwards can't save a task that went the wrong way. Hence the second family of ideas: keep Claude inside the frame, starting with a file. CLAUDE.md is the file of standing instructions that Claude rereads at the start of every session. Bloated, it does the opposite of what you want. The book puts it this way: "Bloated CLAUDE.md files cause Claude to ignore actual instructions because the rules get lost in noise" (module 2). The book measures its size in tokens. A token is a chunk of a word, the unit the model counts and bills. The book's target: about 50 lines, under 1,000 tokens. Boris Cherny, who leads Claude Code at Anthropic, prunes his team's file with every new model version.

The book recommends two sections in it. The first sets the limits of the project: one line on what you do, several on what you don't:

## Project boundaries
**In scope:** slide deck generation, PDF export and local HTML
**Out of scope:**
- Authentication or user accounts
- Database or any persistent backend
- Real-time collaborative editing

Without this section, one vague word is enough to derail Claude. You write "improve the slide editor". But "improve" has no limit. According to the book, Claude can spend four hours adding user accounts that nobody asked for. With the section, user accounts are on the list of what you don't do. Claude knows not to touch them.

The second section is a list of facts about your machine. One line says, for example: "Python: not installed (don't look for it)". Claude reads that line. So it stops wasting time looking for a tool that isn't there.

3A hook guarantees what CLAUDE.md only hopes for

CLAUDE.md has a limit: it only holds instructions. Claude follows them most of the time, and nothing proves it followed them this time. It is the problem of the first idea: you only have its word. For an absolute rule, the book switches to hooks. A hook is a small script that Claude Code runs automatically before or after one of Claude's actions. It can refuse that action. The module 7 formula: "hooks guarantee execution; prompts do not."

# ✗ In CLAUDE.md: "Never run rm -rf or git push --force."
#   Claude often remembers, not always.

# ✓ The book's hook, run before every Bash command:
cmd=$(jq -r '.tool_input.command' <&0)          # jq reads the JSON: extracts the proposed command
if echo "$cmd" | grep -Eq '(rm -rf|git push --force|git reset --hard)'; then
  echo "Blocked dangerous pattern: $cmd" >&2    # message sent back to Claude
  exit 2                                        # code 2 = "refused"
fi
exit 0                                          # anything else: let it through

The script compares the command to a blocklist. If the command is on it, the script exits with code 2, the refusal signal. Claude then reads the message and can propose a safer variant. The book flags three pitfalls:

• A blocking hook must fire before the action, on the PreToolUse event. Wired to PostToolUse, which comes after the action, it is too late: the file is already written.
• Claude Code has a mode where it no longer asks for any confirmation, bypassPermissions. A hook that exits with code 2, the refusal in the script above, still blocks the action.
• Your terminal reads your .bashrc at startup. An echo in it gets appended to the hook's answer and breaks it. The fix checks that the shell is interactive:

if [[ $- == *i* ]]; then
  echo "Welcome back, $(whoami)"    # shown only in a human terminal
fi

4Ask Claude what it decided without you

A hook stops the actions you saw coming. But Claude also makes decisions you did not plan for, and it does not flag them.

The book suggests two questions. Before the code, you ask Claude for the list of all its assumptions. After the code, you ask for the list of decisions it made without being told. The second pays off most (module 5). Every implementation makes choices in silence. For example, Claude picks on its own:

• the library used;
• the error-handling style;
• where the new file goes;
• the name of the public API.

The fewer choices you leave open, the fewer there are to expose. The book goes the same way: "A short, constrained prompt outperforms a long, polished one with no scope." Here is a vague prompt, then the same prompt with constraints. Redis is an in-memory database: here, it keeps the login sessions.

✗ Add authentication to this app.

✓ Add email and password authentication using the existing user model,
  store sessions in Redis, introduce no new abstractions and change
  no existing route.
  If that's impossible without breaking these constraints, stop and explain why.

Each part of the prompt closes a choice. "With email and password" says what to build. "In Redis" says where to keep the state. "Change no existing route" says what does not move. The last sentence asks Claude to stop rather than decide alone.

Some words open every choice at once. The book warns against "refactor", "improve", "clean up" and "optimize" (tip 100): read literally, each one gives Claude permission to redesign the area it targets. "Refactor" is heard as "rethink this code": extracted helpers, renamed functions, new abstractions, sometimes new files. A small localized improvement is heard as a surgical edit. The book advises keeping the strong words for when you really mean them, and otherwise using a bounded vocabulary: "tighten", "rename", "extract this one helper".

✗ Refactor the slide generation logic.
   → helpers extracted, functions renamed, new abstractions, sometimes new files

✓ Make a small, localized improvement to the slide generation logic,
  without changing the structure.
   → a surgical touch-up of the existing code

5Chat is not proof

Back to the first family: do not take Claude at its word. What Claude writes is not proof. When you contradict it, it answers in the tone of a conversation. It agrees, then fixes, in smooth prose, whether the fix is right or not. The book says it: the model imitates the shape of agreement. So a "You're absolutely right!" proves nothing. The countermeasure is mechanical: read the diff rather than the answer. The book sums it up in one line: "The chat language is not load-bearing" (module 15). In other words, nothing should rest on what is written in the conversation.

Same trap with tests (tip 98). Claude can write "I ran bun test, all green" without ever calling the Bash tool, the one that actually executes a command. The text is fluent, plausible and wrong. The Ctrl+O shortcut opens the transcript: with no visible Bash call, there was no test. This check matters most in automated runs (-p mode, GitHub Actions), where nobody watches each call. The book asks to build the verification into the structure of the run.

6Clear the context, or it makes you pay

Back to the second family: keeping Claude inside the frame, this time during the session. Context is everything Claude has in front of it in the session: your messages, its answers, the files it read. "Stale context degrades performance," says module 14, hence three habits:

• /clear empties the context between two unrelated tasks, for example after an authentication overhaul, before a payment bug.
• /compact summarizes the conversation when the same task continues. The book pairs it with an instruction on what to keep, for example "focus on the refactoring plan and the failing tests".
• A handoff file, written before clearing the context and reread by the next session. On a long project, the book prefers it to /compact: Claude finds the exact state of the work there.

## Current task
Migrate `src/auth/` to the new sessionStore.
## Done
- `loginHandler` migrated, tests green.
## In progress
- Migrating `passwordResetHandler`, blocked on the recovery-token branch.
## Next steps
1. Resume the migration of `passwordResetHandler`.

These gestures empty a context that is already full. Subagents keep it from filling up in the first place. A subagent is a second Claude, launched separately, with a context of its own. Module 9 gives a rule: "if the task involves search results, log dumps, or file contents we will not reference again, run it in a subagent." The book's example: "find every place that uses this deprecated API" returns hundreds of lines. Those lines stay inside the subagent. It hands you back only a summary, and your own context stays light.