Overview
A system prompt sets standing role and behavioral context for an entire conversation, even a single sentence measurably shapes tone and focus, in a way the same instruction repeated in a user message doesn't, because the model treats system-level framing as persistent context rather than part of the back-and-forth exchange. Beyond role-setting, the single most reliable lever for output format, tone, and structure is few-shot (multishot) prompting: official guidance specifically recommends 3-5 examples that are relevant to the real use case, diverse enough to avoid teaching an accidental incidental pattern, and clearly structured, typically with tags, so the model can distinguish example content from instructions. For genuinely complex prompts mixing instructions, context, examples, and variable input in one block, wrapping each kind of content in its own consistently-named tag removes the ambiguity of inferring those boundaries from phrasing alone.
Quick Reference
| Technique | What it does | Guidance |
|---|---|---|
| System prompt | Sets persistent role/behavior for the whole conversation | Even one clear sentence measurably changes output |
| Few-shot / multishot examples | Steers output format, tone, structure | 3-5 examples: relevant, diverse, structured |
| XML-style tagging | Marks where instructions/context/examples/input begin and end | Use consistent, descriptive tag names |
Syntax
{
"model": "claude-sonnet-5",
"system": "You are a helpful coding assistant specializing in Python.",
"messages": [{ "role": "user", "content": "How do I sort a list of dictionaries by key?" }]
}Examples
<!-- Structuring a prompt with tags removes ambiguity about where
instructions end and the actual input to process begins. -->
<instructions>
Classify the ticket below as bug, feature, or question.
</instructions>
<examples>
<example><input>App crashes on login</input><output>bug</output></example>
<example><input>Add dark mode</input><output>feature</output></example>
<example><input>How do I reset my password?</input><output>question</output></example>
</examples>
<input>{{ticket_text}}</input>Diversity in examples matters as much as relevance
Three near-identical examples can teach the model an accidental, unintended pattern (formatting quirk, incidental phrasing) instead of the actual rule you meant to demonstrate. Vary the examples enough to cover real edge cases, not just the happy path.
Visual Diagram
Common Mistakes
- Repeating role/behavior instructions in every user message instead of setting them once in the system prompt.
- Using only one example, or several nearly identical ones, and inadvertently teaching an incidental pattern rather than the intended rule.
- Mixing instructions, context, and input in one undifferentiated block of text on a complex prompt, forcing the model to infer boundaries from phrasing alone.
- Adding more and more instructions to fix an output-format problem that a few well-chosen examples would solve more reliably.
Performance
- Every example and every tag adds real tokens to the request, counting against the context window and cost; 3-5 well-chosen examples is a deliberate balance point, not an arbitrary minimum.
- A well-structured, tagged prompt reduces the model's own effort spent inferring intent, which in practice shows up as more consistent output, not primarily as latency.
Best Practices
- Set role and standing behavioral context in the system prompt, not repeated per turn in user messages.
- Choose 3-5 examples that are relevant to the real use case and diverse enough to cover edge cases, not just near-duplicates of the happy path.
- Wrap distinct kinds of prompt content, instructions, context, examples, input, in their own consistently-named tags once a prompt grows complex.
- Reach for better examples before reaching for more instructions when output format or consistency is the actual problem.