🧬 Anatomy & Patterns

The persistent instruction layer that defines the model's behavior before any user message — composed by the harness from stable and dynamic parts.

Distinguishing a system prompt from a user message, RAG, tool context, and a system-reminder is the prerequisite for reading any prompt without confusing the layers.

Stable prompt · turn-by-turn messages · harness · dynamically injected context.

The prompt’s anchor: persona + product, base model, and knowledge cutoff, stated in the first line.

Without an anchor, the model drifts — it becomes a different persona, invents capabilities, or talks about events beyond its cutoff as if it knew about them.

Persona · base model · knowledge cutoff · mission scope ("your job is…").

Structured list of tools with scope and usage conditions—not a vague paragraph.

A weak declaration leads to over-promising (offering what it can’t do) and under-using (ignoring what’s available). The structured spec solves both.

Tool scope · usage condition · function signature · anti-overpromising.

The section that states refusals and principles, positioned early to signal precedence: safety before usefulness.

A blanket prohibition can be bypassed; a rule with a rationale and a description of the pattern (not the mechanics) generalizes to new situations.

Principled refusal · safety > helpfulness hierarchy · default vs. mechanics · early positioning.

Concision budget, lists vs. prose, markdown use, and conversational vs. technical tone — the tone_and_style section.

Prevents two opposing anti-patterns: overly long responses and responses broken into bullets without coherent prose.

Concision budget · prose vs. list · contextual markdown · tone calibrated to the product.

The layer the harness injects each turn via <system-reminder>: date, user, notices — separate from the stable prompt.

Confusing what is stable with what is injected leads to incorrect conclusions when reading a leaked prompt and comparing versions.

Harness · system-reminder · current date injected · stable/dynamic separation.

The distinction between patterns that give shape (skeleton) and those that shape behavior (voice), with the 5 structural patterns in this module.

The structure is what you can diff across versions and providers — it makes prompts readable and versionable.

Skeleton · domain-independent · 5 patterns · diffable.

"You are X" + model + cutoff date: the first pattern and the only one seen in 100% of prompts.

Identity is an anchor, not a biography—recognizing the pattern helps avoid the anti-pattern of a buried or bloated persona.

Persona · knowledge cutoff · mission scope · 100% universal.

Structured list where each capability includes "what it does," "when to use it," and "limits"—even as a function signature.

Seen at xAI, Google, Microsoft, Notion, Cursor, and Claude Code—more elaborate in agents than in pure chatbots.

Scope · condition ("if the user…") · signature (params + defaults) · anti-overpromising.

Each logical block wrapped in a named XML tag (<policy>, <tone_and_formatting>), flat and modular.

It’s what makes a prompt with thousands of lines maintainable and the diff between versions readable—in code, Markdown headers serve this purpose.

Named block · flat (≤ 2 levels) · diffable · Markdown too.

The <system-reminder> block injected by the harness, separate from the prompt's stable behavior.

Recognizing the dynamic layer prevents attributing to the "model prompt" what is actually runtime context.

system-reminder · harness injection · separate layer · runtime context.

The stated precedence that resolves conflicts: core policy > system > user > default.

Without an explicit hierarchy, conflicting instructions leave behavior undefined — the prompt needs to say which one wins.

Declared precedence · core policy · conflict resolution · combination with <policy>.

The shift from the skeleton (form) to the patterns that govern how the agent acts, decides, and expresses itself.

It’s where the agent’s personality and reliability live—the difference between a prompt that “obeys” and one that “understands.”

Voice · behavior × structure · decision governance · expression.

Every rule comes with the reason behind it, instead of a blunt command.

The rationale lets the model generalize to unforeseen cases instead of obeying mechanically and failing at the edges.

Explicit reasoning · generalization · edge-case robustness · intent over literal wording.

Pair of instructions that sets the desired behavior and the prohibited behavior side by side, in uppercase for emphasis.

Contrast removes the ambiguity of the middle ground—the model knows exactly which pole to move toward and which to avoid.

ALWAYS/NEVER · uppercase emphasis · desired/prohibited pair · ambiguity removal.

Concrete demonstration of the expected behavior (input → output) paired with the abstract rule.

One well-chosen example establishes behavior better than three paragraphs of description—the model learns by imitation.

Demonstration · input → output · learning by imitation · rule + example.

Explicit instruction about the ideal response length and when to expand or cut back.

Without a budget, the model "pads things out"; with one, it calibrates density to the channel (terminal, chat, API).

Target length · expand/cut · density by channel · anti-verbosity.

The behavior rules for tools: when to call them, in what order, how to chain them, and when to stop.

Naming the tool isn’t enough—the usage contract is what prevents redundant, out-of-order, or unnecessary calls.

When to call · order · chaining · parallelism vs. sequence.

The rule to preserve verbatim passages that carry exact meaning — quotes, code, load-bearing values.

Summarizing or paraphrasing exact content introduces subtle errors; the pattern teaches the model what NOT to rewrite.

Verbatim · load-bearing · faithful quote · do not paraphrase.

A general principle that absorbs several specific rules into a single high-level instruction.

It’s the mature form of a prompt: instead of listing every case, it states the principle that covers them all—more robust and shorter.

General principle · consolidation · high-level · robustness through abstraction.

The logic behind studying what goes wrong: each anti-pattern has an observable symptom and a known fix.

Knowing the name of the error speeds up diagnosis — you go from "the prompt feels off" to "this is an onion prompt."

Named symptom · correction · diagnosis · error catalog.

A prompt that grows by addition: every incident becomes a new rule, and nothing is ever removed or consolidated.

The layers contradict each other and bloat the context; the fix is to consolidate them into principles (see module 1.3) and prune.

Growth through additions · internal contradiction · context inflation · pruning.

"Never X" without explaining the intent—the opposite of a Rule with a Reason.

Without the reason, the model follows the letter but fails on nearby variations that violate the rule's spirit.

Strict order · edge-case failure · letter vs. spirit · add the why.

Safety implemented by listing prohibited terms/techniques instead of describing the pattern to detect.

The list can be circumvented with synonyms and still teaches what to avoid; describing the principle generalizes better and is safer.

List of terms · circumventable · pattern over mechanics · robust principle.

Two sibling anti-patterns: forcing lists/headers/emoji into everything, and putting policies, tone, and tools in running text.

One strips the prose down to a skeleton; the other makes the prompt impossible to version—both curated by the XML Compartment.

Forced format · skeleton without prose · mixed blocks · compartmentalize.

Overusing CAPS, “CRITICAL,” “ALWAYS,” and bold — until emphasis loses its value as a signal.

If everything is urgent, nothing is: the model can't prioritize. Emphasis is a scarce resource and should be spent carefully.

Excessive CAPS · signal loss · sparse emphasis · prioritization.