Prompt and Context Engineering

What this domain tests

11.0% — roughly 6 of the 53 scored items, the fourth-heaviest domain on CCDV-F. The exam guide breaks it into three named skills with their own weights: Context Engineering (3.8%), Prompt Engineering (4.6%), and Output Handling (2.6%). Those weights are your study budget: prompt engineering is the single largest slice, but context engineering and output handling together outweigh it.

The published sample items for this exam are scenario stems — a concrete situation, four options, one clearly best — with distractors that are category errors rather than near-misses. Expect the same shape here. The recurring pattern in this domain: a developer's pipeline is producing output that is technically valid but operationally wrong (drifting mid-conversation, silently uncached, parsed incorrectly downstream), and the right answer is the option that fixes the mechanism rather than the one that adds emphasis, retries, or switches models.

Two question species show up:

• Mechanism recall: what render order caching uses, what context editing clears versus what compaction summarizes, which field constrains response format versus tool input, what happens below the minimum cacheable prefix.
• Placement judgment: what belongs in the system prompt versus the user turn, where untrusted input goes, where the cache breakpoint goes, when to isolate context in a subagent instead of stuffing the main window.

A note on scope: thinking configuration, effort levels, and the cost side of caching are Domain 5 (Model Selection and Optimization) skills. This domain cares about caching only as a prompt layout discipline — where the bytes go so the prefix stays stable.

Theory outline

1. Context Engineering (3.8%)

The official skill statement covers context and memory management for Claude applications: context window management, prevention of context drift and bloat (tool output pruning, compaction), and context isolation through subagents or multi-step agentic workflows.

The core framing. Prompt engineering asks "what do I say?" Context engineering asks "what is in the window when I say it?" On a long agentic run, the second question dominates: the window fills with tool results, file dumps, and superseded intermediate reasoning, and the model's attention gets diluted across material that no longer matters. Context drift is what that looks like from the outside — the agent starts confidently referencing a file version that was replaced twenty turns ago, or answering the question it was asked at turn three instead of turn thirty.

Three mechanisms, three different jobs. This table is the highest-yield recall item in the domain:

Clearing versus summarizing is the distinction the exam probes. Editing throws information away cheaply; compaction pays to keep the substance. Both operate within a session; memory is the cross-session tool. Long-running agents commonly use all three.

Two implementation facts worth memorizing:

• Context-editing strategies are named per concern — one clears tool uses (with an option to clear the tool inputs as well, not just the results), a separate one clears thinking blocks. They are configured under the request's context-management edits, and they are not the same thing as the compaction strategy, which has its own type and its own beta gate. An option that mixes the two names is a distractor.
• With compaction enabled, append the model's full response content back into the conversation, not just the extracted text. The compaction block lives in that content; the API uses it to replace the compacted history on the next request. Pulling out the text string and appending only that silently loses the compaction state — the classic bug, and a clean exam stem because it produces no error, just a conversation that stops compacting.

Tool output pruning. The dominant source of bloat in agentic applications is tool results, not prompts. A single database dump or file read can outweigh the entire system prompt. Practical discipline: return the narrowest useful result from a tool rather than the raw payload; have the harness truncate or offload oversized outputs and hand the model a preview plus a pointer it can read on demand; and clear results that are no longer load-bearing. The pattern many harnesses adopt — write an oversized tool result to a file, return a truncated preview plus the path — is the same principle: keep the pointer in context, keep the payload out of it.

Context isolation through subagents. The guide names this explicitly as a context-engineering technique, which is the angle to hold. Delegating a subtask to a subagent is not just an orchestration choice — it is a context budget decision. The subagent spends its own window reading the raw material and returns condensed findings, so the parent's window accumulates summaries instead of source dumps. Two consequences follow, and the exam tests both:

• Isolation is the point. A subagent does not inherit the parent's conversation, so everything it needs must be stated explicitly in its prompt. (The orchestration mechanics — how subagents are spawned, coordinated, and handed off — are examined under Domain 1, Agents and Workflows.)
• The same logic supports multi-step workflows without subagents at all: splitting a job into sequential steps, where each step receives only the prior step's output rather than its whole working transcript, achieves context isolation with plain control flow.

Caching-aware layout is a context-engineering discipline. See section 2 — the placement rules live there because they are fundamentally about where instructions go.

