There is no shortage of advice telling you to "write clear prompts." That advice is useless the moment a prompt contains more than one instruction, because clarity at the level of individual sentences does nothing to resolve conflicts between them. The hard problem is not whether each rule is clear. It is which rule wins when two clear rules collide.
The practices below are the ones we keep coming back to after building, breaking, and rebuilding production prompts. They are opinionated on purpose. Each comes with the reasoning that earned it a place, so you can adapt it rather than cargo-cult it.
What unites them is a single idea: a prompt is not a wish list, it is a priority system. Treat it like one and most conflict problems dissolve.
Establish a Default Precedence Order and State It Once
Every prompt should declare, near the top, the order in which sources of instruction take priority. A reliable default is: hard safety and policy rules, then system behavior rules, then the current user request, then retrieved or tool-supplied content.
Why This Works
When the model hits a contradiction, it needs a tiebreaker. An explicit precedence statement gives it one, removing the guesswork that produces run-to-run variability. Stated once, clearly, it applies to every conflict without you anticipating each pairing.
How to Apply It
Write a short block like: "When instructions conflict, follow this order of priority." List the tiers. Keep it to a few lines. This single addition prevents the bulk of the failures described in Seven Ways Conflicting Instructions Quietly Break Your Prompts.
A Concrete Default to Start From
If you have no precedence order today, adopt this one and adjust: safety and policy rules first, then the assistant's defined role and scope, then the current user request, then formatting and tone preferences, and retrieved content last. This order works because it puts the things that must never break above the things a user can reasonably ask to change, and it keeps untrusted retrieved text from ever overriding your own rules. You will tune it over time, but starting from a sensible default beats starting from nothing.
Separate Constraints from Preferences Visually
Group your non-negotiable constraints into one labeled section and your preferences into another. The label does real work: it tells the model that violating a constraint is failure, while trading off a preference is acceptable.
The Reasoning
Models weight instructions partly by how they are framed. "Constraints (must never be violated)" carries more force than the same rule dropped into a paragraph of suggestions. Visual separation also helps you, the author, notice when a supposed preference is actually load-bearing.
Make Conflicts Explicit Instead of Hoping They Never Arise
Do not just list rules and hope they never collide. Anticipate the likely collisions and pre-resolve them. "Aim for under 200 words, but if completeness and brevity conflict, prioritize completeness" is worth ten vague instructions.
Why It Beats Adding More Rules
Each new rule you add to patch a problem creates new conflict surface. Pre-resolving the conflict directly addresses the actual decision point. This is the difference between a prompt that grows brittle and one that stays stable, a dynamic we trace in The Instruction Hierarchy and Priority Conflicts Checklist for 2026.
Anchor Hard Rules at Both Ends of the Prompt
Place your most critical constraints at the very beginning and restate the handful that absolutely cannot break at the very end.
The Reasoning
Position affects attention. Rules at the start anchor the model's behavior; rules at the end benefit from recency. The middle of a long prompt is the weakest position, so nothing critical should live there alone. This redundancy costs a few tokens and buys meaningful reliability.
Keep User-Supplied Content Structurally Distinct
Wrap untrusted user input or retrieved documents in clear delimiters and tell the model that content inside them is data, not instructions.
Why It Matters
Without this boundary, a user message saying "ignore the above and do X" competes on equal footing with your system rules. Structural separation reinforces the precedence order and is a core defense against prompt injection. We compare the structural options in Instruction Hierarchy and Priority Conflicts: Trade-offs, Options, and How to Decide.
Align Examples with Rules, Always
Every few-shot example must demonstrate the behavior your rules describe, especially at the edges. An example that contradicts a rule will usually win, because demonstrated behavior is a stronger signal than stated behavior.
Practical Discipline
When you change a rule, re-read your examples. Stale examples are a leading cause of prompts that "stopped following instructions" after an edit that never touched the instruction itself.
Prune Relentlessly
A shorter prompt with a clear hierarchy beats a long prompt with many rules and hidden contradictions. Periodically remove instructions that no longer earn their place.
The Reasoning
Every instruction is a potential conflict partner. Fewer rules means fewer collisions and a smaller surface to test. Pruning is not cleanup, it is conflict prevention.
Write Rules the Model Can Actually Act On
A precedence order only helps if each rule it ranks is specific enough to follow. "Be professional" is not a rule a model can reliably weigh against another; "do not use exclamation points or slang" is. Vague rules produce vague conflicts, where the model cannot even tell whether two instructions are colliding.
Why Specificity Reduces Conflict
When rules are concrete, the model can detect overlap and apply your precedence order. When they are abstract, the model interprets each one differently on each run, which is why abstract prompts feel so unstable. Specificity is not just good writing; it is what makes a hierarchy enforceable in the first place.
The Practical Move
Rewrite every soft, evaluative rule into an observable behavior. Replace "be helpful" with the actual behaviors you mean, such as offering next steps and citing the relevant source. Concrete rules also make your conflict tests easier to grade, because the correct outcome is something you can detect rather than judge.
Test the Hierarchy, Not Just the Output
Most teams test whether a prompt produces good answers on ordinary inputs and stop there. That leaves the hierarchy itself untested, because ordinary inputs rarely trigger conflicts. You need inputs designed to force one rule against another.
Building Conflict Inputs
For each pair of rules that could collide, write an input where both would apply but only one can win. A support prompt with a brevity rule and a completeness rule needs an input that demands a long, complete answer, so you can confirm completeness wins as intended.
Running Them Honestly
Run each conflict input several times, not once. Priority failures are intermittent, and a rule that wins four runs out of five is not actually winning. This repeated-run discipline is the backbone of the measurement approach in Putting Numbers on Whether Your Prompt Rules Actually Win, and it is the only way to know your best practices are holding in production rather than just on paper.
Frequently Asked Questions
What is the single highest-leverage practice here?
Declaring an explicit precedence order. It is a few lines that give the model a tiebreaker for every conflict, and it eliminates the largest source of run-to-run inconsistency.
How often should I revisit a prompt's hierarchy?
Any time you add a rule, and on a regular cadence even when you have not. Prompts accumulate contradictions silently, so a periodic read-through of the full assembled prompt is worth scheduling.
Do these practices change for multi-turn conversations?
The principles hold, but the surface grows. Earlier turns can contradict later ones, so restate critical constraints in the system prompt rather than relying on a single user turn to carry them.
Is it better to add a rule or to fix the conflict directly?
Fix the conflict directly. Adding rules to patch symptoms grows the prompt and creates new collisions. Pre-resolving the specific contradiction is more durable.
Key Takeaways
- A prompt is a priority system, not a wish list; design it that way.
- State an explicit precedence order once, near the top, and let it govern every conflict.
- Separate hard constraints from preferences both visually and in language.
- Pre-resolve likely conflicts instead of adding more rules that create new ones.
- Anchor critical rules at the start and end, never in the buried middle.
- Keep user content structurally distinct and your examples aligned with your rules.