The chapter opens with a story. The author once told Claude Code to "help me optimize the styles on this page," meaning a few spacing and font tweaks. Claude refactored the entire CSS file, added unrequested "improvements," and destroyed a layout that took an afternoon to build. Rolling it back took half an hour.
Rephrased: "Change the heading font-size from 16px to 18px, and paragraph spacing from 10px to 14px. Only these two changes — don't touch anything else." Claude finished in 30 seconds. Perfect.
/clear, interviews, high effort) remove most day-to-day friction.src/components/UserWidget.tsx." A reference example beats ten lines of description./clear wipes context for a clean restart. /compact auto-compresses and is opaque and error-prone — the chapter warns against relying on it.The book distils the official Best Practices into three principles.
Do not say "add a login feature." Say:
Add Google OAuth login under src/auth/ using the Better Auth library,
following the pattern of the existing GitHub login implementation.Why: file paths, tech choices, and reference patterns each remove a guess Claude would otherwise have to make.
Look at how src/components/UserWidget.tsx is implemented,
then build a CalendarWidget the same way.Why: Claude reads code exceptionally well. Handing it a good example in your own codebase is far more effective than describing the style in words.
Users fail to log in after session timeout - please check the token refresh flow under src/auth/.Why: unless you have confirmed the cause, your diagnosis ("there's a problem with the token refresh logic") can send Claude down the wrong path. Claude can see all the code; let it find the root cause.
| Weak request | Strong request |
|---|---|
| Add a search feature | Add a search box to the navbar in src/components/Header.tsx, using Fuse.js for fuzzy search over the posts array, styled to match the existing FilterDropdown component |
| The API is throwing an error, take a look | POST /api/orders returns 500 when quantity > 100 — check the input validation and database write logic in src/api/orders.ts |
| Optimize performance | The homepage takes 4 seconds to load. The main bottleneck is the Dashboard component — it fetches all user data at once. Switch to pagination, 20 records per page |
Your intuition might be "the more I tell Claude, the better." The book says the opposite is true. Anthropic's engineering team found that too much context degrades model performance — it gets lost in the noise and starts making incoherent decisions.
Use the /context command to see how much of the context window is in use. In one monorepo
test cited in the book, just loading the base configuration in a fresh session consumed roughly
20k tokens, leaving about 180k for actual work.
| Technique | How / why |
|---|---|
@ file references | @src/utils/auth.ts points Claude at a specific file instead of making it search. |
| Paste screenshots | For UI issues, a screenshot is "ten times more accurate" than a text description. |
| Pipe data | cat error.log | claude feeds logs directly to Claude. |
| Share URLs | Claude can fetch web content — linking to API docs beats copy-pasting them. |
When you are about to build something substantial (the book's example: a payment system from scratch), do not start by writing a requirements document. Instead:
I want to build a payment feature. Before you start,
interview me and ask everything you need to know.Claude asks a series of questions: which payment methods? refunds? expected concurrency? webhook callbacks? which currencies? The book notes at least half of these will be things you had not considered — Claude just did the work of a requirements analyst.
Why a fresh session? The interview conversation has already accumulated a lot of history, consuming a large chunk of context. A new session that starts from a clean Spec lets Claude focus entirely on execution, without the noise of everything discussed along the way.
Many people only use Claude Code to write code. It is equally valuable for understanding a codebase. You can ask it directly:
useAuth hook?"src/lib/db.ts and src/utils/database.ts? Why do both exist?"Claude reads the relevant code and gives a structured explanation — faster than reading docs, more convenient than asking a colleague. The book says this is exactly how the Claude Code team onboards new members: they ask Claude Code rather than reading a pile of wikis, and its understanding is often more accurate than the outdated docs.
| Strategy | What it means |
|---|---|
| Tight feedback loops | Do not wait for 500 lines before checking. Correcting after 10 lines costs almost nothing; tearing down a finished feature wastes tokens and time. |
| Two corrections and still off? Start over | Stop correcting. Use /clear to wipe context and restart with a better initial prompt. Untangling a derailed conversation usually makes it worse. |
| Switch tasks, clear context | Finished a component and moving to a schema change? /clear. Different tasks have different context needs; old history is just noise. |
| Use a /catchup after /clear | Shrivu's approach: a custom /catchup command tells Claude to read the current git branch's changes to restore relevant context. |
| Use subagents for research | Delegate "figure out how this library works" or "analyze how competitors implement this" to a subagent. Findings return to the main session without the intermediate reasoning polluting your context. |
/compact
(auto-compression). It is opaque and error-prone. When you need to reset, use /clear, not /compact.Claude Code has four effort levels, controlling how much reasoning the model invests.
| Level | Best for | Characteristics |
|---|---|---|
| Low | Simple formatting, renaming | Fast, but prone to careless mistakes |
| Medium | Routine development tasks | Lighter than the default |
| High | Complex features, debugging | Default level — what Boris (Claude Code's creator) uses |
| Max | Extremely complex architectural decisions | Uncapped reasoning tokens — slowest and deepest |
High is already the default, and Boris never dials it down. The reasoning mirrors why he sticks with Opus: Claude thinks more deeply, needs fewer revisions, and ends up more efficient overall.
Context window (say ~200k tokens)
┌───────────────────────────────────────────────┐
│ base config / CLAUDE.md ~20k │
│ THE RIGHT FILES for this task │
│ THE RIGHT SCREENSHOT / LOG / URL │
│ .................. free space for real work .. │
└───────────────────────────────────────────────┘
vs. cramming in the whole project
┌───────────────────────────────────────────────┐
│ every file, every doc, huge chat history │
│ model gets lost in the noise -> worse output │
└───────────────────────────────────────────────┘/clear | /compact | |
|---|---|---|
| What it does | Wipes context; you restart with a clean prompt (or /catchup) | Automatically compresses conversation history |
| Predictability | You control exactly what goes back in | Opaque — you cannot see what was kept or dropped |
| Book's advice | Use this to reset | Do not rely on it |
| You write the requirements doc | Claude interviews you first |
|---|---|
| You only capture what you already thought of | Claude asks about refunds, concurrency, webhooks, currencies — things you missed |
| Blind spots stay blind | Blind spots surface before any code is written |
| Execute in the same messy session | Compile a Spec, then execute in a fresh, focused session |
POST /api/orders when quantity > 100" — Claude locates the cause./context usage./clear and restarting./compact to manage context./context.@file, screenshots, piped logs, and URLs to feed context efficiently./clear and start over./clear between tasks; use a /catchup to restore branch context./context command do, and roughly how much did base config cost in the book's monorepo test?@, screenshots, pipes, URLs)./compact, and what should you use instead?/context in a real project and note how much is used before you do anything.Advanced Prompting & Context Engineering
│
├── Three principles
│ ├── Be specific (files, paths, tech, patterns)
│ ├── Point to examples ("do it like this")
│ └── Symptoms, not causes
│
├── Context engineering
│ ├── Context = message + CLAUDE.md + files + screenshots + history
│ ├── Too much context -> worse output
│ ├── Check with /context
│ └── Feed: @file, screenshots, cat log | claude, URLs
│
├── Big builds
│ └── Let Claude interview you -> Spec -> NEW session to execute
│
├── Codebase navigator
│ └── Ask architecture / call-chain / "why do both exist" questions
│
├── Multi-turn strategy
│ ├── Tight feedback loops (correct early)
│ ├── 2 fails -> /clear + restart
│ ├── /clear between tasks (+ /catchup)
│ ├── subagents for research
│ └── Don't trust /compact
│
└── Effort level
Low / Medium / High(default) / Max -> keep it High/context; feed context with @file, screenshots, piped logs, and URLs./clear after two fails, /clear between tasks, subagents for research./compact; use /clear./clear, and do not lower the effort level. The most effective advancement comes from building
intuition through practice.
This teaching edition is based on the supplied April 2026, 2nd edition of Claude Code: The Complete Guide (§06, "Advanced Prompting & Context Engineering"). Command names, effort-level details and token figures reflect that edition and may change over time.