2. Prompt Engineering (4.6%)

The official skill statement: principles and methods including instruction clarity, few-shot examples, system versus user placement, output constraints, prompt and instruction placement across components, iterative refinement, prompt adjustment, and input sanitization when writing and iterating on prompts for Claude.

Instruction clarity. The operative test: could a capable colleague with no context on your system execute this prompt correctly? If not, neither can Claude. Clarity failures are almost always a missing specification rather than a misunderstood one — no stated audience, no output contract, no rule for what to do when the input lacks what the task needs. Robust prompts say what to do with missing information ("if the field is absent, emit null — do not infer it"); without that instruction you get a confident guess, which is strictly worse than a null because it's indistinguishable from a real value downstream.

System versus user placement. This is a recall-shaped judgment item and it turns up reliably:

The failure mode the exam likes: a developer interpolates per-request context — a customer ID, today's date, the current user's name — into the system prompt "so the model definitely sees it." That is both a caching disaster (section below) and a structural mistake: the system prompt is the stable component, and putting volatile data there makes the stable component change every request.

Mid-conversation instructions. When an operator instruction arrives partway through a conversation — a mode change, a newly-learned constraint — editing the top-level system prompt is the wrong move: it changes the front of the prefix and re-processes the entire cached history. On models that support it, appending a system-role message to the messages array delivers the instruction after the cached history, leaving the prefix intact. It is also the non-spoofable operator channel, which is why it reappears in the Security and Safety domain: text embedded in a user or tool turn can be forged by anything that writes to user-visible input; a system-role message cannot.

Few-shot examples. Instructions describe the target; examples demonstrate it. For anything where output shape must be identical across runs — a classification label set, a fixed report skeleton, a specific tone — one or two good examples lock it more reliably than a paragraph of rules. Two disciplines: examples must be representative (an unrepresentative example teaches the wrong generalization), and examples of the desired behavior beat prohibitions of the undesired one. Positive demonstration outperforms "do not do X."

Output constraints. State length, structure, and boundaries explicitly, and prefer a machine-enforceable constraint over a prose one where the API offers it — see Output Handling below. Prose constraints ("respond in JSON") are a request; a schema is a guarantee.

Prompt and instruction placement across components — the caching layer. A Claude application's prompt has three rendered components, in this fixed order:

tools → system → messages

Caching is a prefix match over the exact bytes up to each breakpoint. Any change anywhere in the prefix invalidates everything after it. Three rules follow, and they are pure recall:

1. Order by stability. Content that never changes goes first; content that changes per request goes last, after the final breakpoint. Because tools render at position zero, adding, removing, or reordering a tool invalidates the entire cache — serialize the tool list deterministically and keep it fixed for the conversation.
2. Breakpoints go at stability boundaries, capped at four per request. A breakpoint on the last system block covers tools and system together, since tools render before system.
3. Below the model's minimum cacheable prefix, nothing caches — silently. No error is raised; the write simply reports zero cached tokens. The minimum is model-dependent and not monotonic across generations, so a prompt that caches on one model may quietly fail to on another.

Diagnosis is mechanical: check cache_read_input_tokens in the response usage. If it stays at zero across repeated requests that should share a prefix, hunt the silent invalidator — a current timestamp or generated ID interpolated early, non-deterministic JSON serialization (unsorted keys, set iteration), a conditionally-included system section, or a tool list built per user. Note also that the uncached input token count is only the remainder: total prompt size is the uncached input plus the cache-creation tokens plus the cache-read tokens, so a small input-token figure on a long-running agent means caching is working, not that the prompt is small.

The cost model for caching — write premiums, read discounts, break-even math, TTL selection — belongs to Domain 5's Cost and Token Management skill.

Iterative refinement and prompt adjustment. Change one element at a time and test against a saved set of representative inputs, not a single sample. Tuning on one example is how you overfit a prompt to a case that doesn't recur. When steering has accumulated across many contradictory rounds and quality is degrading, the right move is to consolidate everything learned into one clean prompt and start fresh rather than adding another correction on top of the pile. Related discipline: version prompts the way you version code (Domain 2's Configuration Management skill covers prompt versioning explicitly) so a regression can be traced to a specific change.

