OurSharedCode › Prompt Engineering Studio › Guides
I had a system prompt with this line in it:
Never exceed 150 words.It worked most of the time. Roughly one answer in three came back at four hundred words, cheerfully ignoring a limit written in plain English, and I spent an embarrassing week assuming this was the model being unreliable. It wasn't. Four lines further up I had also written explain your reasoning in full, and the two instructions could not both be obeyed. The model picked one each time and I had no way of predicting which.
That is most of what I want to say here. Instructions are rarely ignored at random. They are ignored for reasons you can find, and after chasing a few hundred of them I keep meeting the same six.
This is the big one, and it is almost always invisible to the person who wrote the prompt, because they wrote the two halves on different days.
The prompt that misbehaved
You are a technical support assistant.
Explain your reasoning in full so the user can follow it.
Be thorough — a partial answer is worse than no answer.
...
Never exceed 150 words.Nothing here is wrong on its own. Together they are a contradiction, and a model resolving a contradiction does not raise an error — it silently picks a side. The fix is not better phrasing. The fix is deciding which instruction wins, which is work the author had quietly skipped.
The prompt that behaved
Answer in at most 150 words.
If the full reasoning does not fit, give the conclusion and the
single strongest reason for it, then say that you have compressed
the explanation and offer to expand it.Same two goals, one of them explicitly subordinate, plus a defined behaviour for the case where they collide. Most contradictions in prompts exist because the author had two hopes and wrote them both down.
Before you debug anything else, read your own prompt looking specifically for the opposite of the instruction being ignored. In my experience that search ends the investigation about half the time.
Attention across a long input is not flat. Material at the very beginning and the very end of a context is used more reliably than material buried in the middle — this has been measured repeatedly, across model families, and it is stable enough to plan around. A constraint sitting in the middle of a 2,000-word prompt, with a long document pasted after it, is competing from the weakest position on the page.
So put the constraint you care most about last, immediately before the model starts generating. If you are pasting a long source document, the order that works is: role and framing, then the document, then the task and the hard constraints. Not the other way round. The instruction should be the last thing the model reads.
A cheap test: take the line that is being ignored, cut it, paste it as the final line of the prompt, and change nothing else. If compliance jumps, position was your problem and you have just fixed it for free.
"Don't write in bullet points" asks the model to hold an idea and then suppress it. Positive framing is more dependable, because it gives something to do rather than something to avoid:
Weak: Do not use bullet points or headings.
Better: Write in continuous prose, in full paragraphs.
I want to be careful here, because elsewhere on this site I say that the
Do NOT line at the end of a Task block earns its place, and I
still think it does. The two claims only look contradictory. What matters
is what you are negating.
Negating scope works well. "Do not cover pricing" names a topic that either appears in the answer or doesn't. It is binary, it is checkable at a glance, and it genuinely does cut scope creep faster than any amount of describing what you do want.
Negating style works badly. "Don't be verbose", "avoid repetition", "don't be too formal" all point at a spectrum with no edge on it. The model has no way to know where your line is, so it guesses, and it guesses differently each time. Every style negation should be rewritten as a positive instruction with a measurement in it — which is the next problem.
Brief. Detailed. A few examples. Keep it short. Concise but complete. None of these carry a value, so each one is filled in by the model, differently every run. Whenever you catch yourself writing one, put a number there instead.
Vague: Give a brief summary with a few key points.
Better: Give a summary of four bullets, one sentence each.Countable structure is more reliable than word counts. "Four bullets, one sentence each" lands close to what you asked for almost every time; "about eighty words" is a rough target and nothing more, because models genuinely cannot count their own output well. A 150-word cap will produce answers between roughly 120 and 200 words.
That last point is worth internalising rather than fighting. If a length limit is a real limit — a database column, an SMS, a UI that breaks — the prompt is the wrong place to enforce it. Ask for the length you want, then truncate or reject in your own code. A prompt is a strong preference, never a guarantee.
If a prompt contains few-shot examples, they beat the prose around them. Instructions describe; examples demonstrate; demonstration wins. Tell the model to answer in a single paragraph, then show it two examples that run to three paragraphs each, and you will get three paragraphs — the instruction was not ignored so much as outvoted.
Which is extremely useful once you know it. The fastest fix for a stubborn formatting problem is usually not another line of instruction. It is one example that already has the property you want.
Examples leak content as well as form, and this catches people out. Two examples both drawn from e-commerce will tilt answers towards e-commerce even on unrelated questions. If your examples share an accidental feature — all short, all positive in tone, all about the same industry — the model will read that feature as part of the pattern, because you gave it no way to tell which similarities were meant.
Compliance decays as a constraint list grows. I don't have a threshold to offer you, and anyone who quotes one precisely is guessing, but the shape is real: with eight constraints most prompts hold, and by thirty the model is satisfying some and dropping others without telling you. Every rule spends attention that the other rules needed.
The test I apply to each line: if the answer came back violating this, would I actually notice or care? Most long prompts are half aspiration — rules written in case they help, never checked, never missed. Cutting those makes the remaining ones work better, which feels like it shouldn't be true and reliably is.
Grouping helps too. Nine bullets under one Constraints:
heading read as one instruction with nine parts. The same nine scattered
through four paragraphs read as nine competing demands, and they compete.
When something is being ignored, this is the sequence I actually work through, cheapest first:
Steps one through five cost minutes and fix most cases. Step six is where people start, which is why prompt engineering has a reputation for being superstition — if you jump to swapping models and adding emphasis without checking for a contradiction first, then yes, it will feel like weather.