All modules
MODULE 02~14% of exam · 50 min read

Prompt Engineering & System Design

Structure, examples, reasoning, and prefill — turning instructions into reliable behaviour.

1 of 5

Anatomy of a production prompt

Role, task, context, rules, examples, output contract — in that order.

A production prompt is a specification, not a wish. The reliable structure is: (1) role and objective, (2) durable rules and constraints, (3) reference context or documents, (4) worked examples, (5) the specific task, (6) the output contract. Steps 1, 2 and 4 belong in the system prompt because they are stable across turns; steps 3, 5 and 6 usually belong in the user turn.

Claude responds strongly to structural delimiters. Wrapping distinct sections in XML-style tags (<documents>, <rules>, <example>, <question>) removes ambiguity about where one region ends and the next begins, which is the single highest-leverage formatting change for long or multi-part prompts.

<rules>
Never invent a policy number. If a policy is not in <documents>, say so.
</rules>

<documents>
{{retrieved_chunks}}
</documents>

<question>{{user_question}}</question>

Answer in <answer> tags. Cite the document id for every claim.
Positive instructions beat prohibitions

'Respond in three short paragraphs of plain prose' outperforms 'don't use bullet points and don't be verbose'. Tell the model what to do; a prohibition still puts the forbidden concept in context.

Exam-ready takeaways
  • System prompt = stable identity, rules and examples. User turn = the variable task.
  • XML-style tags disambiguate sections far more reliably than prose headings.
  • State desired behaviour positively; avoid stacking negative constraints.
divider
Next module · Context Engineering