Advanced Prompting and Claude's "Personality": System Prompt, XML Tags, Letting the Model Think First, Structured Output

Today's Goals

1. Explain the division of labor between the system prompt and the user message, and write a reusable system prompt
2. Use XML tags to organize multiple passages, instructions, and examples into a long prompt Claude can read cleanly
3. Get Claude to analyze before answering, and use a JSON Schema to obtain structured output

All five days of this course are about one thing: how to work well with a teammate who is very capable but only knows what you told them. Today is about the telling. Once you have read this and finished the lab, scroll back to the top and tick off the three goals.

Plain-Language Walkthrough

The basics live in the prompting course; here we only cover Claude's four habits

Let me draw a boundary first. The generic craft of prompting — the four parts of task, context, constraints, and output format; giving a few worked examples so the model can copy the pattern (few-shot); asking the model to reason step by step (chain of thought) — is covered systematically in D1 of Prompt Engineering in 5 Days, and this course does not repeat it. If you have never practiced turning a vague request into a clear instruction, spend an hour there first and then come back.

This course has exactly one running analogy: a new teammate you have just hired. This teammate is strong — reads fast, writes fast, never complains about the hours — with one quirk: they only know what you told them, and they will guess at whatever you left out. Working well with a teammate like that has little to do with how forcefully you give orders and everything to do with how clearly you brief them. Claude as a teammate also has four specific habits, and life gets much easier once you know them:

1. It is very sensitive to a business card — say who it is in the system prompt and it will stay in that role all session.
2. It reads labeled material far more accurately than one wall of text, and XML tags are the delimiters it recognizes.
3. It is noticeably more reliable when it thinks before it speaks — so you have to leave it somewhere to think.
4. It can emit structured output that matches a JSON Schema exactly — your program consumes it directly, no regex required.

Today has six subsections: the first four take one habit each, the fifth folds all four into a reusable template set, and the last one explains how that template set gets used over the next four days. The example task that runs through the whole course also shows up today: add input validation and matching unit tests to an Express / FastAPI TODO API. Today we only use it to practice prompting; from D3 on, Claude Code will actually do the work.

System prompt: hand the teammate a business card instead of repeating their identity in every sentence

Picture taking a new colleague to meet a client. You do not preface every sentence with "as a backend engineer at our company, you…" — you hand them a business card at the door: who you are, who you represent, where today's boundaries lie. From then on, every sentence they say comes from the position on that card.

The system prompt is that card. Technically it is a separate system field in the Messages API request, distinct from the user messages in the messages array; Claude treats it as a premise for the whole conversation rather than as one turn inside it. That yields two practical differences. First, in a dense conversation, rules placed in system do not get diluted by dozens of later turns. Second, it is naturally the product side of things — persona, boundaries, and output style are maintained by you in one place, and nothing the user says in the conversation rewrites them.

A good card has three sections, always in the same order:

You are a senior Node.js backend engineer, responsible for reviewing and
completing an Express TODO API.
 
Boundaries:
- Only edit files under src/; do not touch migrations/ or package.json
- Do not introduce new dependencies other than zod
- If a requirement is unclear, ask first; do not guess
 
Output style:
- Answer in English; keep code comments in English
- For every change, first say what you are changing and why, then give the code

The three sections answer three questions: who you are (role), what you may not do (boundaries), and how you talk (style). Note that the boundaries section lists prohibitions rather than capabilities — the teammate already knows what it can do; what you have to state is the red lines it cannot know. In code, in both languages:

import Anthropic from '@anthropic-ai/sdk'
 
const client = new Anthropic() // reads ANTHROPIC_API_KEY from the environment
 
const SYSTEM = `You are a senior Node.js backend engineer reviewing and completing an Express TODO API.
Boundaries: only edit files under src/; no new dependencies other than zod; ask when a requirement is unclear.
Output style: answer in English; for every change, say what you are changing and why before giving code.`
 
const res = await client.messages.create({
  model: 'claude-sonnet-5',
  max_tokens: 1024,
  system: SYSTEM, // the card goes here, not into messages
  messages: [
    { role: 'user', content: 'POST /todos validates nothing at all right now. Tell me your plan first.' },
  ],
})
 
