🏗️ Structural patterns
In the previous module, you opened the note and saw its parts. Now let's look at the form of these pieces: how professionals put in order a system prompt to make it clear, organized, and easy to maintain. There are five "templates" that appear in almost every real prompt — and a warning about when no use the most famous one.
Detailed content
The Identity Block: "You are..."
Almost every system prompt in the world starts with the same two words: "You are..." ("You are..."). It's the first line, and it does a huge amount of work: it anchors who the AI is before any rule. Without that anchor, the AI drift — changes personality mid-conversation, makes up tools it doesn’t have, talks about things it doesn’t know as if it did.
🪪 The idea in one sentence
The Identity Block answers three questions right at the beginning: who is the AI, where she operates and what she knows (including the limits of her knowledge). It’s the “anchor” that everything else in the prompt refers to.
Think of an employee’s ID badge on their first day: name, job title, department. In three lines, everyone (including the AI itself) knows who they’re talking to. No biography — just the essentials to establish its self-image.
You are ChatGPT, a large language model trained by OpenAI, based on GPT 5.5.
Knowledge cutoff: 2025-08
Current date: 2026-06-01
The three canonical elements in three lines: persona ("You are ChatGPT..."), knowledge cutoff e today's date. Clean, short, no fluff.
You are Perplexity Computer.
Your goal is to solve as many things on your own as possible. Use tools to answer your own questions and explore.
Here, the identity comes with the goal pasted together: who you are + what you came to do. "Solve as much as possible on your own" isn't a rule by itself — it's the mission that gives meaning to all the other instructions.
✓ WITH a good identity at the top
- ✓AI maintains the same persona from beginning to end
- ✓Knows what it can and can’t do
- ✓Doesn’t make up facts after the cutoff date
- ✓Short: 3 to 5 lines, just who/where/when
✗ NO identity (or buried in the middle)
- ✗"Turns into" another AI mid-conversation
- ✗Claims to have tools that don’t exist
- ✗Responds about events it doesn’t know about
- ✗Bloated with backstory that no one uses
The Capabilities Statement: What It Can Do
Right after saying who yes, a good prompt says what the AI can do. It seems obvious, but it's the step most people forget—and the result is an AI that offers to generate an image it doesn't know how to generate, or that ignores a tool it had all along. The Capabilities Declaration is the list of superpowers of the AI, each with its own rule for when to use it.
What it is
A section that lists each capability with three things: what it does, when to use e a condition/limit ("if the user asks...", "only when it's urgent..."). The secret is that capability without conditions turns into a mess: the AI ends up using the right tool at the wrong time.
Why learn
Because “giving powers” isn’t enough—you also have to teach when use them. The difference between an AI that fumbles around and one that executes directly is here. And note: every real capability comes with a embedded condition, and that’s what keeps the AI from barreling ahead.
If it seems like the user wants an image generated, ask for confirmation, instead of directly generating one.
See how the capability (“generate image”) already comes with the protocol ("ask for confirmation first"). It's not just "you can generate images" — it's when e how. This is a clearly defined capability.
def concise_search(query: str, max_num_results: int = 3):
"""Does a search for the query and prints up to the max_num_results results."""
Google declares capabilities such as function signatures: the scope, parameters, and even the default value (max_num_results = 3) are unambiguous. There’s no doubt about what can be done.
Identity ≠ Capabilities (don’t confuse them)
A Identity says who the AI is; the Capability Declaration says what she can do. In plain chat, without tools, this section becomes "what I no I can do that” — short, but useful so the AI doesn’t promise what it can’t deliver.
The XML Compartment: each topic in its own drawer
Imagine a thousand-line prompt written as one huge block of text without paragraphs. Finding a rule in there would be a nightmare. The solution the labs adopted is simple and powerful: put each topic in its own labeled “drawer”. These drawers are the XML tags — <tone_and_style>, <tool_calling>, <safety> — and they make the prompt navigable. It’s the diagram at the top: stacked blocks, each with its own name.
1. The opening tag— <tone_and_style>
Marks the beginning of the drawer and names it.
The tag’s name works as etiquette: the AI "pulls" the right block at the right time. When the conversation calls for a certain tone, it goes straight to the drawer tone.
2. The content — the rules for that subject
Everything related to tone (and tone alone) lives here.
Don't mix them: a safety rule doesn't belong in the tone drawer. Each topic isolated — that’s what makes the prompt easy to read and edit.
3. The closing tag — </tone_and_style>
Close the drawer. The next drawer (another topic) starts right below.
With clear beginnings and endings, you can replace an entire drawer without touching the others — and you can compare two versions of the prompt and say exactly "the tone block changed".
<tone_and_formatting>
- Only use emojis if the user explicitly requests it...
</tone_and_formatting>
<tool_calling>
You have tools at your disposal...
</tool_calling>
To change the tone policy, edit only the first block—the rest stays intact. The tags are flat (side by side), not nested one inside another. We’ll return to the word "flat" in Topic 6.
Why this helps people, not just AI
A compartmentalized prompt becomes navigable by a team. You can “code review” a block, compare versions, and say “Anthropic removed the block <search_first>" — a precise sentence. Without the drawers, it would be "something changed somewhere".
The Rule by Example: show instead of describe
"Format the citations appropriately." Appropriately how? This sentence allows a thousand interpretations—and the AI will choose one, probably the wrong one. The template that solves this is simple: show an example instead of (just) describing. A concrete example clears up ambiguity all at once in a way three paragraphs of explanation can’t.
🎯 Show > describe
AI matches patterns much better than it follows verbal specifications. Instead of explaining a format in prose, you paste an example of what’s right (and, even better, a pair right × wrong). The example carries the rule — sometimes even before the prose explains it.
It's the difference between saying "assemble the furniture correctly" and design the assembled piece of furniture. The design leaves no doubt.
The anchor text must be the source name, publication, or a natural descriptive phrase — never a generic word like "source" or "link", and never a raw URL.
WRONG: "The population grew 5% ([source](https://...))”
RIGHT: "The population grew 5% ([World Bank](https://...))”
RIGHT: "According to [World Bank data](https://...), the population grew 5%”
Notice the engineering: the rule in prose ("the link text must be source name, never a generic word like 'source' or 'link'") would already be good — but it’s reinforced by a pair WRONG/RIGHT that shows exactly what’s wrong and what’s right. Impossible to misinterpret.
Example: <database url="URL" inline>Title</database>
Example: <database url="URL" locked>Title</database>
Two example lines replace an entire paragraph describing attributes. The AI sees the format and copies it pattern — not the literal word.
✓ Example used well
- ✓Shows the format and the mechanics
- ✓Use a WRONG/RIGHT pair
- ✓It’s short—a shortcut, not an encyclopedia
- ✓Make it obvious what to “fill in here”
✗ The danger: overfitting to the example
- ✗AI copies the example literally
- ✗Treats the list of examples as exhaustive
- ✗Example as long as the expected output
- ✗Use an example to judgment (locks down)
Naming blocks: the name itself is an instruction
Here’s a lovely detail that’s easy to miss: the name you give a block also teaches the AI. It’s not just an administrative label. Change the name — even if the content stays the same — and the AI starts behaving differently. There’s a real case from Anthropic that proves this in an almost poetic way.
<claude_prioritizes_copyright_compliance>
<core_copyright_principle>
The hard rule on the inside remains the same (“Copyright compliance is NON-NEGOTIABLE”). Only the block name changed: from compliance ("follow the rules") to principle ("respect intellectual property").
🧠 Why this changes everything
"Compliance" is a order: the AI follows it only in the listed cases. "Principle" is a value: the AI reasons from it and covers even cases no one anticipated. The name changes the AI's posture toward a new situation.
In other words: the block name is the first line the AI reads about that topic—and it already "gets in the right mindset" because of it. That's why choosing good names is part of the work, not decoration.
Name it by value, not mechanics
Prefer <respects_user_privacy> a <privacy_rules_v2>. The first name says why and invites the AI to reason; the second is just a soulless drawer. This principle returns in force in Module 1.6 ("from rule to principle").
When NOT to use XML (yes, sometimes it gets in the way)
After so much praise for XML drawers, here comes the honest counterpoint: not every prompt needs them. Too much structure in the wrong place becomes ceremony — it just gets in the way. Knowing when to no using a template is just as important as knowing how to use it. Here are the three cases where XML is overkill.
⚠️ The three cases where XML is unnecessary
- ① Short prompt (fewer than ~50 lines). If it fits on one screen, tags become decoration. A single-task request doesn’t need a drawer—write it directly.
- ② When Markdown already does the job. Coding agents (like Claude Code) use # Headings in Markdown instead of XML—it serves the same purpose of separating topics and feels more natural there.
- ③ Deeply nested tags. Real prompts keep the blocks plans — rarely go beyond 2 levels. Nesting drawer inside drawer inside drawer turns into a maze.
✓ XML makes sense when...
- ✓The prompt is long (many topics)
- ✓It will be versioned and maintained by a team
- ✓You want to compare versions block by block (diff)
- ✓Some policies benefit from a clear boundary
✗ XML is unnecessary when...
- ✗It’s a short instruction for a single task
- ✗Markdown with headings already provides good organization
- ✗You caught yourself nesting 3+ levels of tags
- ✗The structure took up more space than the content
The rule of thumb
Structure exists to serve clarity, not the other way around. If the drawer makes the prompt more easy to read and maintain, use it. If it only adds noise, remove. The template is a tool—you control it, not the other way around.
📝 Module Summary
- ✓O Identity Block ("You are...") anchors who/where/when right on the first line
- ✓A Capability Declaration list what the AI can do — each with its condition
- ✓O XML compartment puts each topic in a named drawer (<tag>), flat and modular
- ✓A Rule by Example shows the format (WRONG/RIGHT pair) instead of just describing it
- ✓O block name is also an instruction: compliance (order) vs. principle (value)
- ✓Not every prompt needs XML — in short text or code, it becomes ceremony
➡️ Next Module
1.4 — 🎚️ Behavioral patterns. You already have the form of the blocks. Now let's move on to content: how to write the rules inside them—with reasons, with always/never contrasts, with a concision budget—so the AI doesn’t just obey, but to understand.