🎚️ Behavioral patterns
In the previous module, you saw how assemble the pieces of a prompt. Now let’s adjust the way of the AI: how to state a rule for it to understand and not just obeying, when to shout and when to whisper, and why "always" and "never" are expensive words. All with real examples from actual prompts — and not a difficult word in sight.
Detailed content
Rule with a Reason: explain why, not just what to do
Imagine a sign that says only "KEEP OFF THE GRASS". That’s fine — until a stone path appears in the middle of the lawn, and no one knows whether they can walk on it. Now imagine the sign "don't step on the grass because it was just planted". Suddenly you know what to do in any new situation: the stone path? Sure. Stepping where there's already old grass? Probably that too. AI works the same way. This is the most powerful pattern of all.
🎯 The idea in one sentence
Every rule should include the reason: "Do X because Y". The reason is what lets the AI generalize for the case you didn't anticipate. That's the difference between giving someone a fish and teaching them to fish.
Think of it this way: the rule alone is the compiled binary — works only where it was tested. The reason is the source code — with it, the AI recompiles the rule on its own for situations no one wrote down.
What it is
An instruction accompanied by its explicit rationale — usually with a "because…" or "since…" in English, or a “because…” in Portuguese. Instead of just giving the instruction, the prompt explains the intention behind the rule.
Why learn
Because bare prohibitions break outside the script: the AI doesn’t understand the intent and either works around the rule with a variation you didn’t anticipate or applies it absurdly where it shouldn’t. With the reason, it gets both cases right. See the diagram above: the arrow with the reason reaches even the "new case" the bare rule left out.
...when suggesting eating disorder support resources, Claude directs users to the National Alliance for Eating Disorders helpline instead of NEDA, because NEDA has been permanently disconnected.
Without the "because NEDA has been permanently disconnected", the AI might treat this as an arbitrary preference and "correct" it back to the most famous feature. With the reason, it understands that this is a matter of fact — a number that no longer works — and generalizes: never send to a disabled resource.
The pocket test
Reread every rule in your prompt and ask: "if the AI forgets this, would it still know what I meant?". If the answer is no, the rule has no why. Of the 12 patterns in this course, this is the more leveraged: one extra sentence ("because…") covers infinitely many future cases.
Always / Never contrast: the pair that clears things up
Sometimes you can't explain why—the rule is mechanical and non-negotiable (like "the format has to be exactly this, or it breaks"). For those few cases, there is another pattern: the paired contrast. You say what NEVER do e, right after that, what to do INSTEAD that. This “instead” is what clears up the doubt in “okay, I won’t do X… so what should I do?”
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 list: three NEVER + one ALWAYS, on the one subject where the product can't tolerate errors (rendering code in the editor). Notice: there's no why here — and that's right. Breaking the format simply it can’t, period.
✓ Use RULE WITH RATIONALE when…
- ✓The rule has nuance or legitimate exceptions
- ✓It’s a style, tone, or behavior preference
- ✓You want the AI to get new cases right
⚡ Use ALWAYS/NEVER CONTRAST when…
- ⚡The rule is mechanical and allows no exceptions
- ⚡Errors break the product (format, safety)
- ⚡You can give the “instead” in the pair
The practical rule for knowing which one to use
If you can imagine a legitimate exception to the rule, it doesn’t deserve a NEVER — deserves a why. The contrast in caps is a reserved weapon: the best pair is always complete, with the prohibition attached to the positive behavior ("don’t do this… do that").
Concision Budget: brevity as policy
Any AI, if left unchecked, speaks too much: long answers, lists for everything, preamble, recap at the end. In high-volume products (search, terminal, voice), this costs money, time, and the reader's patience. The solution is to give the AI a budget: specify the target length, when to expand, and when to shorten.
🎚️ The concision budget, by context
There’s no “always be brief.” There’s state the right budget for the product: tiny in the voice, huge in a legal report.
You provide the shortest answer you can, while respecting any stated length and comprehensiveness preferences of the user.
An entire foundational principle in one sentence: brevity is the default, and the user is the expansion valve — if they ask for more detail, the AI expands. The default budget is "the shortest that works".
🧠 Caution: short doesn't mean unreadable
The newest prompts (2026) separate two things that seem alike: brevity (choose only what matters) and compression (squeeze it until it becomes telegram-style). Claude Code Fable 5 says to be selective about content, but to write complete sentences — forbids fragments and arrow chains like “A → B → failed”.
In other words: cut what’s superfluous, not clarity. A good concision budget trims the fat, not the bones.
The budget can also be a number
It doesn’t have to be just a principle. It can be surgical: Claude Code, to describe a simple command, asks for "keep it brief (5-10 words)". And Fable 5 even stated its own context ceiling — <budget:token_budget>190000</budget:token_budget> — for AI to manage long conversations while knowing its limits.
Tool Contract: the rules for WHEN to use each thing
Back in Module 1.2, you saw that the prompt list the AI’s tools. But listing them isn’t enough. Giving someone a hammer doesn’t tell when hammer, even if you first need to hold the nail. The Tool Contract are the usage rules for each tool — and this is just an introduction, because the entire practice-focused Track 2 revisits this in depth.
🔧 What a tool contract defines
- ① Trigger. When should you use this tool? ("Use search only when the information is recent or requested.")
- ② Prerequisite. Does something need to happen first? ("Read the file before editing it.")
- ③ Exclusion. For this case, use X and never Y. (Eliminates the wrong choice.)
- ④ Grouping. You can make several calls at once (in a batch) instead of one at a time.
First, the prerequisite: read before changing
A good contract prevents the AI from editing a file blindly. The rule "read before editing" ensures it only acts on something it actually knows — preventing it from damaging what it doesn't understand.
Then the exclusion: use this tool, not that
When two tools seem suitable, the contract chooses for you: “to display the image, use ONLY this one—don’t use any other.” The AI isn’t left wondering and doesn’t call the wrong one.
And batching: several at once
If three searches don’t depend on one another, do all three together instead of waiting for each one to finish. Fast and cheap. (When one depends on the previous one, then wait.)
Always use this tool to render an image from search_images tool call result. Do not use render_inline_citation or any other tool to render an image.
A perfect exclusion contract: defines the trigger (image search results came back) and prohibits the alternatives ("don't use any other"). The AI has no way to choose wrong.
When the contract is excessive
If the AI only has 2 or 3 very different tools with no overlap, a clear description of each is enough—the detailed contract only is worthwhile when there’s ambiguity about what to choose or dependency between calls. We’ll build complete contracts in Track 2.
Emphasis is a currency—and inflation is real
Words like IMPORTANT, NEVER and ALL CAPS work for just one reason: because they're rare. The moment half the prompt is shouting, the AI learns that shouting means nothing—and starts treating everything with the same weight. It's inflation: printing too much emphasis on devalues.
💰 The idea in one sentence
Emphasis is money, and you don't have much in your pocket. A disciplined prompt spends emphasis the way it spends a scarce resource — reserved for the very few behaviors whose violation breaks the product.
The sentence that sums it all up: "if you need to emphasize ten things, either none of them is critical, or you haven't thought enough about which ones are."
✗ A prompt that shouts all the time
- ✗Half the rules use CAPS or "IMPORTANT"
- ✗AI loses the scale: everything becomes noise with equal weight
- ✗The rule that actually matters gets lost in the middle
- ✗Emphasis has become "wallpaper" — invisible
✓ A prompt that knows where to shout
- ✓Caps only for the very few non-negotiable items
- ✓When AI sees a NEVER, it knows it’s serious
- ✓The rest goes in as a rule with a reason (Topic 1)
- ✓Emphasis retains its value because it is rare
<claude_prioritizes_copyright_compliance>
Copyright compliance is NON-NEGOTIABLE...
<core_copyright_principle>
Claude respects intellectual property...
Anthropic didn’t change a word of the rule—only the block name: of compliance (obedience: “I comply in the listed cases”) to principle (value: "I reason from this in new cases"). The label shapes how the AI sees obeying — and this changes how it obeys. Even the name is a form of emphasis.
The most common and most invisible trap
You add “IMPORTANT” to a rule that “needs to stick.” It works once. Then the next one gets “IMPORTANT” too. Six months later, half the prompt is in caps, and the AI treats it all as the same noise. Emphasis is currency; overusing it causes inflation.
Always / never, but sparingly
This topic brings it all together. “Always” and “never” are the strongest words in a prompt—and that’s why they should be the most rare. A good prompt uses very few NEVERs. The practical rule: more than about 5 to 7 NEVERs in the entire prompt is already a sign that you're shouting too much (the inflation from Topic 5). If you need many, they aren't all critical.
NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one.
Notice how this NEVER deserves be a NEVER: it comes with an escape hatch ("unless absolutely necessary") e with the positive counterpart ("INSTEAD of that, prefer editing"). That's Topic 2's Contrast used well — spent where it really counts.
🎚️ The 4 patterns in this module, side by side
✓ Deserves a NEVER
- ✓"NEVER" break the output format the app expects
- ✓"NEVER" ignore a safety limit
- ✓Without an imaginable legitimate exception
✗ Doesn’t deserve a NEVER
- ✗"NEVER use lists" — there are a thousand exceptions; turn it into a why
- ✗"NEVER be informal" — it’s a tone preference
- ✗Anything where you imagine a “it depends”
The labs' trend
The evolution of Anthropic’s prompts (Opus → Fable 5) was reducing the caps, reserving them for copyright and safety, and replacing prohibitions with principles. The point of the story is clear: less shouting, more why. This is exactly where Module 1.5 will take you—the errors that ruin a prompt.
📝 Module Summary
- ✓Rule with a Reason ("Do X because Y") is the strongest pattern: the reason helps the AI generalize to new cases
- ✓O Always/Never contrast is for the mechanic and non-negotiable — always paired with the "instead"
- ✓O Concision Budget states the target length by context—and short isn't the same as unreadable
- ✓O Tool Contract defines the trigger, prerequisite, exclusion, and grouping (covered in depth in Track 2)
- ✓Emphasis is currency: printing too much causes inflation—and even the name from the block (compliance → principle) is an instruction
- ✓Use "always/never" sparingly (~5–7 total); we saw Grok, Cursor and the real Anthropic
➡️ Next Module
1.5 — 🚫 The 5 mistakes that ruin a prompt. Now that you know the good patterns, let’s flip the coin: the five most common antipatterns (including the emphasis inflation you just saw), with the antidote for each and before → after grids.