Domain 4 — Prompt Engineering & Structured Output (20%)

Half of this domain is classical prompting technique. The other half is the part people lose marks on: knowing when prompting is the wrong tool and a schema is the right one.

4.1 Techniques, in the order you should reach for them

1. Be clear and direct. State the task, the audience, the format and the constraints explicitly. Most "improve this prompt" questions have an answer that simply says more precisely what is wanted.
2. Examples (multishot). The strongest lever for consistency of format and judgement. Include edge cases and near-misses, not just three happy paths.
3. Chain of thought. Ask for reasoning before the answer on analytical tasks. Costs latency and tokens; skip it for classification-style work where it adds nothing.
4. XML tags. <document>, <examples>, <instructions> give unambiguous boundaries and make the prompt parseable by both the model and your own code.
5. System prompt / role. Persona and standing rules go in system; the task goes in the user turn.
6. Prefill. Start the assistant turn (e.g. with { or <analysis>) to force a format and skip preamble.
7. Chain prompts. Decompose a complex job into steps whose outputs feed forward — easier to evaluate and debug than one mega-prompt.
8. Long-context technique. Put long documents first, the question last; wrap each document in tags with an ID; ask for quotes before analysis so the answer is grounded.

Order matters in the answer choices — Questions that ask "what should you try first" reward the cheapest, most direct intervention. Fine-tuning-style answers and "switch to a larger model" are usually distractors when the actual defect is an underspecified prompt.

4.2 Structured output: the two mechanisms

Use them together when an agent both calls tools and must return a structured final answer. Against a prompt that merely asks for JSON, structured outputs are the difference between best-effort and enforced — no parse errors, no missing required fields, no stray prose.

Schema support and limits

Two edge cases the exam likes — Refusals (stop_reason: "refusal") and truncation (stop_reason: "max_tokens") can both produce output that does not match your schema. A schema is not a substitute for checking stop_reason. Enum casing is also not guaranteed — compare case-insensitively.

4.3 Extraction with validation and retry

The Domain 4 / Domain 5 crossover scenario. The pattern the exam wants:

1. Extract with a JSON schema so the shape is enforced at generation time.
2. Validate against your own business rules — the schema guarantees structure, not truth. Dates in range, totals equal to the sum of line items, IDs that exist.
3. On failure, retry with the specific validation error fed back into the prompt: "line_items[2].amount was 'N/A'; it must be a number in cents." A bare "that was wrong, try again" retry is the anti-pattern — it gives the model nothing to correct.
4. Cap the retries. On persistent failure, route to human review with the partial extraction and the failing fields attached — never silently drop the document, and never emit a record you know is invalid.
5. For documents longer than one comfortable pass, use multi-pass extraction: section by section, or field-group by field-group, then merge.

4.4 Prompting for CI feedback quality

When the deliverable is machine-consumed review comments, the prompt has to specify severity thresholds, a fixed output shape (file, line, severity, finding, suggested fix), and — crucially — few-shot examples that show both a finding worth reporting and a finding that should be suppressed. Showing the negative case is what actually moves false-positive rates.

← Previous: Domain 3 — Claude Code Configuration & Workflows  |  Next: Domain 5 — Context Management & Reliability →