🧱 Structural Patterns
The 5 patterns that give it SHAPE to the system prompt — the skeleton that appears before any behavioral rules. They are domain-independent: you find them in code, chatbot, and workspace prompts, from OpenAI to Anthropic. Here you learn to recognize each one and cite the actual passage that shows it.
Detailed content
🗺️ The Map of Structural Patterns
When you read dozens of leaked prompts, you realize they aren't improvised: there's a grammar recurring. Part of this grammar concerns skeleton — where the prompt states who it is, what it can do, how it organizes its sections, and who takes precedence in case of conflict. These are the structural patterns: provide FORM, are domain-independent, and appear before any behavioral rule.
🧩 Structural × Behavioral
One standard structural answers "what shape does the prompt have?"—it's the skeleton that supports everything. A pattern behavioral answers "how does the agent act?"—refusals, tone, ALWAYS/NEVER contrast. The behavioral rules come in the next module (1.3). Here we stick to the skeleton: without it, there's nowhere to hang the behavior.
Structural (this module)
Identity · Capabilities · XML Compartment · System Reminder · Priority Hierarchy
Behavioral (module 1.3)
Principled refusal · ALWAYS/NEVER contrast · Rule with rationale · Tone calibration
The 5 structural patterns in this module
Identity Block — "You are X" + model + knowledge cutoff. The only 100% universal section.
Capability Declaration — what the agent can do, with scope and conditions.
XML compartment — tags <bloco> flat to modularize the logic.
System Reminder — dynamic layer injected by the harness, separate from stable behavior.
Priority Hierarchy — stated precedence that resolves conflicts: user > skill > default.
Why separate "form" from "behavior"?
Because structure is what you can diff-ar between versions and vendors. "Fable removed the block <search_first>" is a precise sentence only because the prompt was compartmentalized. Structure is what makes prompts readable and versionable—for the model and for you.
🪪 Identity Block
It’s the first pattern and the most universal: "You are X" + model + cutoff date anchor everything else. Without this anchor, the model drifts—it changes persona mid-conversation, invents capabilities it doesn’t have, or responds about events after its knowledge cutoff as if it knew about them.
Problem
Without anchoring, the assistant "turns into ChatGPT" in the middle of the conversation, claims to have nonexistent tools, or talks about events beyond its cutoff as if it knew about them.
Solution
Declare in the top: what it is (product + model), who it works for, and the knowledge time limits. It's the anchor everything else refers to.
How real prompts declare identity
OpenAI/gpt-5.5-instant.md (~line 1)You are ChatGPT, a large language model trained by OpenAI, based on GPT 5.5.
Knowledge cutoff: 2025-08
Current date: 2026-06-01
Three canonical elements in three lines: persona, knowledge cutoff, current date. The current date is dynamic context injected — see Topic 5.
Microsoft/github-copilot.md (~line 3)You are GitHub Copilot (@copilot) on github.com. Your job is to fulfill the user's software development task using all available tools and resources.
Persona + scope of responsibility ("your job is…") at the opening. The model knows what it is and what it came to do.
⚠️ Antipattern: identity missing or buried
Persona declaration in the middle of the prompt, or bloated with irrelevant backstory. Rule of thumb: identity is an anchor, not a biography. If the paragraph exceeds ~5 lines, content from another pattern (capabilities, tone) is probably leaking into it.
🛠️ Capability Declaration
The second pattern answers: what can this agent do? Without this declaration, the model hallucinates tools that don't exist, ignores the ones that do, or uses the right one in the wrong situation. The effective pattern is a structured list with scope and conditions — each capability includes “what it does,” “when to use it,” and “limits.”
xAI/grok-4.1-beta.md (~line 11)When applicable, you have some additional tools:
- You can analyze individual X user profiles, X posts and their links.
- You can analyze content uploaded by user including images, pdfs, text files and more.
- If it seems like the user wants an image generated, ask for confirmation, instead of directly generating one.
Each capability comes with its condition. Note the third: capability + built-in confirmation protocol.
Google/gemini-2.5-pro-api.md (~line 18)## Functions in Scope
You have also access to a set of python functions in scope:
```python
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 as function signatures — scope, parameters, and defaults are unambiguous.
📊 Where the pattern appears
Seen in xAI, Google, Microsoft, Notion, Cursor, and Claude Code. More elaborate in agents (code, workspace) than in pure chatbots.
In a prompt without tools (a pure chatbot), the section becomes "what you CANNOT do"—useful, but brief. The detailed contract of when/how calling is another pattern (tool contract), outside this module.
✓ Effective declaration
- •Lists each capability with its usage conditions
- •Define parameters and defaults (function signature)
- •Embeds a protocol (e.g., "ask for confirmation")
- •Dedicated section, separate from tone and rules
✗ Weak declaration
- •Implicit capabilities scattered throughout the prompt
- •"You can search the web" dropped into a tone rule
- •Tool listed without scope or condition
- •Promises what doesn’t exist in the schema (over-promise)
🏷️ XML compartment
The third pattern modularizes the logic: each logical block is wrapped in a named XML tag (<policy>,
<tone_and_formatting>, <tool_calling>).
The blocks are flat (without deep nesting) and work like modules: you can add, remove, and diff an entire block between versions.
The problem it solves
A prompt thousands of lines long in running text is impossible to maintain: you can’t find, version, or remove a policy without rereading everything. And the model benefits from clear boundaries between topics. The tags deliver both at once.
xAI/grok-4.1-beta.md (~lines 1–9)<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.
* Follow additional instructions outside the <policy> tags if they do
not violate these core policies...
</policy>The compartment doesn’t just group things—it declares its own precedence (combined with the Priority Hierarchy, Topic 6).
Cursor/cursor.md (~lines 80–93)<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>Two neighboring compartments, each with one subject. To change the tone policy, edit one block — the rest stays intact.
Works for humans too
The Opus 4.8 → Fable 5 diff is readable only because the prompts are compartmentalized: "Fable removed <search_first> e <default_stance>" is a precise sentence. Without tags, it would be "something changed somewhere." In coding agents, Markdown headers (# Seções) serve the same purpose — Claude Code uses this instead of XML.
⚠️ Antipattern: everything in the prompt
Running text where policies, tone, and tools get mixed together. Opposite approach: deep nesting of tags — real prompts keep blocks flat and rarely go beyond 2 levels. Short prompts (< ~50 lines) don't need tags: the structure would become ceremony.
📨 System Reminder
Not everything the model needs to know is stable: the current date, contextual notices, tool status, degraded adherence in long conversations.
The solution is a two-layer architecture — the system prompt defines the behavior stable;
the harness injects <system-reminder> dynamic in messages when needed. The stable prompt teaches the model to interpret this layer.
⚙️ Harness × behavior separation
It’s the separation stable config × dynamic state of software engineering, applied to prompts. The harness (the infrastructure that orchestrates the model) injects the dynamic layer at runtime; stable behavior remains untouched in the base prompt.
This allows adjust behavior without redeploying of the prompt, A/B testing of warnings, and responses to emerging problems (e.g., degradation in long conversations) without bloating the base prompt. That’s why, architecturally, this is the module’s most important pattern.
The dynamic layer in real prompts
xAI/grok-build.md (~line 36)Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are automatically added by the system, and bear no direct relation to the specific tool results or user messages in which they appear.
The layer’s contract: the model learns that these notices come from the platform, not the user or the tool.
Anthropic/claude-fable-5.md (block <anthropic_reminders>)The long_conversation_reminder, appended to the person's message by Anthropic, helps Claude keep its instructions over long conversations.
Fable 5 lists a named set of reminders (image_reminder, cyber_warning, ethics_reminder, long_conversation_reminder…). The last one, new in Fable 5, refreshes instructions in long conversations.
Convergence across providers
Anthropic is the canonical and most evolved case; xAI adopted the same format <system-reminder>. When two independent providers converge on the same syntax, it’s a sign that the pattern solves a real architecture problem. Without control of the harness, keep at least the mental discipline: distinguish stable information from contextual information in the text.
🪜 Priority Hierarchy
The fifth pattern resolves conflicts: instructions contradict each other all the time — central policy vs. user request, project file vs. chat, skill vs. default. Without a declared hierarchy, behavior in a conflict is undetermined — and indeterminate means exploitable (prompt injection) or frustrating (the model ignores the user). The solution is declare the precedence chain in the prompt itself, alongside the highest-priority rules.
🔢 The precedence chain (top to bottom)
<policy>.The embedded golden rule: safety at the top, the user above everything else. The user can’t override safety, but takes precedence over any product, config, or skill preference.
xAI/grok-4.1-beta.md (~line 2)These core policies within the <policy> tags take highest precedence. System messages take precedence over user messages.
Three levels in two sentences: core policy > system > user. The XML compartment precisely delimits what’s at the top.
xAI/grok-build.md (~lines 195–196)More-deeply-nested project instruction files take precedence over higher-level ones when instructions conflict. Direct user instructions in the chat always take precedence over any project instruction file content.
Hierarchy for coding agents: specific file > general file, and user in chat > any file. Same model as Claude Code (user > skills > default).
✓ Clearly stated hierarchy
- •Explicit precedence alongside the top-level rules
- •Safety above all; user above the rest
- •Tie-breaker defined for each pair of sources
- •Delimited by the XML compartment (
<policy>)
✗ Undetermined conflict
- •Two contradictory rules with no tie-breaker
- •"Be concise" + a skill that asks for a long report
- •Behavior varies between runs
- •Prompt injection vulnerability
🧱 Module Summary
The 5 structural patterns form the skeleton of any system prompt. Recognizing them turns opaque text into a readable map—and lays the groundwork for the behavioral patterns in the next module.
<bloco> flat files that make the prompt modular, versionable, and diffable.<system-reminder> injected by the harness, separate from stable behavior.➡️ Next Module
1.3 — Behavioral Patterns. Now that the framework is in place, it’s time to give the agent a voice: principled refusal, ALWAYS/NEVER contrast, rules with reasons, and tone calibration.