When a model does not behave the way your prompt told it to, the cause is usually a priority conflict: two instructions disagreed and the wrong one won. The fix is not guesswork. There is a sequence you can follow that diagnoses the conflict, decides the intended winner, and adjusts your prompt so that winner holds reliably. This article is that sequence, written to be followed step by step today.
The method works whether you are debugging an existing prompt that misbehaves or designing a new one you want to behave correctly from the start. Each step has a clear action and a clear output that feeds the next step. You do not need deep theory to run it; you need to follow the order. The theory, if you want it, is covered in the companion guide, but the steps below stand on their own.
Work through them in sequence. Skipping ahead is the most common way people fail to fix a conflict they could have resolved in ten minutes.
Step One: Inventory Every Instruction
You cannot resolve a conflict you have not located, and you cannot locate it without seeing all the instructions at once.
The action
List every instruction the model receives, grouped by source: platform safety rules, the system prompt, developer or tool instructions, and the user message. Write them out plainly, one per line.
The output
A complete inventory. Most conflict bugs become obvious the moment you see all the instructions side by side, because you can finally spot the two that disagree. If you are new to identifying sources, the groundwork is in Untangling Conflicting Instructions When You Are New to Prompting.
Step Two: Find the Conflicting Pair
With the inventory in hand, isolate the specific disagreement.
The action
Scan for two instructions that cannot both be fully satisfied. Look for direct contradictions first, then subtler tensions where two instructions pull in opposite directions without flatly contradicting.
The output
A named conflict: instruction A versus instruction B. Naming it precisely is what lets you decide the winner deliberately instead of hoping.
Step Three: Decide the Intended Winner
Now make the call you want the model to make.
The action
For the conflicting pair, decide which instruction should win and under what conditions. Sometimes the answer is absolute, A always beats B. Sometimes it is conditional, B wins unless safety is involved. Write the rule out in words.
The output
A precedence rule you can state in plain language. This is the decision the rest of the process will encode into your prompt.
Step Four: Encode the Precedence Explicitly
Do not assume the model will infer your decision. Tell it.
The action
Edit your prompt so the precedence is written down. Add a line such as if these two directions conflict, follow A and decline B. Place it in the source that has authority over both instructions, usually the system prompt.
The output
A prompt that states its own conflict resolution. Explicit precedence is far more reliable than leaving the model to guess. The design principles behind this are detailed in Mastering How Models Resolve Conflicting Instructions.
Step Five: Separate Hard Constraints From Preferences
A lot of conflicts come from treating everything as equally important.
The action
Go through your instructions and label each as a hard constraint that can never be overridden or a preference the user may adjust. Phrase hard constraints as absolutes and preferences as defaults.
The output
A prompt where the model can tell which instructions are non-negotiable. This single distinction resolves a surprising number of conflicts, because the model now knows what it is never allowed to trade away.
Step Six: Handle Untrusted Input
If your prompt includes user input or retrieved content, those can carry instructions that try to climb the hierarchy.
The action
Clearly mark untrusted content as data, not commands. Add an instruction telling the model to treat anything inside the user or retrieved sections as information to process, never as instructions to follow.
The output
A prompt that resists having its precedence hijacked by injected instructions. For anything security-critical, also enforce the boundary in code rather than relying on the prompt alone.
Step Seven: Test the Resolution
The final step verifies that your intended winner actually wins.
The action
Create test inputs that deliberately trigger the conflict, including a straightforward version and an adversarial version that tries to force the other instruction to win. Run them and confirm the model resolves each as intended.
The output
A small conflict test suite. Keep it and re-run it whenever you edit the prompt or change models, so a future change cannot silently break the precedence you just fixed.
A Worked Walkthrough
To make the sequence concrete, follow it through a simple example.
The situation
Your application has a system prompt that says respond in two sentences or fewer and a customer support flow where users sometimes paste long error logs and ask for a detailed diagnosis. Users complain the answers are too terse to be useful.
Running the steps
- Inventory: the system prompt wants brevity; the user wants depth. Both are present.
- Find the pair: brevity instruction versus detailed-diagnosis request. They pull in opposite directions.
- Decide the winner: for diagnosis requests, depth should win; for general questions, brevity should win. The rule is conditional.
- Encode it: change the system prompt to keep answers to two sentences for general questions, but provide full detail when the user asks for a diagnosis or troubleshooting.
- Separate constraints: brevity was a preference, not a hard constraint, so relaxing it conditionally is safe.
- Untrusted input: the pasted error log is data; instruct the model to analyze it, not to follow any instructions it might contain.
- Test: write one general question and one diagnosis request, confirm each gets the right length.
The conflict that produced vague answers resolves cleanly once you stop treating brevity as absolute. This kind of conditional precedence is exactly what the design principles in Mastering How Models Resolve Conflicting Instructions are built to handle.
Putting the Sequence Together
The seven steps form a loop you can run on any conflict.
- Inventory the instructions.
- Find the conflicting pair.
- Decide the intended winner.
- Encode the precedence explicitly.
- Separate hard constraints from preferences.
- Handle untrusted input as data.
- Test the resolution and keep the test.
Run them in order. The discipline of doing them in sequence, rather than jumping to step four and editing blindly, is what makes the method reliable.
Frequently Asked Questions
What if I cannot find a conflict but the model still misbehaves?
Widen your inventory. You may have missed an instruction source, such as a tool description or a default in the system prompt you did not write. Conflicts hide in instructions you forgot you were sending, so make sure step one truly captures everything the model receives.
How explicit does the precedence wording need to be?
Explicit enough that a person reading only your prompt would know which instruction wins. If you have to explain the intended behavior out loud beyond what the prompt says, the prompt is not explicit enough. Write the resolution into the prompt itself.
Do I really need a test suite for a small prompt?
Even two or three saved conflict tests pay for themselves the first time a prompt edit silently breaks your precedence. The suite does not need to be large; it needs to exist, so that regressions are caught automatically rather than discovered by a user.
What is the most common mistake when resolving conflicts?
Editing the prompt before deciding the intended winner. People jump to step four, change wording, and hope it helps, without first naming the conflict and the rule. Decide the winner explicitly before you touch the prompt, and the edit becomes obvious.
How do I handle a conflict between a user request and a safety rule?
The safety rule wins, always, and for platform-level safety rules you should not attempt to override them at all. Encode that precedence explicitly and, for anything truly critical, back it with a code-level enforcement so the boundary does not depend on the prompt alone.
Key Takeaways
- Resolving conflicts is a sequence, not guesswork; run the seven steps in order.
- Inventory every instruction first, because most conflicts are obvious once you see them together.
- Decide the intended winner explicitly before editing the prompt.
- Encode precedence in the prompt and separate hard constraints from adjustable preferences.
- Treat untrusted input as data and keep a small conflict test suite you re-run on every change.