Prompt Engineering

Prompt Engineering is the largest sub-skill in its domain at 4.6%, roughly two or three questions out of 53. It is also the one candidates most often assume they can skip, on the grounds that they write prompts every day. The exam is not asking whether you write prompts. It is asking whether you can say why one version outperforms another and then prove it.

The framing that holds the material together is that a prompt is a specification, judged the way any specification is: unambiguous, complete about its edge cases, stable when the input varies. Most prompting failures are specification failures in a stylistic disguise. The model did something reasonable with an instruction admitting two readings, or applied a rule meant for one situation to every situation, or produced twelve paragraphs because nothing said otherwise.

The second half is process. Which of two prompts is better is an empirical question with a cheap answer: a handful of representative inputs, a written criterion for success, and one change at a time. Scenarios in this sub-skill frequently describe a team tuning by feel and ask what is missing, and the missing thing is nearly always a way to tell whether the last edit helped.

Practise editing prompts rather than admiring them.

What the exam tests here

• •Splitting standing behaviour into the system turn and per-request material into the user turn
• •Writing few-shot examples that vary, including one awkward case, rather than a single polished sample
• •Specifying what to do when input is missing, ambiguous or out of scope
• •Resolving a contradiction between an instruction and an example instead of adding a third rule
• •Comparing two prompt versions against a fixed input set with a stated pass criterion
• •Decomposing a prompt doing three jobs into a chain that does one each

Standing behaviour above, this request below

The split is not stylistic. Whatever holds for every request in your application (the role, the tone, the rules, the output contract, the tool policy) belongs in the system turn, where it sits at the front of the assembled request unchanged from call to call. Whatever is specific to this request goes in the user turn.

Getting it backwards costs more than tidiness. Standing rules pushed into the user turn get restated on every call and destroy the stable head a cache depends on, while per-request data injected above makes that head change every time. There is a behavioural difference too: instructions in the system turn read as the operator's configuration, whereas the same words in a user turn read as one participant's request and are weighed accordingly.

Examples teach shape faster than instructions do

A model matches what it is shown more reliably than what it is told, which makes worked examples the strongest instrument available and the easiest to misuse. Three or four deliberately varied examples establish a range. One polished example establishes a template that gets copied more literally than intended, down to its length and its headings.

Include at least one awkward case: an input missing a field, an ambiguous request, a situation where the right response is a clarifying question. That is what teaches the boundary. And keep examples consistent with the prose, because when the instructions ask for at most three sentences and every sample runs to six, the samples usually win and the result looks like the model ignoring you.

Say what to do, including in the cases you would rather skip

Two habits carry most of the improvement in production prompts. The first is positive instruction: describing the behaviour you want rather than cataloguing what to avoid, since a prohibition leaves the alternative unspecified and something has to fill the gap. The second is naming the escape hatch. A prompt that never says what to do with an input it cannot handle will get an answer anyway, because producing an answer is what the task asked for.

Explicitly permitting "the document does not contain this" turns a fabrication into a usable signal. Alongside it, give the reason behind a rule: a rule with a stated purpose extends to the case you did not anticipate, while a bare rule covers only the one you wrote it for.

Iterate against a fixed set, one change at a time

Prompt work without an evaluation set is indistinguishable from superstition. Assemble ten to twenty inputs resembling real traffic, including the ones that previously went wrong, write down what a passing output looks like, and run every candidate against the whole set rather than against the single example that provoked the edit.

Change one thing per iteration. A revision that reorders the instructions, adds two examples and tightens the output contract in one pass leaves you unable to attribute the result, and half of those edits may be doing harm under cover of the other half. When a prompt has accreted rules from a dozen incidents, the productive move is deletion followed by measurement rather than another clause.

Where candidates go wrong

Common questions