Domain 2: Claude Models, Prompting & Context Engineering
13% of examSelect Claude models and apply model-choice tradeoffs
Key Points
- Three tiers: Haiku (fastest/cheapest, high-volume well-defined steps), Sonnet (balanced workhorse), Opus (most capable, hardest reasoning/orchestration).
- Resolve quality vs. latency vs. cost against the specific requirement, not in the abstract -- there is no universal 'best' model.
- Mixed-model pipelines route each step to the tier that fits its difficulty and budget.
- Extended/adaptive thinking trades billed output tokens and latency for better performance on hard reasoning tasks -- reserve it, don't default to it.
- Pin model versions in production and re-run evals before adopting a new release; a prompt tuned for one version can regress on the next.
Decision Rules
When: A step is high-volume, well-defined, and latency-sensitive (classification, routing, extraction)
→Route it to Haiku.
When: A step requires genuinely hard reasoning, planning, or orchestration
→Use Opus or extended thinking.
When: A new model release becomes available
→Pin the current version in production and re-run evals before adopting the new one.
✗ Anti-Patterns to Reject
- Defaulting to the most capable model everywhere instead of fitting the tier to the constraint.
- Upgrading to a new model version without re-running evals, assuming newer always means strictly better for a given prompt.
Design system prompts, templates, and guardrails
Key Points
- System prompt holds stable rules/role/tone/constraints; user message holds the specific request and per-request data.
- This separation keeps behavior consistent and keeps the stable prefix cacheable.
- Templates parameterize variable parts while holding the scaffold constant, improving consistency and cache hit rates.
- Prompt-level guardrails (refusals, content policy, escalation) are probabilistic -- the model usually follows them but compliance isn't guaranteed.
- Deterministic controls (hooks, permission scoping, output validation) sit around the model and enforce boundaries structurally; use them for destructive or high-stakes actions.
- Untrusted input must be delimited/sanitized so it isn't read as an instruction.
Decision Rules
When: Content is stable across every request (rules, role, tone)
→Place it in the system prompt, not the user message.
When: An action is destructive or high-stakes
→Pair the prompt guardrail with a deterministic control (hook, permission scoping, output validation) -- don't rely on the prompt sentence alone.
When: A prompt incorporates untrusted input (user text, retrieved docs, tool output)
→Delimit and sanitize it so it can't be read as an instruction.
✗ Anti-Patterns to Reject
- Mixing stable and per-request content in one blob, hurting consistency and breaking the cacheable prefix.
- Relying on a single system-prompt sentence as the only guardrail for a destructive or high-stakes action.
Apply prompt engineering techniques matched to the task
Key Points
- Zero-shot suits simple, unambiguous tasks; few-shot locks in format/edge-case behavior; chain-of-thought suits multi-step reasoning.
- Few-shot examples show the desired behavior rather than describing it in prose.
- Chain-of-thought and extended thinking are the same lever: reasoning depth traded for tokens/latency.
- Specific, clear instructions beat clever or terse ones for consistent output.
- Positive instructions ('respond only in JSON matching this schema') beat long negative 'don't' lists.
- With long inputs, place the key instruction after the material, near the end; iterate one change at a time and measure against an eval set.
Decision Rules
When: The task is simple and well-specified
→Use zero-shot -- examples or chain-of-thought would add cost without benefit.
When: Prose instructions alone can't pin down a specific format or edge-case behavior
→Add few-shot examples.
When: The task requires multi-step reasoning, math, or complex judgment
→Use chain-of-thought or extended thinking.
When: The input is long
→Place the key instruction near the end, after the material.
✗ Anti-Patterns to Reject
- Adding few-shot examples or chain-of-thought reflexively, as if they were always an improvement.
- Iterating on multiple prompt changes at once, making it impossible to attribute a quality change to a specific edit.
Optimize the context window and manage token budgets
Key Points
- The context window is one shared budget across system prompt, history, tools, tool results, retrieved docs, and the response.
- Context rot/drift is quality degradation caused by low-signal tokens crowding the window -- not by running out of room.
- Curate to the smallest set of high-signal tokens rather than relying on raw context capacity; a bigger window does not eliminate the need for curation.
- Pruning drops stale tool output; compaction summarizes older turns; isolation moves heavy subtasks into a subagent's own window; progressive disclosure loads information only as needed.
- Track the usage field (input/output/cache tokens) to model cost and detect bloat before hitting the budget.
Decision Rules
When: Tool output is large or stale and no longer informs the task
→Prune it.
When: Conversation history is long
→Compact older turns into a summary recap.
When: A subtask requires reading far more material than the answer needs
→Isolate it into a subagent's own context window.
When: The usage field shows climbing input tokens with no quality gain
→Investigate curation before assuming a bigger context window is the fix.
✗ Anti-Patterns to Reject
- Assuming a bigger context window removes the need to curate -- it only postpones the same degradation.
- Treating pruning, compaction, isolation, and progressive disclosure as interchangeable rather than complementary.
Design for prompt reuse through caching, modular prompts, and Skills
Key Points
- A stable prefix (system prompt + policy + few-shot block) can be cached: reads are cheap, writes carry a slight premium.
- Order stable content first, dynamic content last to maximize the cacheable prefix length -- this cuts both time-to-first-token and per-request cost.
- Modular prompts compose reusable, independently versioned fragments (role, policy, format spec) instead of duplicating text.
- Agent Skills package reusable instructions/procedures, authored once and reused across apps/teams, without a running service.
- Caching, modular prompts, and Skills are three complementary levers for making prompt designs affordable and maintainable at scale.
Decision Rules
When: A large stable prefix repeats across many requests
→Order it first and cache it rather than reprocessing it every call.
When: A needed policy document is large and there's a temptation to truncate it to save tokens
→Cache it instead -- truncation trades away correctness that caching would have preserved for free.
When: A capability (procedure/know-how) needs to be reused across apps/teams without standing up a service
→Package it as an Agent Skill.
✗ Anti-Patterns to Reject
- Putting dynamic content before the stable prefix, breaking the cacheable prefix and defeating caching.
- Confusing prompt caching (reusing a stable prefix within a call) with retrieval (fetching external documents).