// The reply is a list of content blocks; text blocks have type 'text'
for (const block of res.content) {
  if (block.type === 'text') console.log(block.text)
}

import anthropic
 
client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from the environment
 
SYSTEM = """You are a senior Python backend engineer reviewing and completing a FastAPI TODO API.
Boundaries: only edit files under app/; no new dependencies other than pydantic; ask when a requirement is unclear.
Output style: answer in English; for every change, say what you are changing and why before giving code."""
 
res = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=SYSTEM,  # the card goes here, not into messages
    messages=[
        {"role": "user", "content": "POST /todos validates nothing at all right now. Tell me your plan first."}
    ],
)
 
# The reply is a list of content blocks; text blocks have type "text"
for block in res.content:
    if block.type == "text":
        print(block.text)

Where is the engineering cost? The system prompt is resent verbatim on every request, so the longer it is, the more input tokens every request carries. The card therefore has to stay lean: leave out anything derivable from the conversation, and leave out standard conventions of the language. This same criterion reappears on D3 when we write CLAUDE.md, because CLAUDE.md is essentially the system prompt of the Claude Code teammate. Another common mistake is stuffing things that change every time — the current time, the user's name — into the top of the system prompt, which completely defeats the prompt caching we cover on D2. Do not put a date on the business card.

XML tags: pack material, instructions, and examples into folders with names on them

Say you want the teammate to read a requirements doc, a chunk of existing code, and three test cases, and then write something to match. If you paste all four things together as one blob, they first have to spend effort working out which part is the requirement, which is the code, and which is the instruction to them — and getting that split wrong ruins everything downstream. Hand over four labeled folders instead and they know at a glance what each one holds.

The labels Claude recognizes are paired XML-style markers. This is not a hard syntax rule but an organizing pattern it saw a great deal during training: tags like <document>, <instructions>, and <example> separate content of different kinds cleanly, the model is measurably better at telling the boundaries apart, and it can more easily cite "item three in the document" in its answer. You can invent the tag names, as long as they are paired, semantically clear, and used consistently. The skeleton of a long input looks like this:

<context>
This is a TODO API written with Express. The routes live in
src/routes/todos.ts, and the data shape is in the schema below.
</context>
 
<schema>
type Todo = { id: string; title: string; done: boolean; dueAt?: string }
</schema>
 
<current_code>
router.post('/todos', (req, res) => {
  const todo = { id: nanoid(), ...req.body }
  store.push(todo)
  res.status(201).json(todo)
})
</current_code>
 
<instructions>
1. Use zod to validate the POST /todos request body: title is required and 1-200 characters; dueAt is optional and must be an ISO date
2. On a validation failure return 400 with a body shaped like { error: string, issues: [...] }
3. Give only the functions that need to change; do not rewrite the whole file
</instructions>
 
<example>
Input: { "title": "" }
Expected: 400, with error set to "invalid body"
</example>

Three details are worth memorizing. First, put the instructions after the material, especially when the material is long — a teammate who reads everything and then sees "here is your job" retains it better than one who reads the job first and then wades through thousands of lines; the official guidance for long documents is likewise document first, question last. Second, make it cite the tags in its answer: asking it to "quote the offending line from current_code first, then give the fix" makes the answer checkable. Third, tags are only delimiters — do not wrap every sentence to look professional. Three to six top-level tags is normal.

Someone will ask: can't Markdown headings and code fences separate sections just as well? They can, and Claude reads them fine. The difference is that XML tags are paired, with an explicit start and end, so when the material itself contains Markdown — you pasted in a README, say — nothing slides out of position. The messier the material you paste, the more this matters.

Letting the model think first: separate the analysis from the answer, so readers and programs each take what they need

Ask a teammate "should this endpoint be rate limited" and you can get two kinds of answer. One is an instant "yes." The other is "this endpoint gets three calls a second, has no authentication, and its downstream is a paid API, so yes." Even when the conclusion is identical, the second answer leaves you far more comfortable, because you can check the reasoning for anything it missed.

