System Prompt vs. Message: What Goes Where
Test: would this instruction apply to *every* message in the conversation, or just this one?
| Goes in the System Prompt | Goes in the Message |
|---|---|
| Role / persona statement | The specific document, complaint, or data to act on |
| Tone and brand voice | A one-off request or question |
| Formatting rules that never change | Anything task-specific that varies run to run |
| Things Claude should never do | — |
Fix for generic/inconsistent tone: add a short, specific role statement ("You are X, writing for Y") — not more adjectives describing the tone, and not a sampling setting like temperature.
When to Add a Role vs. Examples vs. XML Tags
| Symptom | Fix | Why |
|---|---|---|
| Output is generic or tone drifts run to run | Role statement in the system prompt | Gives Claude a consistent perspective to filter instructions through |
| Output is inconsistent in structure/format despite detailed instructions | Multishot: 3–5 diverse worked examples in <example> tags | Shows the exact pattern instead of describing it in prose |
| Claude confuses an example (or other section) for the real input | Wrap each part in its own XML tag (<context>, <examples>, <input>, ...) | Removes structural ambiguity about where one section ends and the next begins |
| One prompt does 5 things shallowly / drops a piece | Task decomposition into ordered steps | Each sub-task gets full attention instead of being blended together |
Multishot Prompting Checklist
- Use 3–5 examples — not one repeated pattern, not a huge pile of edge cases.
- Diversity beats volume. Cover the range of situations Claude will actually face, not five near-identical variations.
- Wrap each example in its own
<example>tag so instructions and worked examples don't blur together. - Reach for examples when the problem is structure/format; reach for a role statement when the problem is tone.
- Distractor to reject: one long example that repeats the same pattern several times — that is not diversity.
XML Tag Conventions
Common tags: <context>, <instructions>, <examples> (containing individual <example> blocks), <input>. These are conventions, not a fixed schema — any consistent, clearly-labeled tag name works (<background>, <constraints>, <document>, <question>).
- Tag every distinct part of a multi-part prompt: background, rules, examples, and the live query.
- Useful even for moderately short prompts, not just very long ones, whenever more than one kind of content is mixed together.
- If Claude is responding to a worked example instead of the real request, the fix is tagging, not reordering the text or shortening the examples.
Matching Prompting Approach to Task Type
| Task Type | Prompting Approach | Distractor to Avoid |
|---|---|---|
| Analysis | Give explicit criteria up front — what dimensions matter, what a good answer weighs | Leaving criteria implicit and hoping Claude infers them |
| Research | Instruct Claude to cross-check claims and cite sources | Trusting ungrounded claims without a sourcing instruction |
| Drafting | Give examples plus a clear audience/role — aim for one finished artifact | Offering a menu of options when a single finished draft was wanted |
| Brainstorming | Ask for volume and range first; evaluate/narrow as a separate later step | Asking Claude to judge quality while it's still generating — narrows output prematurely |
Audience Framing & Task Decomposition Signals
Audience framing: name the reader's role, background, and purpose ("a general donor with no stats background who wants to know if the program worked") and ask for findings restated in plain, practical language. "Make it shorter/simpler" alone often just trims a still-jargon-heavy passage.
Decompose a request when:
- A later step needs the *actual output* of an earlier step, not just the original input (sequential dependency) — e.g. an email that must reference the analysis's real findings.
- The request spans genuinely different kinds of work (analysis, then drafting, then formatting) that tend to shortchange each other if done at once.
- Two forms count: numbered steps inside one prompt, or separate messages. Across-message is slower but catches a wrong turn before it propagates.
- Not every multi-part request needs this — two closely related, non-dependent parts ("summarize this and suggest a title") are fine as one prompt.
- Distractor: listing sub-tasks without ordering them does not solve a dependency problem.