Domain 6: Prompt and Context Engineering
11% of examWrite clear, direct instructions and place system/user content correctly
Key Points
- State the task, constraints, and desired output explicitly -- ambiguity is the top cause of poor output.
- Positive framing ("respond only in JSON matching this schema") steers more reliably than long "don't" lists.
- Durable role, rules, and constraints go in the system prompt; the specific request and per-request data go in the user message.
- Output constraints (exact shape, length, structure) usually belong with the durable rules in the system prompt.
Decision Rules
When: Writing a standing rule that applies to every call
→Put it in the system prompt.
When: Supplying the specific request or data for this particular call
→Put it in the user message.
When: Tempted to add another "don't" to the instructions
→Prefer a positive instruction describing the target output instead.
✗ Anti-Patterns to Reject
- Putting per-request data in the system prompt and stable rules in the user turn.
- "More prohibitions = safer" -- long negative lists steer worse than positive, specific instructions.
Use few-shot examples, delimiters, and iterative refinement
Key Points
- Worked examples (zero-/one-/multi-shot) often lock in format and style more effectively than a paragraph of description.
- With long inputs, place the document first and the key instruction near the end, right before the response.
- XML-style tags and headings separate instructions from data and enable input sanitization.
- Untrusted user/retrieved text must be delimited and sanitized so it isn't read as an instruction -- ties directly to prompt-injection defense.
- Iterative refinement: diagnose the specific gap, change one thing, re-run, compare, and fold recurring lessons into the standing system prompt.
Decision Rules
When: Prose instructions alone don't reliably produce the target format
→Add worked examples instead of more description.
When: Prompting over a long source document
→Place the document first and the key ask near the end of the prompt.
When: Untrusted user or retrieved text enters the prompt
→Wrap it in delimiters and treat it as data, not instruction.
✗ Anti-Patterns to Reject
- Burying the key instruction at the top of a huge document.
- Changing multiple things at once during prompt refinement, making it impossible to attribute a quality change to one edit.
Manage the context window as a shared, finite budget
Key Points
- The context window is one shared budget: system prompt, tool schemas, history, tool results, and retrieved docs all compete for the same space.
- The goal is the smallest set of high-signal tokens that maximizes the odds of the desired outcome.
- Context rot is attention degradation as the window fills with irrelevant or stale content, even with room technically left.
- Context drift is the gradual loss of track of instructions or facts over a long interaction.
- Compaction, pruning, isolation, and re-stating key constraints counter drift -- not temperature or more prohibitions.
Decision Rules
When: A long agent session starts ignoring earlier instructions and quality drops
→Compact older turns and prune stale tool output; don't raise temperature or add prohibitions.
When: Deciding what to include in context
→Prefer the smallest high-signal set over maximizing what's included.
✗ Anti-Patterns to Reject
- "Just use the biggest context window and stuff everything in."
- Reaching for temperature or more prohibitions to fix context rot or drift.
Apply context curation techniques: pruning, compaction, isolation, and retrieval
Key Points
- Tool-output pruning: keep only what later steps need from a large tool payload; drop raw dumps from the ongoing history.
- Compaction: periodically summarize older turns into a compact recap, reclaiming budget while preserving the thread.
- Compaction is not truncation -- truncation blindly drops tokens and can lose critical facts.
- Context isolation: delegate a heavy subtask to a subagent with its own window; it returns a condensed result.
- Just-in-time retrieval: pull information in when needed rather than front-loading everything.
Decision Rules
When: A tool returns a large payload
→Prune it to what later steps need rather than carrying the full dump forward.
When: A session grows long
→Compact older turns into a summary rather than truncating blindly.
When: A subtask requires reading far more than the final answer needs
→Isolate it in a subagent with its own context window.
✗ Anti-Patterns to Reject
- Confusing compaction (preserves meaning) with truncation (blindly drops tokens, can lose critical facts).
- Front-loading an entire knowledge base instead of retrieving just-in-time.
Handle Claude's output defensively
Key Points
- For machine-readable output, use tool use/tool-forcing (a tool whose input schema is the target shape) or structured-output features; prefilling (e.g., "{") can nudge JSON-only output.
- Validate structure AND semantics -- well-formed JSON can still be wrong.
- Defensive parsing: tolerate extra prose, handle truncation (stop_reason: max_tokens), and retry, repair, or fall back on failure.
- Claude can be confidently wrong -- polish and certainty are not evidence of correctness; ground high-stakes claims and keep a human in the loop.
Decision Rules
When: Reliable machine-readable JSON is needed
→Define a schema and use tool-forcing/structured output, then validate the result.
When: A numeric or semantic field looks wrong despite valid JSON structure
→Validate semantics -- don't assume structure implies correctness.
When: Output is truncated (stop_reason: max_tokens)
→Handle it in defensive parsing and raise max_tokens; don't crash the application.
✗ Anti-Patterns to Reject
- Trusting output because it "looks right" or sounds confident.
- Parsing model text with brittle string operations and no error handling.
- Believing temperature 0 alone guarantees valid, parseable JSON.