Structure prompts with tags, roles and templates
Separate instructions from data with XML tags, use system and user messages well, and build reusable prompt templates.
- Use XML-style tags to separate instructions, context and input
- Know what belongs in system versus user messages
- Build prompt templates with variables, and keep them in version control
Real prompts mix instructions, background documents, examples and user input. Tags keep them apart so neither you nor the model confuses one for another:
<instructions>Classify the ticket. Reply with one label.</instructions>
<labels>billing, shipping, technical</labels>
<ticket>{{ticket_text}}</ticket>There’s nothing magic about the tag names - be consistent and refer to them (“the text in <ticket>”).
Message roles add another layer of structure. The system message (called developer in some APIs) holds the application’s standing rules - who the assistant is, what it must and mustn’t do. User messages carry the request and its data. Behavior that must hold across the conversation goes in the system message; variable content goes in the user turn.
Try it
System message or user message?
Where does each piece belong in a customer-support assistant?
“You are the support assistant for Acme Bikes. Answer only from the provided manual.”
“My rear brake squeaks when it rains - what should I do?”
“Never promise refunds; hand those requests to a human agent.”
“<manual_section>Brake maintenance…</manual_section> retrieved for this question”
“Respond in the customer’s language, in under 150 words.”
Templates
Production prompts are templates: fixed instructions with {{variables}} filled at runtime. Keep them in your codebase under version control, review changes like code, and test each version against your eval set before shipping (OpenAI’s prompting guide recommends the same). Put stable content first and variable content last - it also lets providers cache the stable prefix.
template = "<ticket>{{ticket}}</ticket>\nLabel:"
print(template.replace("{{ticket}}", "Charged twice for one order"))<ticket>Charged twice for one order</ticket> Label:
Key takeaways
Tags separate instructions, context, examples and input.
System message: standing rules. User message: the request and its data.
Treat prompts as versioned templates; stable parts first, variables last.
Lesson quiz
6 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: write Python
Write Python in the editor and run it against sample inputs. Python runs locally in your browser using a WebAssembly runtime.
Fill a prompt template
The first line is a JSON object of variables. The remaining lines are a template with {{name}} placeholders. Print the filled template. If any placeholder has no variable, print only error: missing variable NAME (the first one, in order of appearance).
- All variables present
- A missing variable
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Check a message list
Each line is role: content. A valid conversation has at most one system message, which must come first, then strictly alternating user and assistant messages starting and ending with user. Print valid: N messages or invalid: and the first problem: system message must come first, consecutive ROLE messages, must start with user, must end with user or unknown role ROLE.
- Valid
- Two users in a row
- Late system message
- Ends with assistant
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…