For a model this is not just about looking credible; it is a real accuracy difference. Making it write the analysis before the conclusion effectively gives it several more steps of computation before the answer is committed, and error rates drop noticeably on hard tasks. The mechanics are simple — give thinking and answering one tag each:

First, in an <analysis> tag, go through this item by item: which inputs in the
current code are unvalidated, what error each one can cause, and what rule you
intend to use to block it.
Then, in an <answer> tag, give only the final code; do not repeat the analysis.

The output now splits naturally in two. When a person is reading, show both sections; when a program consumes it, take only the <answer> section and keep the analysis out of the downstream flow. That is what "readers and programs each take what they need" means — you do not have to choose between wanting an explanation and wanting a clean result.

Let me clear up something that gets conflated. Newer Claude models have a built-in ability to think internally before answering; in the API it is called thinking, and it is adaptively enabled by default — the model decides how much a given question deserves. It neither conflicts with nor replaces the analysis section above. Thinking is the model's internal reasoning, and you control its depth (output_config.effort) rather than its content; the analysis section is reasoning you asked it to write down for you, so it is checkable, archivable, and usable as material in later turns. Easy questions need neither; hard questions want both; anything whose process must be auditable definitely needs an analysis section.

The cost is equally plain: the analysis section is output tokens, billed at output prices, and output is usually several times more expensive than input. So write the analysis section on demand — batch-classifying a thousand easy items with an analysis section is just burning money, while reviewing a contract or auditing a piece of security-sensitive code makes it mandatory. This trade-off is one of the focal points of today's interview questions.

Structured output: use a JSON Schema to get a result your program can use directly

When the teammate finishes something, you want a filled-in form in a fixed format, not a paragraph of prose you have to pick fields out of yourself. The old approach was to write "return only JSON, do not say anything else" in the prompt and then pray it would not prefix the reply with "Sure, here is the JSON:" — the prayers failed often enough that everybody has written a regex to dig JSON out of a reply.

Claude now accepts a JSON Schema directly as a request parameter (output_config.format), and the output is constrained-decoded into JSON that strictly matches that schema: every field present, types correct, no extra chatter. Both official SDKs offer a parse method so you can define the type with zod or pydantic and get a parsed object back:

import Anthropic from '@anthropic-ai/sdk'
import { zodOutputFormat } from '@anthropic-ai/sdk/helpers/zod'
import { z } from 'zod'
 
const Review = z.object({
  missing_validations: z.array(z.string()), // which fields are unvalidated
  severity: z.enum(['low', 'medium', 'high']),
  suggested_tests: z.array(z.string()), // which tests to add
})
 
const client = new Anthropic()
const res = await client.messages.parse({
  model: 'claude-sonnet-5',
  max_tokens: 1024,
  messages: [
    {
      role: 'user',
      content: `<current_code>
router.post('/todos', (req, res) => { store.push({ id: nanoid(), ...req.body }); res.status(201).json(req.body) })
</current_code>
Review the input validation in this code.`,
    },
  ],
  output_config: { format: zodOutputFormat(Review) }, // schema as a parameter, not in the prompt
})
 
const review = res.parsed_output // already typed as Review; no JSON.parse
console.log(review?.severity, review?.missing_validations)

from pydantic import BaseModel
from typing import Literal
import anthropic
 
 
class Review(BaseModel):
    missing_validations: list[str]  # which fields are unvalidated
    severity: Literal["low", "medium", "high"]
    suggested_tests: list[str]  # which tests to add
 
 
