Anatomy of a prompt

The parts every reliable prompt has: a role, a clear task, the context the model cannot guess, explicit rules and the shape of the answer.

What a prompt is

Also called prompt, prompting

What: A prompt is everything the model reads before it answers: the system prompt, earlier messages, pasted documents and your latest request.
Why: The model only knows what is in the prompt plus its training, so every missing detail becomes a guess.

Watch out

Treating the model like a colleague who shares your context, then blaming it for guessing.

System prompt

Also called system message, instructions

What: A message sent before the conversation that sets the role, tone, rules and constraints for every reply. APIs take it as a separate field.
Why: Rules placed there apply to the whole conversation, so users do not have to repeat them and cannot easily drift from them.

Code

You are a senior Python reviewer for a student team.
Reply in British English, under 200 words.
If the code is fine, say so in one line.
Never rewrite whole files: show only changed lines.

Role prompting

Also called persona, act as

What: Telling the model who it is, such as "You are a database engineer reviewing schema changes", to steer vocabulary, depth and priorities.
Why: A specific role pulls in the right assumptions; a vague one like "You are helpful" adds nothing.

Watch out

Expecting a role to add knowledge the model does not have: it changes style and focus, not facts.

Be specific and direct

Also called clear instructions

What: State the goal, the audience, the length, the format and what "done" looks like, as if briefing a smart new hire on day one.
Why: Vague prompts get average answers. Specific ones get answers you can use without a second round.
Example: Weak: "Summarise this." Strong: "Summarise this RFC in 5 bullet points for a backend developer, each under 20 words, ending with the one open question."

Give the why and the context

What: Explain the purpose behind a rule and include the facts the model needs: the stack, the data, who reads the output and what it will be used for.
Why: Models generalise from reasons. "No bullet points, this is read aloud by a voice app" works better than "no bullet points".

Delimiters and XML tags

Also called tags, separators

What: Wrapping each part of the prompt in clear markers such as <document>, <instructions> or triple quotes so the model knows what is data and what is instruction.
Why: Clear boundaries stop pasted text from being read as instructions and let you say "use only what is in <document>".

Code

<instructions>
Extract every deadline from the email.
Return one line per deadline: date, task.
</instructions>

<email>
{{EMAIL_TEXT}}
</email>

Say what to do, not only what not to do

What: Phrase rules positively: "Write in flowing paragraphs" instead of "Do not use Markdown".
Why: A list of bans tells the model what to avoid but not what to aim for, and it sometimes repeats the banned thing anyway.

Watch out

Writing ten "never" rules in capitals: shouting makes models over-apply rules in odd places.

Prompt templates and variables

Also called placeholders, prompt template

What: A fixed prompt with slots such as {{QUESTION}} that your code fills in for each request.
Why: Templates keep the tested wording stable, make prompts reviewable in Git and separate instructions from user input.

Watch out

Building prompts by string concatenation all over the codebase, so nobody knows which wording is live.

Go deeper