Key Principle
"If your question is vague, the reasoning path will be broad; if specific, Claude narrows its reasoning" (Chapter 3). Specificity is the master lever under every framework in these chapters. A good prompt has three parts — Context + Instruction + Constraint — and answers three unspoken questions: what to build, how it behaves, what format (Chapter 3). "Every missing detail weakens its reasoning process" (Chapter 3).
Why This Matters
Developers import linter-style, deterministic expectations and are surprised when generation is probabilistic — the same prompt yields slightly different output (Chapter 2). The correct response is iterative refinement, not bug-hunting the model. The three prompt-error categories — ambiguity, context overload, instruction conflict (Chapter 3) — are all communication failures, not model failures, so the fix is to "reframe the prompt rather than correcting the model" (Chapter 3).
Context is finite working memory ranked by recency, relevance, and semantic weight. When the window fills, Claude compresses and forgets earlier content, prioritizing recent tokens (Chapter 2). This makes more context not better: overloading "blurs focus" and degrades relevance ranking. The principle is curate, don't dump — strategic inclusion, not maximal inclusion.
Good Examples
- Chain-of-thought = separate reasoning from execution: outline the approach before writing code, so the reasoning constrains the implementation and prevents logical and runtime errors (Chapter 3). Same lever (force structure first) applied inside one prompt.
- System prompts anchor behavior session-wide: define standards (PEP8, docstrings) and guardrails ("only DB-migration code," "never expose credentials") once, inherited by every later prompt as top priority; reinforce mid-session to fight drift (Chapter 3).
- You are the keeper of memory: the context is stateful only as far as you maintain it — restate language, framework, and goals every few turns and use brief recaps as "session anchors" (Chapter 2).
Counterpoints
- A vague "create a register API" silently drops password hashing and error handling — "not because the model is weak but because nothing constrained it toward them" (Chapter 3).
- Context overload is itself a failure mode: burying the signal forces the model to guess what matters, so curation beats volume (Chapter 2, Chapter 3).
- Letting goals drift: because the API is stateless and the window forgets, unrestated goals get silently optimized against — "the model reacts like an uncertain intern, guessing instead of reasoning" (Chapter 3).
Key Quotes
"context is Claude's mindspace. Tokens define its capacity; structure defines its reasoning." — Kilian Voss, Chapter 2
"When it's vague or rushed, the model reacts like an uncertain intern, guessing instead of reasoning." — Kilian Voss, Chapter 3
Rules of Thumb
- Build prompts as Context + Instruction + Constraint; answer what / how / what-format.
- Ask for the reasoning or plan first, then the implementation.
- Curate context; do not dump. Order foundation → higher layers and label files.
- Restate language, framework, and goals every few turns; treat tokens as bandwidth.
- Set guardrails in a system prompt once; reinforce them mid-session to counter drift.
- When output is wrong, reframe the prompt — don't "correct" the model.
Related References
- Core Framework — Partner Not Autocomplete, Mastery Through Understanding - context richness as the quality lever
- Debugging and Review — Semantic Debugging and Calibrated Trust - specificity is the enabling condition for debugging
- The Claude Loop - reasoning-before-execution at workflow scale
- Rules of Thumb — Heuristics Across All Chapters - condensed prompting heuristics