Input sanitization. Any content that came from a user, a document, a web page, or a tool result is data, not instruction — and must be structurally marked as such. The technique is delimiting: wrap untrusted content in clearly labeled tags or sections, and state in the instruction region that the delimited content is material to process, not directions to follow. The canonical idiom is XML-style tags — an opening and closing tag named for what the content is, so the boundary and the role are both explicit — and the same tagging discipline is what structures a long prompt generally, separating instructions, examples, and reference material into labeled regions the model can address individually. What you must never do is concatenate untrusted text directly into the instruction region, where the model has no structural signal separating your rules from the attacker's. This is where prompt engineering hands off to Domain 7 — sanitization is the prompt-side half of prompt-injection defense, and the enforcement half (guardrails, hooks, least-privilege tools) lives in Security and Safety.

3. Output Handling (2.6%)

The official skill statement: established patterns and techniques for producing, validating, and consuming Claude output, including structured output patterns, response validation, defensive parsing, and skepticism toward confident output.

Structured output patterns. Two distinct mechanisms, and confusing them is a ready-made distractor:

The strict flag belongs on the tool definition, alongside name, description, and input schema — not on the tool-choice parameter. That misplacement is a clean recall trap.

The supported schema subset has real edges worth knowing: basic types, enum, const, and composition keywords are supported; recursive schemas are not, and neither are numeric bounds (minimum, maximum, multipleOf) or string-length constraints. Objects must set additionalProperties to false. Some SDKs paper over unsupported constraints by stripping them from the wire schema and validating client-side — which means a constraint you wrote may be enforced by your SDK, not by the model, and only if you kept the SDK's validation path.

Two operational facts: a new schema incurs a one-time compilation cost on first use, with subsequent requests served from a cache for a day — so a latency spike on the first request with a new schema is expected, not a bug. And structured output is incompatible with citations (the combination is rejected) and with message prefilling.

A note on prefilling. The older technique of forcing output shape by prefilling the start of the assistant's turn is no longer supported on current Claude models — a request whose final message is an assistant turn is rejected. Its jobs have been reassigned: schema conformance goes to structured outputs; suppressing preambles ("Here is the summary:") goes to a system-prompt instruction to respond directly without preamble; continuing an interrupted response goes into the user turn as an explicit continuation instruction. If a scenario describes a prefill-based pipeline that started failing, the fix is the replacement mechanism, not a workaround.

Response validation. The load-bearing point: a schema-constrained response is not an unconditionally valid response. Two documented cases break conformance —

• The model refuses (a refusal stop reason), in which case the output may not match the schema at all.
• The response is truncated at the token ceiling (a max-tokens stop reason), leaving structurally incomplete output.

So: check the stop reason before consuming the content, and validate the parsed object against your schema on receipt anyway. Code that indexes into the first content block unconditionally breaks on a refusal.

Defensive parsing. Three rules:

1. Parse, never string-match. Model-produced JSON — including tool-call inputs — can differ in escaping (Unicode escapes, escaped forward slashes) between models and versions while remaining semantically identical. Run it through a real JSON parser and read fields off the parsed object. Raw substring matching against the serialized form is a latent version-dependent bug.
2. Narrow the content union before reading it. A response's content is a list of typed blocks — text, tool use, thinking, tool results — not a single string. Check the block type before reading a field off it.
3. Fail loudly at the boundary. Validate where model output enters your system, and treat a validation failure as an error to handle, not something to silently coerce.

Skepticism toward confident output. The named skill, and the judgment layer of this domain. Confidence in the prose is not evidence of correctness: a fabricated identifier, an invented API parameter, or a plausible-but-wrong figure arrives in exactly the same register as a correct one. The engineering responses the exam rewards are structural rather than exhortative:

• Ground claims in retrieved evidence and require the output to cite the source it used, so a claim without a source is visibly unsupported.
• Verify against a system of record for anything consequential — check the ID exists rather than trusting that it does.
• Put checks where they're cheap. A schema catches shape errors; a boundary validation catches range errors; a human review catches judgment errors. Choose the cheapest layer that catches the class of error you actually face.

The wrong answer, reliably, is "instruct the model not to hallucinate."

Worked problems

