🧩 The parts of a prompt
In the previous module, you discovered that an invisible note exists. Now let's open this note and see the pieces inside. A good system prompt isn't one long block of text — it's a kit of interlocking pieces: identity, tone, tools, safety, and priority. You'll learn what each piece does and how they fit together, all with examples real from real prompts.
Detailed content
Identity: who the AI is
The first piece — and the most important — is the identity. Almost every system prompt in the world starts with two little words: "You are..." ("You are..."). In one sentence, the AI already knows who it is, who it works for, and what it came to do. It's the anchor: everything that follows in the note rests on it.
🪪 The idea in one sentence
Identity is the badge of the AI. Without it, the AI "drifts": it changes character in the middle of the conversation, invents abilities it doesn't have. That's why it goes in the top and in just a few lines — it's an anchor, not a biography.
✓ Strong identity (at the top)
- ✓Stays in the right character throughout the conversation
- ✓Knows what it is and what it came to do
- ✓Short and clear — an anchor, not a biography
✗ Weak identity or buried
- ✗"Turns into" another character mid-chat
- ✗Invents tools that don’t exist
- ✗Useless backstory buries what matters
You are an AI coding assistant, powered by {model_name}.
You operate in Cursor.
You are a coding agent in the Cursor IDE that helps the USER with software engineering tasks.
Three lines, three pieces of information: who it is ("coding assistant"), with what ({model_name}) and where it is ("in Cursor"). The AI doesn't memorize which model is running — Cursor fills in the {model_name} placeholder at the time.
What it is
The part that states, right at the opening, who the AI is (product + function), who it works for and the limits of what it knows. It's the only piece that appears in all the actual prompts, without exception.
Why learn
Because it’s the part that most "keeps" the AI in the right character. When an AI "forgets who it is" in the middle of a conversation, or claims it can do things it can’t, the problem is almost always a weak identity or one buried at the bottom of the note.
Tone: how the AI speaks
The second piece is the tone — the way of speaking: formal or casual, with or without emoji, wordy or direct. Identity says who she is; the tone says how she expresses herself. It’s the difference between a bank teller and a friend explaining something to you at a bar: the same language, completely different “tones.”
<tone_and_style>
- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
- Do not use a colon before tool calls. ...text like "Let me read the file:" ... should just be "Let me read the file." with a period.
</tone_and_style>
Notice how the tone shifts as you get specific: no emoji without being asked, and even the rule not to use colons before an action. Tone isn't just "be nice" — it's concrete writing choices.
What it is
The part that defines the way of speaking: level of formality, emoji use, response length, formatting. It's what gives the AI its "voice"—and what most changes how it feels to talk with it.
Why learn
Because it’s the part you most feels. “Why does this AI sound so robotic?” “Why does that one fill everything with emojis?” It’s all in the tone block. Knowing it exists shows you that an AI’s “personality” is a choice — and a choice you can change.
Tone goes hand in hand with honesty
Many prompts combine “how to speak” and “how to be honest” in the same block — for example, not pretending to be certain when you aren't, not making up facts. It makes sense: both are about the way to communicate with you. Tone isn’t just style; it’s also the stance of telling the truth the right way.
Tools: what the AI does
Some AIs just chat. Others do things: read files, search the web, run commands. These actions are the tools. But providing a tool isn't enough—the AI needs to know when e how use each one. This piece is the tools’ “user manual.”
1. List what exists
AI needs to know what tools it has at hand. Without the list, it ignores a useful resource or invents one that doesn't exist— like an unlabeled toolbox.
2. Say when to use each one
Each tool comes with a usage condition. Cursor says to use the right tool for each thing — and no use terminal commands to read or edit files when there’s a dedicated tool for that.
3. Set the order (prerequisites)
Sometimes one action can only happen after another. "Read before editing" is the classic example: the AI needs read the file at least once before changing it — otherwise you're editing blind.
1. Don't refer to tool names when speaking to the USER. Instead, just say what the tool is doing in natural language.
2. Use specialized tools instead of terminal commands when possible... don't use cat/head/tail to read files, don't use sed/awk to edit files...
// in <making_code_changes>:
1. You MUST use the Read tool at least once before editing.
Three contracts at once: don’t cite the tool's name for the user, use the right tool (not the terminal for everything), and read before editing. Each tool has its own “when” and “how.”
What it is
The part that states the actions of the AI (read, search, edit, run) and the rules for using each one: when to call it, in what order, and what to avoid. It exists mostly in AIs that "do," such as coding assistants.
Why learn
Because it’s the difference between an AI that talks about one task and one that runs the task. And this is where the most annoying errors live: the AI that edits a file without reading it first, or uses the wrong tool. Good tool rules prevent that.
Safety: what AI doesn’t do
Just as important as saying what the AI should doing is saying what it shouldn’t. This is the piece of the safety: the guardrails. Some prevent serious harm (not helping with something illegal); others prevent small but annoying damage (creating files for no reason). Every reliable AI has this block of "brakes".
NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one.
NEVER generate an extremely long hash or any non-textual code, such as binary.
See the pair NEVER ... ALWAYS ...: the AI is prohibited from creating files unnecessarily and encouraged to prefer editing. It’s a barrier that keeps the project tidy—protection, not censorship.
✓ WITH a security block
- ✓Politely refuses dangerous requests
- ✓Doesn’t create files or clutter unnecessarily
- ✓Doesn’t make up facts with false certainty
- ✓Knows where the limits are — and respects them
✗ NO safety block
- ✗Agrees to any request, including harmful ones
- ✗Makes destructive changes without thinking
- ✗Confidently states things it doesn’t know
- ✗Has no brakes—and you find out too late
What it is
The part about safeguards: what the AI refuses, what it never does, and how it acts when in doubt. It ranges from serious (not helping with a crime) to practical (not creating files needlessly). It's the "brake" in the note.
Why learn
Because it’s what makes the AI reliable. “Why did it refuse to do that?” The answer is almost always here. And because it reveals an important truth: an AI without brakes isn’t “freer” — it’s just unpredictable and risky.
Priority: what takes precedence in a conflict
What if two instructions if they clash? The safety block says "don't do X," but the user asks for X. Which takes precedence? That's what the priority: it defines the command order—who wins when there's a conflict. Without it, the AI gets lost in the conflict.
🪜 The chain of command (Grok example)
- ① Central policy (top). The most important safety rules come first — "these have the highest precedence." Nothing overrides them.
- ② System message. The rest of the system prompt comes next: identity, tone, tools. It governs almost everything—except where it conflicts with the top-level policy.
- ③ User message (you). Your requests come later. AI is happy to help you—as long as they don’t conflict with the two layers above.
<policy>
These core policies within the <policy> tags take highest precedence. System messages take precedence over user messages.
* Do not provide assistance to users who are clearly trying to engage in criminal activity.
</policy>
In two sentences, three levels: policy > system > user. The piece itself announces that it's at the top of the ladder — that's why it goes right at the beginning of the prompt.
Think of a company
A law (policy) is above everyone else. The company rules (system) apply day to day. And the a client's request (you) get served — as long as it doesn’t break the law or the house rules. The AI follows exactly this ladder.
How the pieces fit together: the XML compartment
You’ve seen the five pieces. One final question remains: how do they fit organized inside the ticket? Imagine throwing identity, tone, tools, safety, and priorities all into one giant wall of text with no separation. It becomes an impossible mess to maintain. The solution professionals use is the XML compartment — named drawers, one for each piece.
🗂️ Labeled drawers
Each piece goes into a named “drawer” — a tag an opening and a closing, like <tone_and_style> ... </tone_and_style>. Look at the SVG above: the separate pieces (left) each go into their own drawer and form the entire prompt (right).
The drawers stay side by side (without nesting one inside another). That way, to change the tone, you open only the tone drawer — everything else stays intact. That’s what keeps a giant prompt easy to edit.
<tone_and_style>
- Only use emojis if the user explicitly requests it...
</tone_and_style>
<tool_calling>
You have tools at your disposal to solve the coding task...
</tool_calling>
<making_code_changes>
1. You MUST use the Read tool at least once before editing...
</making_code_changes>
Three drawers, three subjects: tone, tools e code changes. Each with its own name and content, side by side. To change the tone rule, you edit only the first drawer — the others don't even notice.
The drawer’s name helps you (and the AI)
The tag <making_code_changes> already says, just by its name, what that block is about. This helps AI separate topics — and helps writers find, compare versions, and remove an entire piece without rereading everything. A drawer without a label is a drawer no one can find. The name is part of the instruction.
📝 It's not always XML
Short prompts (a few lines) don’t need drawers — that would turn into a ceremony. And some coding assistants use Markdown headings (like # Section) in place of XML tags, serving the same purpose: clearly separating topics. The important idea is compartmentalization, not the tag itself.
📝 Module Summary
- ✓A prompt is a kit of parts easy to fit together, not one wall of text
- ✓Identity ("You are...") says who the AI is — it's the anchor at the top
- ✓Tone says how it speaks — formal, emoji, length (goes hand in hand with honesty)
- ✓Tools say what it does — and when/how (e.g., read before editing)
- ✓Safety says what it doesn’t do, and priority says who has authority in a conflict
- ✓The pieces fit together in named buckets (compartment XML), side by side
➡️ Next Module
1.3 — 🏗️ Structural patterns. Now that you know the parts, let’s look at the templates that recur in every real prompt: the identity block, the capability declaration, the XML container, and the rule for example. The recurring patterns that work.