client = anthropic.Anthropic()
res = client.messages.parse(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": """<current_code>
@app.post("/todos", status_code=201)
def create(body: dict):
    store.append({"id": uuid4().hex, **body})
    return body
</current_code>
Review the input validation in this code.""",
        }
    ],
    output_format=Review,  # schema as a parameter, not in the prompt
)
 
review = res.parsed_output  # already a Review instance; no json.loads
print(review.severity, review.missing_validations)

A few boundaries to know. The schema supports the common shapes — objects, arrays, enums, constants, optional fields — but not recursive structures, numeric ranges (minimum / maximum), or string length limits; those checks belong in your own code. Structured output and citations (D2) cannot be enabled at the same time. Also, once you ask for structured output there is nowhere left to put an analysis section, so "think first" has two landing spots here: either add an explicit reasoning field to the schema and place it before the other fields (the model generates it first, which behaves much like an analysis section), or rely on the model's internal thinking. Batch extraction, classification and tagging, turning unstructured text into a table — reach straight for structured output; anything that needs a long explanation for a human still wants tagged sections.

Fold the four habits into a template set you will use every day from D2 on

That is all four habits: the business card (system prompt), the labeled folders (XML tags), thinking before speaking (the analysis section), and filling in the form (structured output). They are not four mutually exclusive techniques but four parts that can all appear in the same prompt. Together, one complete briefing looks like this:

• system: the three-section card, a paragraph or two, containing nothing that changes between requests.
• The user message: material first (one tag per piece), then instructions, then examples; if you want to see the reasoning, the instructions ask for separate analysis and answer sections.
• Request parameters: pass a schema when a program consumes the result, and skip it when nothing does.

Today's lab is to write each of those four parts as a template with blanks, then fill them in once against the example task. This template set is not homework — it is for your own use over the next four days. On D2 the prompt for reading a PDF will use "material first, instructions last." On D3, writing CLAUDE.md, you will find it is exactly a business card handed to Claude Code, and the trim-until-you-cannot criterion is identical to today's criterion for a system prompt. On D4, the "procedure" in a SKILL.md is the analysis section and the instruction section combined. And on D5, when you run CI with claude -p, what --append-system-prompt carries is precisely the card you write today.

One last thing. All four habits are about how to brief, but briefing well only solves half the problem: the teammate understood you, and whether what came out is correct still needs checking by someone. The second half of this course shifts its center of gravity from how to say things to how to make it verify its own work — that is the watershed that turns Claude from a chat tool into a production tool.

Source Reading

Hands-On Lab

This is a documentation-style lab: nothing to run, and the deliverable is four Markdown templates. The templates in starter/ have blanks left in them, and solution/ is a worked example. Read the solution once, then go back to the starter and write your own — copying the solution straight across defeats the purpose, because this template set will eventually hold the business card for your own project rather than the course's TODO API.

1. Open system-prompt.md in the starter and fill in the three sections: role, boundaries, output style. Read it through once and delete any sentence the model already knows.
2. Open long-input.md and put the example task's requirement, existing code, and test cases each in their own tag, with the instructions last. Count your top-level tags and check that you are in the three-to-six range.
3. Open think-first.md, name the analysis and answer tags, and write one line about which section the program parses. Decide what task complexity this template actually suits.
4. Open structured.md and write a minimal JSON Schema for a code review result (at least three fields, one of them an enum). Confirm the prompt body no longer describes the format.
5. Run all four filled-in templates once in any Claude client or the API playground. Watch whether the output splits into sections and whether it matches the schema, and fold anything you dislike back into the template.

Interview Questions

Today's 3 questions are in the question bank below, weighted toward the responsibilities of the system prompt, why XML tags work well for Claude, and the trade-off between structured output and thinking. Expand each one and read the analysis before the key points — practicing the derivation beats memorizing bullets. The high-frequency labels for the domestic and overseas markets are there so you can pick by target market.

Checklist and Tomorrow

• Explain the division of labor between the system prompt and the user message, and write a reusable system prompt
• Use XML tags to organize multiple passages, instructions, and examples into a long prompt Claude can read cleanly
• Get Claude to analyze before answering, and use a JSON Schema to obtain structured output
• State the difference between the analysis section and the model's internal thinking, and the billing cost of each
• All 5 acceptance criteria of the lab pass
• Answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D2) we call Claude from code for the first time: feed it a whole PDF of several dozen pages, get back a summary with page-numbered citations, and then use prompt caching to cut the cost of repeated questions by an order of magnitude. Today's "material first, instructions last" applies directly, and when we get to the prefix semantics of caching you will see exactly why "do not put a date on the business card" matters. We learn briefing before we learn feeding material because the cost of a vague briefing gets multiplied many times over once the material grows.