Problem 1. A support application sends a 12,000-token system prompt on every request. The prompt begins with a header line that interpolates the current timestamp, and a cache breakpoint sits on the last system block. After a week in production, the team sees no cost improvement. What is wrong?

A. The breakpoint is on the wrong block — it belongs on the last user message B. The timestamp at the front of the system prompt changes the prefix every request, so nothing after it can ever be a cache hit C. Twelve thousand tokens exceeds the maximum cacheable prefix size D. Caching requires a beta header the team did not send

Approach: Caching is a prefix match with a fixed render order — tools, then system, then messages. A value that changes per request, placed at the front of the system component, invalidates everything downstream of it no matter where the breakpoint sits. The fix is to move the timestamp out of the system prompt into the user turn, after the last breakpoint.

Why the others fail: A misreads the mechanism — a breakpoint on the last system block is a correct and common placement, and moving it wouldn't rescue a poisoned prefix. C inverts the real constraint: there is a minimum cacheable prefix below which caching silently doesn't happen, not a maximum that a 12K prompt would exceed. D invents a gate; prompt caching is generally available.

Answer: B

Problem 2. An agent runs long research sessions. Its transcript fills with tool results from dozens of file reads, most long since superseded. The team wants to keep the transcript lean without paying to compress content that no longer matters. Which mechanism fits?

A. Compaction, which summarizes earlier context as the window fills B. Context editing, which clears old tool results from the transcript C. The memory tool, which persists state to files across sessions D. Raising the token ceiling on each request

Approach: The stem specifies stale, irrelevant content and an explicit preference not to pay to preserve it. That is the clearing case, not the summarizing case — context editing removes old tool results outright. Compaction is the right answer to a different stem: content that still carries meaning, and a conversation about to exceed the window.

Why the others fail: A summarizes when the requirement is to discard — more expensive, and it preserves material the team just said is worthless. C solves cross-session persistence, an orthogonal problem. D confuses the output ceiling with the input window; a larger output allowance does nothing about a bloated transcript.

Answer: B

Problem 3. A pipeline must return an object with fixed fields for downstream code. The developer sets a response format with a JSON schema and pipes the result straight into the consumer. It works for weeks, then the consumer crashes on malformed input. What was missing?

A. Nothing — the schema guarantees conformance, so this must be a consumer bug B. The schema needed additionalProperties set to false C. Checking the stop reason before consuming the content — a refusal or a token-ceiling truncation can produce output that does not conform D. A retry loop around the request

Approach: Schema constraints hold on the normal path. Two documented cases break them: a refusal, where output may not match the schema, and truncation at the token ceiling, which leaves structurally incomplete output. Both surface on the stop reason, which is exactly what the pipeline never checks. The discipline is to branch on the stop reason first and validate the parsed object on receipt.

Why the others fail: A states the belief the item is testing. B is a real requirement for objects in the supported subset but doesn't address a truncated or refused response — a schema that already validated for weeks was clearly acceptable. D retries without diagnosing; a refusal retried verbatim refuses again, and a truncation retried at the same ceiling truncates again.

Answer: C

Problem 4. A summarizer accepts web pages submitted by end users. The developer builds the prompt by concatenating the instruction paragraph and the page text into one system prompt. A reviewer flags the design before launch. What is the prompt-side fix?

A. Move the whole thing to the user turn as one concatenated string B. Put the instructions in the system prompt and pass the page text in the user turn inside clearly labeled delimiters, stated to be data to summarize rather than instructions to follow C. Add a line to the instructions asking users not to include malicious text D. Truncate the page text to a fixed length before including it

Approach: Two mistakes are stacked: untrusted content is in the system prompt (the stable, authoritative component), and it is structurally indistinguishable from the instructions. Sanitization means marking untrusted material as data — delimited, labeled, and outside the instruction region — so the model has a structural signal about what is a rule and what is material. Note this is the prompt-side half only; the enforcement half (guardrails, least-privilege tools) is Domain 7's.

Why the others fail: A keeps the fatal property — no boundary between instruction and untrusted text. C is a polite request, not an enforceable control, and asks the wrong party: the attacker is the one submitting the page. D limits volume, not authority — a short injection works exactly as well as a long one.

Answer: B

Problem 5. An agent must analyze forty long log files and produce one report. Loading all forty into the main conversation exhausts the context window. Which approach fits the context-engineering intent?

