🗣️ Behavioral Patterns
The 7 patterns that govern how the model acts and speaks — not how the prompt is structured, but how it behaves. From the rule with a why to the consolidated principle, this is where the course's central thesis appears: rules become principles.
Detailed content
Behavior over form
In module 1.2, you cataloged the patterns structural — how the prompt is organized: identity blocks, XML compartments, system reminders. This module shifts the focus. The patterns behavioral don't say where the rule goes; they say how the model acts and speaks: it justifies, it emphasizes, it holds back, it preserves, it consolidates.
🧭 The course’s central thesis appears here
Immature prompts govern behavior with rules: lists of "never X," micro-restrictions, accumulated exceptions. Mature prompts govern through principles: statements of intent that produce the right behavior in cases no one anticipated.
The 7 patterns in this module form a ladder: they start as mechanics (ALWAYS/NEVER contrast, rule by example) and climb toward stance (rule with a reason, consolidated principle). This progression—from rule → principle — is the bridge to Track 2, about how prompts evolve over time.
🏗️Structural (module 1.2)
Respond where it goes e how it’s organized.
- •Identity block on the first line
- •XML compartments that isolate context
- •System reminder injected per turn
🗣️Behavioral (this module)
Respond how the model acts and speaks.
- •Justifies the rule ("because…")
- •Reserve emphasis (NEVER) for non-negotiables
- •If it contains, preserve the source, consolidate
Rule with Rationale
Blunt prohibitions fail in cases outside the script: the model doesn’t understand the intent and either works around the rule in unanticipated variations or applies it absurdly where it shouldn’t.
Adding the why solves this — a model that understands the intent generalizes. The justification works like the rule’s “source code,” not just its compiled binary.
Source: educacao/fichas/03-regra-com-porque.md.
…directs users to the National Alliance for Eating Disorders helpline instead of NEDA, because NEDA has been permanently disconnected.
Without the "because," the model would treat it as an arbitrary preference and "correct" it to the most famous feature. With the reason, it understands that it's a factual matter.
You must NEVER state you don't know a certain piece of personal information without calling personal_context first. It is the safe default way to ground your answers in the user's context.
The second sentence turns the prohibition into an understandable policy: “verify before refusing” is the principle; the rule is just its consequence.
✗ "Never X" (a ban with no reason)
- •Follows the letter, violates the spirit
- •Breaks with unforeseen variations
- •Applies the rule where it shouldn't
- •Model doesn't know when to be flexible
✓ "Avoid X because Y" (a rule with a reason)
- •Generalizes to new cases
- •Model understands the intent
- •You know when reason doesn't apply
- •Grows with the model's capabilities
When NOT to attach the why
At strict safety limits where the detailed justification would teach the workaround. In these cases, state the principle, not the detection mechanics (see Topic 7, Source Preservation). And note the trend: this pattern grows with maturity — rare in Opus 4.6, frequent in Fable 5.
ALWAYS / NEVER contrast
In long prompts, critical rules get diluted among dozens of instructions. The solution is to mark them with caps
(NEVER, ALWAYS, MUST) only what is non-negotiable — ideally in contrasting pairs:
what never to do + what to do instead. The contrast eliminates the ambiguity of "okay, I won't do X… so what do I do?".
Source: educacao/fichas/04-contraste-always-never.md.
RULE SUMMARY (ALWAYS Follow):
- NEVER mix formats.
- NEVER add language tags to CODE REFERENCES.
- NEVER indent triple backticks.
- ALWAYS include at least 1 line of code in any reference block.
Pure contrast: three NEVERs and one ALWAYS, about the point where the product cannot tolerate errors — code rendering in the editor.
You MUST NOT generate any text before or between tool calls. […] Simply execute the tool calls silently. Only provide text output AFTER all tool calls are complete…
Prohibition (MUST NOT) immediately followed by the expected positive behavior ("simply execute… only AFTER") — the complete pair.
📢 Antipattern: Emphasis inflation
When everything is CRITICAL, IMPORTANT, and NEVER, nothing is. The prompt shouts all the time, and the model loses its sense of priority. The Opus → Fable 5 evolution reduced caps, reserving them for copyright and safety.
Practical rule: if you can imagine a legitimate exception, the rule doesn’t deserve NEVER — deserves a why (Topic 2).
Caps are a scarce resource
Contrast is more common in coding agents (Cursor, Microsoft), where formatting errors break the product. Treat NEVER/ALWAYS as a limited budget: every use of caps reduces the weight of the others.
Rule by Example
Format rules described in prose are ambiguous. "Use the correct database syntax" allows N interpretations — and the model chooses the wrong one.
The solution is show, don’t (just) describe: one concrete example — inline schema, model call, good/bad pair — eliminates ambiguity once and for all.
Source: educacao/fichas/06-regra-por-exemplo.md.
# Notion — notion-ai.md (~linhas 121–125): schema inline
Example: <database url="URL" inline>Title</database>
Example: <database url="URL" locked>Title</database>
# duas linhas substituem um parágrafo de especificação de atributos
# Google — gemini-2.5-pro-api.md (~linhas 38–44): batching por exemplo
```tool_code
concise_search(query="your search query")
```
```tool_code
print(browse(urls=["url1", "url2"])) ← o exemplo MOSTRA o batching
```
When you are asked to browse multiple urls, you can browse
multiple urls in a single call.Advanced variant: judgment example
Contrast pairs (<example_good> / <example_bad>) and examples with context
(<memory_application_examples> in Anthropic's prompts) also demonstrate the judgment, not just the format.
The example stops teaching "how to write" and starts teaching "when to apply it".
✓ Effective example
- •Concrete inline schema/call
- •Obvious or varied placeholder
- •Good/bad pair for teaching judgment
- •Used for format and mechanics
✗ Antipatterns
- •Abstract rule: "format appropriately"
- •Overfit: copies "your search query" literally
- •List treated as exhaustive
- •Too many examples for one principle (makes it rigid)
Concision Budget
Models tend toward excess: long answers, lists for everything, preambles, and recaps. In high-volume products (search, CLI, voice),
verbosity costs money, latency, and attention. The solution is to state the budget: target length, when to expand, when to shorten —
brevity as policy, not chance. Source: educacao/fichas/07-orcamento-de-concisao.md.
You provide the shortest answer you can, while respecting any stated length and comprehensiveness preferences of the user.
Foundational principle: brevity is the default; the user is the expansion valve.
Clear, concise description of what this command does in active voice. […] For simple commands (git, npm, standard CLI tools), keep it brief (5-10 words).
Surgical numerical budget (5–10 words) for a specific field — concision by context, not globally.
✂️ 2026 nuance: concision ≠ compression
The most recent prompts distinguish concision of compression. Claude Code Fable 5 instructs you to be selective with content, but writing complete sentences — and prohibits fragments and chains of arrows:
✓ “Step A calls B, which fails due to a timeout.”
Short ≠ illegible. The budget cuts fat, not clarity.
The pattern isn't "be brief"
It’s “declare the budget appropriate for the product.” Educational content, reports, and analyses call for the opposite—budget generous with structure. The corresponding anti-pattern is the formatting as a crutch: without a budget, the model fills the response with headers and bold text to look organized.
Tool Contract
Listing tools (module 1.2) isn't enough: the model calls the wrong tool for the case, ignores dependencies between calls, or makes N sequential calls when 1 batch call would have sufficed.
The contract specifies, for each tool: usage trigger, prerequisites, sequencing, exclusions, and rules for batching/parallelism.
Source: educacao/fichas/08-contrato-de-ferramenta.md.
The flow of a call under contract
Usage trigger
xAI — grok-4.3-beta.md (~line 625)
"Always use this tool to render an image from search_images result." The trigger is another tool’s output—the contract ties A to B.
Exclusion (use X, never Y)
xAI — grok-4.3-beta.md (~line 625)
"Do not use render_inline_citation or any other tool to render an image." Prohibiting the alternatives eliminates the wrong choice.
Chaining (B consumes A's output)
xAI — grok-4.3-beta.md (~line 618)
The argument citation_id must have the format [web:citation_id] extracted from the previous call — the exact format is stated.
Batching / parallelism
Claude Code (concurrency contract)
Make independent calls in the same block (in parallel) and wait for results only when there’s a dependency. Explicit concurrency, not implicit.
When a detailed contract is wasteful
With a few orthogonal tools (2–3 with no overlap), a clear description of each is enough. The contract only pays off when there is choice ambiguity or dependency between calls.
Source Preservation
Two opposing risks with third-party material: (a) the model changes what it cites — paraphrase citations, corrupt traceability; (b) the model copies too much — reproduces protected text.
The solution is a double rule: citations go through a formal mechanism that preserves the source exactly; reproducing protected content has strict limits — and detailed paraphrasing counts as reproduction.
Source: educacao/fichas/09-preservacao-de-fonte.md.
Do not cite sources any other way; always use this component to render citation. You should only render citation from web search, browse page, X search, or document search results, not other sources.
Citations only through a structured component and only from verifiable sources in the session itself — traceability by architecture, not goodwill.
Decline and explain you cannot reproduce substantial portions. Do not attempt to reconstruct the passage through detailed paraphrasing […]—this still violates copyright even without verbatim quotes.
Also closes the gap in detailed paraphrase: preserving the source also means not reconstructing it.
🛡️ Connection to the Rule with a Why
Here is the exception from the Rule with a Why (Topic 2). For safety limits, include the detailed rationale would teach the workaround. That’s why the preservation mechanism is stated formal and architectural — you don't explain how to detect the violation; you make the violation mechanically impossible (citations only through a component, reproduction blocked by a hard limit).
Formal mechanism only where justified
In a pure chatbot, with no external material, the citation apparatus becomes ceremony. The mechanism makes sense for search/synthesis products — Perplexity ("preserve response_text with zero modifications"), Grok, Copilot, Anthropic (copyright throughout the prompt).
Consolidated Principle
Prompts grow by accretion: every bug becomes a new rule and nothing is removed. The result is the onion prompt —
redundant rules that fall out of sync, micro-rules that signal distrust, and text where no one knows what can still be deleted.
The antidote: replace sets of specific rules with a single principle that generates them — and also covers cases nobody anticipated.
Source: educacao/fichas/12-principio-consolidado.md.
🧪 Real case: 4 micro-rules → "capable adult" (Opus 4.8 → Fable 5)
Opus 4.8 — 4 separate safeguards
Fable 5 — removed all 4, covers them with 1 stance
Four microscopic guardrails became a stance—which also handles cases the guardrails didn't anticipate.
Copyright case: 2 blocks → 1, renamed to reflect the intent
The text barely changed — the block name yes:
<claude_prioritizes_copyright_compliance> — framing of obedience
<core_copyright_principle> — framing of value
From "prioritize compliance" to "core principle". Consolidating also means renaming by intent — two blocks become one, under a name that conveys the why.
⚠️ Consolidation ≠ blind trust
Hard safety and format limits keep rules explicit even with a stated principle. Fable 5 keeps the numerical citation limits alongside the copyright principle. The principle replaces rules redundant, not the non-negotiable. Prompt-onion smell test: if two rules say almost the same thing in different places, the next edit will desynchronize them.
This is the bridge to Track 2
Fable 5 is the masterclass in consolidation: 7 blocks removed, micro-rules merged, with a net total of only +56 lines with a lot of new content. Seeing this edit happen across versions — Opus 4.6 → 4.8 → Fable 5 — is exactly the subject of Track 2 (Evolution). The "rule → principle" pattern is the yardstick you'll take there.
Module Summary
- ✓Behavioral rules govern how the model acts and speaks, not where the rule goes
- ✓Rule with rationale: the justification is the "source code" — it generalizes to new cases
- ✓ALWAYS/NEVER contrast: use caps only for non-negotiables; emphasis inflation kills the scale
- ✓Rule by example: inline schema eliminates ambiguity; watch out for overfitting
- ✓Concision budget: brevity as policy; concision ≠ compression
- ✓Tool contract: trigger, exclusion, chaining, and parallel batching
- ✓Source preservation: citation by design + copyright limit (the rationale exception)
- ✓Consolidated principle: merge redundancies into one principle — the bridge to Track 2
Next Module: 1.4 — Anti-patterns
Each pattern in this module has a dark counterpart (prohibition without a reason, emphasis inflation, overfitting to the example, formatting as a crutch, onion prompt). Learn to recognize them in the collection.