ExamworthyExamworthy
Open the appStart free

CCDV-F - Prompt and Context Engineering - Section 6.2

Write and iterate on prompts using established prompt engineering principles.

Published skill weight 4.6 percent. Covers instruction clarity, few-shot examples, system versus user placement, output constraints, where a prompt or instruction should sit across the components of a system, iterative refinement, prompt adjustment and input sanitisation when writing and revising prompts for Claude.

instruction clarityfew-shot examplessystem versus user placementoutput constraintsiterative refinementinput sanitisation

Practice question for this objective

Free samplePrompt and Context Engineeringmedium

A team improving a ticket triage prompt made four edits in one release: it added a block of worked examples, rewrote the role sentence, moved the operating rules from the user turn into the system prompt, and added an explicit output contract. Accuracy on a fixed labelled set of 200 tickets rose by six points, and cost per request rose by about a third, driven by the example block. Finance holds a per-request ceiling, and the team must establish which edits earn their cost before the release goes wider. How should the team proceed?

  • AShip all four edits together and watch live accuracy for a month, on the basis that the combined result already clears the agreed accuracy bar for the assistant.
  • BRemove the example block alone and re-run the labelled set, keeping the block out of the prompt if accuracy holds within one point of the combined result.
  • CRe-run the labelled set with the edits applied one at a time from the original prompt, so the effect of each edit on accuracy and on cost is measured separately. Correct
  • DAsk the assistant to review the four edits and explain which of them it found most influential on its own answers, then drop the edits it does not name.
Iterate a prompt one change at a time against a fixed scored set, so each edit's effect on both accuracy and cost is attributable. Four simultaneous edits produce one aggregate number that cannot be decomposed, so the team cannot tell which change earned the six points or whether the expensive example block contributed at all. Re-running the same labelled set with one edit applied per run isolates each effect and pairs it with its own token cost, which is what the per-request ceiling requires.

Why A is wrong: Tempting because the combined measurement is real and the bar is met, but it keeps whatever share of the extra cost buys nothing, and live traffic gives no way to attribute the gain to any one edit.

Why B is wrong: Tempting because it isolates the expensive edit and would answer the cost question, but it leaves the other three edits unattributed, so a change that harms accuracy stays hidden inside the bundle.

Why C is correct: Correct because changing one element per run against a fixed scored set is what makes an effect attributable, and it prices each edit so a costly one that adds little accuracy can be dropped.

Why D is wrong: Tempting because the model can produce a fluent account of its own behaviour, but that account is generated text rather than a measurement, and the team already holds a scored set that settles the question.

See more CCDV-F practice questions, answers explained.

More in this domain

Back to all Prompt and Context Engineering objectives, or the CCDV-F cert hub.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.