A. Increase the token ceiling on the request B. Delegate per-file analysis to subagents, each spending its own window on one file and returning condensed findings, and synthesize from those findings C. Concatenate the files and rely on compaction to handle the excess D. Analyze the first ten files and extrapolate

Approach: The guide names context isolation through subagents or multi-step workflows as a context-engineering technique, and this is its archetype. Isolation is a budget mechanism: each subagent burns its own window on raw material and returns a summary, so the parent's window accumulates findings rather than source text. The same shape works as a sequential multi-step workflow if subagents aren't available — each step receives the previous step's output, not its transcript.

Why the others fail: A confuses the output ceiling with the input window. C is compaction misapplied — it manages a conversation approaching its limit, not an input that never fit; you would also be summarizing raw logs rather than analyzed findings. D trades a solvable engineering problem for guaranteed blind spots.

Answer: B

Problem 6. A tool takes an object parameter. A downstream integration reads the tool call by matching substrings against the serialized input JSON. After a model upgrade, matches start failing intermittently even though the model is calling the tool correctly. What is the fix?

A. Add strict validation to the tool definition B. Parse the tool input with a JSON parser and read fields off the parsed object rather than matching the serialized text C. Lower the model's sampling variability D. Rename the tool parameters to avoid characters that need escaping

Approach: Model-produced JSON can differ in escaping — Unicode escapes, escaped forward slashes — across models and versions while remaining semantically identical. Any integration that matches the serialized form carries a latent version-dependent bug; parsing is the documented discipline. This is the defensive-parsing skill stated almost literally.

Why the others fail: A improves input validity but changes nothing about how the consumer reads it — a strictly-validated input can still be serialized with different escaping. C treats a serialization difference as a sampling problem. D is a workaround aimed at the symptom that breaks the moment a value (not a key) contains an escapable character.

Answer: B

Exam traps

• Cache render order. It is tools, then system, then messages. Tools sit at position zero, so a changed tool list invalidates the whole cache. Options that place messages before system, or claim a breakpoint protects content before it, are distractors.
• Static-first, volatile-last. Any per-request value (timestamp, request ID, user name, session ID) placed early in the prompt makes everything after it uncacheable. The seductive wrong answer is "move the breakpoint"; the right one is "move the volatile content."
• The minimum cacheable prefix fails silently. Below it there is no error — just zero cached tokens. An option claiming caching "errors out" on short prompts is wrong, and the threshold is model-dependent.
• Clearing versus summarizing. Context editing clears stale tool results and thinking; compaction summarizes as the window fills. Swapping the two, or naming a compaction strategy where a clearing strategy belongs, is the standard mix-and-match distractor.
• Dropping the compaction block. Append the model's full response content back, not just the extracted text — the compaction state rides in that content and silently disappears if you extract only the string.
• Per-request data in the system prompt. The system prompt is the stable component: role, durable rules, format contract, tool guidance. Task and data belong in the user turn. For a mid-conversation operator instruction, a system-role message appended to the messages array beats editing the top-level system prompt.
• The strict flag's home. Strict tool use is a field on the tool definition, next to name and input schema — not on tool choice. And it constrains tool input, whereas the response-format configuration constrains the model's response. Options that swap those two jobs are common.
• Schema constraints that aren't supported. Recursive schemas, numeric bounds, and string-length limits are outside the supported subset; objects need additionalProperties set to false. An option that solves a problem with a minimum/maximum constraint is describing something the schema layer will not enforce.
• "The schema guarantees it." A refusal or a truncation at the token ceiling can produce non-conforming output. Check the stop reason before consuming content, and validate on receipt anyway.
• String-matching serialized model output. Escaping varies. Parse it. Any option built on substring matching against raw tool-call JSON is wrong regardless of how carefully it's written.
• Prefilling as the answer. Assistant-turn prefills are rejected on current models. When a stem describes a broken prefill pipeline, the fix is structured outputs (for shape), a system-prompt instruction to respond without preamble (for preambles), or an explicit continuation instruction in the user turn (for interrupted responses).
• "Tell the model not to hallucinate." Never the answer to a skepticism-toward-confident-output stem. The correct moves are structural: require citations to retrieved evidence, verify against a system of record, and validate at the boundary.