A constraint stated once behaves like a suggestion

The rule does not break, it fades
You establish at the outset that the copy must never exceed forty words per paragraph and must avoid the word solution. For three exchanges this holds. By the seventh, paragraphs are running long and the forbidden word has reappeared, and if you point this out you get an apology and one compliant response before the drift resumes.
It is tempting to read this as disregard, and the apology reinforces that reading. What is actually happening is closer to dilution. Your rule was one instruction near the beginning, and by now it sits behind thousands of words of subsequent material, most of which is more recent and more specific about the immediate task.
The practical consequence is that emphasis does not fix it. Capital letters, repeated warnings and increasingly stern phrasing all address a problem of will, and the problem is one of weight. A rule competes with everything else in the exchange, and its position and frequency decide how much of that competition it wins.
Position and repetition are the levers you actually have
A constraint placed immediately before the request outperforms the identical constraint placed at the top of a long conversation, for the same reason a note on the front of a folder is more likely to be read than one filed halfway through it. Recency is doing real work here and you can use it deliberately.
So carry the constraints with you. Restate the two or three that matter in every request, in one compact line, rather than establishing them once and hoping. This feels redundant, and it is exactly the redundancy that makes the rule survive the eleventh exchange as well as the second.
Keep the list short enough to restate. A dozen rules cannot be repeated every time and will not all be honoured anyway, so the discipline is to identify which two or three genuinely matter and let the rest be corrected in editing. Constraints have a budget, and spending it evenly is a mistake.
Make the constraint something the output has to display
A rule that leaves no trace is easy to lose. A rule that requires visible compliance is much harder to lose, because producing the output means producing the evidence, and the absence is obvious to you at a glance rather than after a careful reread.
Instead of asking that paragraphs stay short, ask that each paragraph be preceded by its word count. Instead of asking that every claim come from the supplied document, ask for the quoted line beside each claim. The constraint becomes part of the structure rather than a background preference, and structure is far more durable than preference.
When the visible marker has served its purpose you can strip it mechanically, which takes seconds. The point is not the marker itself. The point is that a requirement embedded in the shape of the output is being enforced by the format rather than remembered.
Restate rather than reprimand
When a rule lapses, the instinct is to say that you already asked for this. That sentence adds length without adding constraint. It usually produces a compliant next response followed by the same drift, because nothing in the exchange has changed except the addition of an admonishment.
The more effective move is to start fresh with the constraint in the strongest position: restate the requirement plainly and reissue the request. If it has lapsed twice, that is evidence the conversation has grown too long to hold it, and continuing to patch inside the same thread is working against the grain.
It is worth distinguishing a lapse from a conflict. Sometimes the rule was dropped because it cannot be satisfied alongside something else you asked for, and no amount of restating will resolve that. If the same constraint fails repeatedly on the same kind of request, check whether you have asked for two incompatible things.
Some constraints do not belong in the prompt at all
Anything that must be true every time is better enforced outside the conversation. A word count can be measured. A banned term can be searched for. A required field can be checked for presence. These are cheap mechanical tests, and unlike an instruction they do not have a failure rate that varies with conversation length.
This is the sharper version of the point. Prompts are good at describing what you want and unreliable at guaranteeing it, so a requirement that genuinely cannot be violated should be verified by something deterministic rather than requested politely and repeatedly.
Reserve the prompt for the constraints that need judgement, where no mechanical test exists — register, emphasis, what to leave out. Those are the ones worth restating in every request, and they are far fewer than the list most people carry into a long exchange.
Common questions
Does putting a rule in capitals or repeating it three times help?
Marginally at best, and it costs you length. What reliably helps is position, restating the rule immediately before the request, and structure, requiring output that displays compliance. Emphasis addresses a motivation problem that is not the actual cause of the drift.
How many constraints can I realistically hold in one conversation?
Two or three that you restate every time, plus whatever you are prepared to fix in editing. Longer lists are not honoured evenly, and the ones that lapse first are rarely the ones you would have chosen to sacrifice.
Is it better to start a new conversation than to keep correcting?
Often, yes. If a constraint has lapsed twice in the same thread, the thread has accumulated enough competing material that further correction is unlikely to hold. Restating the requirement at the top of a fresh exchange is usually faster than the third round of patching.
Senior writer, Prompt After Prompt
Maya writes about prompt craft, writing with ai, images & audio, mostly the parts other people skip and thinks most subjects are more interesting once you know how they work.