A prompt returns something wrong and the instinct is to rewrite it entirely. That discards the information the failure contained.
Why rewriting first is the wrong move
A full rewrite changes many things at once, so a better result does not identify what fixed it.
Prompts edited this way accumulate defensive clauses added after each failure, most of which do nothing. They also get longer, and length itself degrades instruction following, so the repair compounds the original problem.
The alternative is to read the output as evidence about which specific instruction was not followed.
What to check before changing anything
Run the same prompt again unchanged. Output varies between runs, and a single bad result may not indicate a defect at all.
Confirm the model received what you think it did, particularly when a file or a long document is involved and extraction may have failed silently.
Check whether the request contains two instructions that conflict, since the model will satisfy one and appear to ignore the other. Conflicts are common in prompts that grew by accretion, because each addition was written without reference to the last.
How to isolate the failing instruction
Strip the prompt to the single requirement that was violated, run it alone, and see whether the model can follow it in isolation.
If it can, the instruction is being crowded out and its position or emphasis is the problem. If it cannot, the instruction is unclear or beyond the model.
Adding requirements back one at a time locates the point where compliance breaks, which is usually a specific pair rather than the length of the prompt. That pair is then the thing to rewrite, and the rest can stay as it was.
Why ordering matters more than phrasing
Instructions near the start and end of a prompt are followed more reliably than instructions in the middle.
Moving a neglected requirement to the end frequently resolves the failure with no change to its wording.
Long prompts amplify this, so a requirement buried at position twenty is competing against everything above it regardless of how it is phrased.
When the prompt is not the problem
Some failures are task failures. If the request requires information the model does not have, no phrasing supplies it.
Requests that need current facts, private data or arithmetic on many figures fail for reasons no prompt engineering addresses.
Recognising this class early saves the hours otherwise spent refining wording against a wall, and redirects the effort towards supplying the missing input instead.