Prompt and Context Engineering

Prompt and Context Engineering is 11.0% of CCDV-F, roughly six items of fifty-three. That makes it a mid-weight domain: worth real but bounded study time, far behind Applications and Integration, about level with Tools and MCPs. The questions are implementation questions, not style advice. Expect to be shown a prompt or a request payload and asked what to change: where a rule belongs, how a document should be delimited, why the returned JSON will not parse.

The idea that unlocks the domain is that a prompt is a structured document with a fixed order, not a paragraph of wishes. Durable identity and standing rules go in the system parameter. Long documents go near the top of the user turn, above the question. Instructions and examples each get their own tagged block. The output contract comes last and is enforced rather than requested. Everything else follows from that: prefill locks the opening, thinking has to be budgeted and placed before the answer, and because the Messages API is stateless, every turn you carry forward is a turn you pay for again.

• Stable identity, role, tone and standing rules belong in the top-level system parameter; the turn-specific task belongs in the user message. There is no system role inside messages.
• Order every prompt the same way: task context, then long documents, then detailed rules, then examples, then the immediate question, then the output format.
• Long documents go near the top of the user turn, above the question. Material first, query last, measurably beats the reverse on long inputs.
• Delimit each distinct part with XML tags such as <document>, <instructions>, <example> and <data>. The tag names are yours to pick; using them consistently matters more than which word you pick.
• With several documents, wrap each in its own block carrying an index and a source or title, so the model can name what it used and you can check it.
• Three to five diverse examples outperform any amount of adjective instruction. Wrap them in <example> tags and include at least one edge case you actually care about.
• Be explicit about output: state the exact shape, and say what to leave out — no preamble, no commentary — whenever you intend to parse the response.
• Force JSON with a tool whose input_schema is the schema you want, rather than asking for JSON in prose and hoping.
• Prefill the assistant turn to lock the opening: end the request with an assistant message containing the first characters of the answer, and Claude continues from there.
• Pair a prefill with a stop sequence to cap the tail, then reattach the prefill text to the completion before parsing.
• Reasoning must come before the answer, never after. An answer already written is not influenced by justification that follows it.
• Reach for extended thinking only when the task genuinely needs multi-step reasoning; the budget is tokens you pay for, and it is subtracted from max_tokens.

• Output that parses only sometimes is a schema problem, not a temperature problem. Move the contract into a tool input_schema and validate before you use the result.
• Prefilling the assistant turn and extended thinking are mutually exclusive; a prefilled final assistant message is rejected once thinking is enabled.
• Extended thinking pins sampling. Leave temperature at its default and do not tune top_p or top_k alongside it.
• Never edit, summarize or regenerate returned thinking blocks. In a multi-turn tool loop they must be passed back verbatim, signature intact, or the request is refused.
• The thinking budget counts against max_tokens. Setting it close to max_tokens starves the visible answer and yields a truncated response.
• A truncation stop reason in the middle of JSON is the classic silent corruption. Check the stop reason before parsing; retry or continue rather than string-patching the fragment.
• Prose wrapped around JSON defeats naive parsers. Prefill the opening delimiter and stop on the closing one instead of scraping with a regular expression.
• A growing conversation degrades twice over: cost and latency rise with every resend, and stale tool results crowd out the instructions you care about.
• Compress the middle of a conversation, never its ends. Keep the system prompt and the most recent turns verbatim; summarize or drop the oldest exchanges and spent tool results.
• Any change near the front of the prompt invalidates the cache for everything after it. Keep the cached prefix — tools, system, long documents — byte-stable and let only the tail vary.
• A timestamp, session id or user name embedded in the cached prefix quietly destroys the hit rate on every request.
• Text inside a document tag is data, not instruction. Say so in the surrounding prompt, and never let quoted content redefine the output contract.

SCRIBE — the order in which a prompt is assembled, front to back.

• S — System prompt. Role, tone and standing rules go in the system parameter, where they persist across every turn.
• C — Context. Long documents, background data and conversation history next, near the top of the user turn and above the question.
• R — Rules. Explicit task instructions and constraints, stated positively: what to do, what to omit, what edge cases mean.
• I — Illustrate. Three to five diverse few-shot examples, tagged, including the awkward case.
• B — Brainstorm before answering. Reasoning space ahead of the answer: guided steps, a <thinking> block, or an extended thinking budget when the task earns one.
• E — Enclose and extract. XML tags around every part, the output format or tool schema stated last, prefill to lock the opening, then parse by tag or schema.

Read it as a sequence, not a checklist: each letter constrains the one after it, and the two most commonly skipped are R and E — the parts that make the output machine-readable.