Domain 6 – Prompt and Context Engineering (11.0%)

• Context Engineering (3.8%)
• Prompt Engineering (4.6%)
• Output Handling (2.6%)

CCDV-F Domain 6 · Task 6.1

What You Need to Know

Context engineering is “the set of strategies for curating and maintaining the optimal set of tokens during LLM inference.” Prompt engineering asks what the instructions say; context engineering asks what is in the window at all.

Bloat and Drift Are Not the Same Fault

Fault	Cause	Fix
Bloat	Volume — full API payloads, whole files, complete search results fill the window	Pruning, just-in-time loading, compaction
Drift	Behaviour — standing rules stated once now sit hundreds of turns back	Placement: move rules to where the model reads them

A bigger window postpones size failure; it does nothing about recall. Context rot: attention budget depletes as token count grows.

Just-in-Time Loading

Keep lightweight identifiers (file paths, stored queries, web links) instead of pasting every record. Load data through tools when the task calls for it. Hybrid: small core up front; fetch everything else as needed.

Pruning Spent Tool Output

Context editing (beta context-management-2025-06-27): clear_tool_uses_20250919 clears old tool results server-side, replaces with placeholders. Configure trigger, keep, clear_at_least, exclude_tools. Clearing invalidates the cached prefix from the clearing point.

Compaction and the Preservation Contract

Replaces the settled portion with a structured summary. Two forms:

• On demand (beta compact-2026-09-04) — your code decides when
• At a token threshold (beta compact-2026-01-12) — API decides when

A custom instructions string replaces the default summarisation prompt entirely. Write the preservation contract in advance: decisions and reasons, established facts and sources, constraints still binding, open questions, state of unfinished work. Drop raw payloads already reduced to facts.

Compaction is billed as its own iteration in usage.iterations. Top-level counts exclude it.

Isolating the Sprawl

Context isolation through subagents: each subagent runs in its own conversation; intermediate tool calls stay inside; only the final message returns to the parent. Exploration stays out of the main window entirely.

CCDV-F Domain 6 · Task 6.2

What You Need to Know

Four choices: where an instruction sits, how clearly it is worded, what output shape it asks for, and how incoming material is marked off. Test one change at a time.

Where an Instruction Sits

• Durable material → top-level system field (who Claude is, standing rules, tone, scope, refusal boundaries)
• Per-request material → user turn (this task, this document, this question)
• Mid-conversation system messages — append a role system message where the new instruction becomes relevant. System takes precedence over user. Later system messages take precedence over earlier ones. Cannot be first entry; must follow user/assistant turn; must end array or be followed by assistant turn.

Not a place for untrusted content. Third-party material stays in tool_result blocks.

Which Surface Carries an Instruction

• Tool description → when that tool applies and its boundaries
• Schema field descriptions → what each field means
• CLAUDE.md / rules → standing conventions (Claude Code)
• System prompt → what must hold whichever tool or task is in play

Put each instruction on the surface guaranteed to be present when it must apply. Treat a duplicated instruction as a defect.

Writing Clear Instructions

Golden rule: “Show your prompt to a colleague with minimal context. If they’d be confused, Claude will be too.” Say what to do rather than what to avoid. Give the motivation. Decompose into ordered steps. State audience, format and length explicitly. Current models follow wording closely and may not generalise — state the scope. Match prompt style to desired output. Emphasis tuned for older models now overshoots.

Worked Examples

Three to five examples, each: relevant, diverse, structured (wrapped in example tags). Inconsistent examples teach inconsistency. Undelimited examples look like the task.

Constraining the Output

Describe format explicitly; give a template or worked example. Where output feeds a machine, use structured outputs (constrained decoding). max_tokens is a hard cap, not a brevity instruction — truncated responses stop mid-sentence.

Gone on current models:

• Prefilling the assistant turn (400 on Claude 4.6+)
• Non-default temperature / top_p / top_k (400 on Claude 4.7+)

Replacements: structured outputs for format control; direct system-prompt instruction (“Respond directly without preamble”) for preamble suppression.

CCDV-F Domain 6 · Task 6.3

What You Need to Know

Structured output is a reply in a fixed shape (usually JSON matching a schema). Well-formed = parses and matches the shape. Correct = values are right.

Three Ways to Produce Structured Output

Method	Enforcement
JSON outputs (output_config.format with json_schema)	Strongest — constrained decoding; schema-compliant guaranteed on completed responses
Strict tool use (strict: true on tool definition)	Constrained decoding on tool names and inputs
Instruction-plus-example JSON	Fallback — relying on the model honouring a request

Python SDK: client.messages.parse(...) with a Pydantic model → response.parsed_output. First request with a new schema pays grammar-compilation latency; compiled grammars cache 24 hours.

The Schema Is Not the Validator

Parsing answers “is this well-formed?”. Validation answers “is this right?”. Structured outputs settle the first. The supported JSON Schema subset does not support numerical constraints (minimum/maximum), string constraints (minLength/maxLength), recursive schemas, or complex enums. additionalProperties must be false.

Four validation checks (yours):

1. Structural — required fields, types, enums (compare enums case-insensitively)
2. Range and plausibility — numbers inside domain bounds, dates in process window
3. Cross-field consistency — total equals sum of parts; status compatible with fields
4. Referential — identifiers naming real things, checked against the issuing system

On failure: raise with the raw response body and request id. Never substitute a default.

Check stop_reason Before the Payload

max_tokens / model_context_window_exceeded → truncated. refusal → declined (still HTTP 200). Never take everything between the first and last braces — succeeds on truncated output and prose-wrapped JSON.

Scepticism Towards Confident Output

Tone carries no information about accuracy. Give permission to decline with exact machine-detectable wording. For long documents, extract word-for-word quotes first. Citations feature (citations.enabled on documents) guarantees valid pointers — does not combine with structured outputs.

When Validation Fails

Re-ask with the specific validation errors attached. An identical re-ask is the weakest move.