5.1 Prompt Engineering

A Prompt Is a Contract

The CCA-F treats a prompt as a contract, not a polite request, and Prompt Engineering & Structured Output is a 20% domain. A production-grade prompt names six things:

Naming all six removes ambiguity. The most common weak-prompt failure the exam describes is a vague instruction ("summarize this nicely") that leaves the output shape and the failure behavior undefined, so downstream code cannot rely on it.

Structure Claude Responds To

Two formatting habits measurably improve adherence and are worth knowing for the exam:

• XML-style delimiters. Claude is tuned to respect tags such as <document>...</document>, <example>...</example>, and <instructions>...</instructions>. Wrapping each part of the prompt in a labeled tag prevents the model from confusing the data with the instructions — important when the data itself contains instruction-like text (a defense against prompt injection from retrieved content).
• Rules near the end. A short, explicit list of rules placed near the end of the prompt benefits from recency and is followed more reliably than the same rules buried in the middle.

Be prescriptive and explicit rather than clever. State both what to do and what not to do. Give the model an escape hatch: tell it to say "I don't know" or return a sentinel value when the context lacks the answer, rather than forcing a fabricated response. And place dynamic context deliberately — durable rules go in the system prompt, the immediate task goes at the bottom, and anything that changes per request goes late so it does not invalidate prompt caching of the stable prefix (Chapter 6).

A further habit the exam rewards is matching prompt specificity to the task: positive instructions that show the desired behavior outperform long lists of prohibitions, and concrete success criteria ("each risk must cite a line number") beat vague adjectives ("be thorough"). When a recent Claude model follows instructions very literally, an over-prescriptive prompt can backfire by suppressing useful judgment — so state the goal and the hard constraints, then let the model fill in the rest rather than scripting every step.

Few-Shot Examples: Powerful but Not Validation

Examples are the strongest lever for teaching format and edge cases. The exam expects a few principles:

• Diversity beats volume. Three or four diverse examples that include a tricky edge case outperform ten near-duplicates that all look the same. Duplicates teach the model nothing new and waste context budget.
• Show the edge case. If the real input distribution includes empty fields, ambiguous requests, or adversarial text, an example should demonstrate the desired handling for at least one of them.
• Examples never replace validation. A model can produce convincing prose that violates the contract. If downstream code parses the output, you still validate the parsed object in code (Chapter 5.2). Treating examples as a guarantee is a trap the exam punishes.

Wrap each example in tags (<example>) and, where it helps, label the input and the expected output so the pattern is unambiguous.

Advanced Techniques: Deploy When Justified

The exam expects familiarity with advanced techniques and, just as importantly, the judgment to apply them only when the task warrants it.

Modern Claude models expose extended (adaptive) thinking, where the model decides how much to reason; you control depth with an effort setting rather than a fixed token budget. The architect's discipline is the same as everywhere on this exam: reach for the simplest technique that meets the quality bar. A clear single prompt with good structure beats an elaborate chain when the task is simple, and the exam will offer an over-engineered prompting answer as a distractor.

Prompt Engineering Decision Table

Match the clue to the lever, and prefer the least elaborate prompt that satisfies the success criteria.