A rule added for every failure produces a prompt nobody can read

Every clause was added for a reason

A working instruction that gets used regularly has a life cycle. It starts short. Something comes back wrong, so a sentence is added. A month later a different thing comes back wrong, so another sentence is added. Nobody ever removes anything, because each clause is a scar from a real failure and deleting it feels like inviting the failure back.

After a year the instruction is a page and a half of accumulated corrections, written in five moods, with three clauses that contradict each other and two that refer to a situation which no longer arises. It still works, mostly. Nobody can say which parts are doing the work.

This is not a sign of carelessness. It is the natural result of a sensible local decision repeated many times, which is how most maintenance problems arise.

What a long instruction actually costs

The first cost is that a constraint added to a crowded instruction is weaker than the same constraint in a short one, because attention is finite and everything is competing. Adding your fifteenth rule can degrade the third, and nothing will announce that it has happened.

The second cost is that nobody can test it. A short instruction can be reasoned about; a page of clauses cannot, and the practical consequence is that people stop editing it and start working around it, which is how a team ends up with four private variants of the same prompt.

The third is that contradictions become invisible. Two clauses written eight months apart may pull in opposite directions, and the resolution happens quietly, which means the behaviour you are getting is the outcome of a conflict nobody knows exists.

Most of the clauses were really one clause

When you finally read the accumulated version, the striking thing is usually how much of it collapses. Six specific prohibitions turn out to be six instances of one preference about register. Four formatting rules are one description of an output shape. Three warnings about a particular kind of content are one statement about who the reader is.

Rewriting them as the general rule they were reaching for is nearly always shorter and often more reliable, because it covers the cases you have not met yet. Specific prohibitions only ever cover what has already gone wrong.

Keep the specifics where they are genuinely idiosyncratic. A term your organisation insists on, a unit convention, a thing that must never be abbreviated: these do not generalise and they belong in the instruction verbatim.

Branch rather than accumulating

A lot of clause growth comes from trying to make one instruction cover cases that are not the same task. Half the rules exist for the awkward third of inputs, and they are being applied to the straightforward two thirds as well, where they add noise and occasionally do harm.

Splitting into two instructions, chosen by an obvious property of the input, is usually cheaper than a single prompt with conditionals in it. Two short instructions, each of which can be read and tested, beat one long instruction that handles everything and can be reasoned about by nobody.

The counterargument is real: two variants can drift apart and both need maintaining. That is a genuine trade rather than a free improvement, and it favours splitting only where the cases really are different and the split is decided by something you can see in the input.

Prune deliberately, and keep the failures somewhere else

The practical remedy is to schedule a rewrite rather than waiting for the instruction to become unbearable. Read it end to end, group the clauses by what they are actually about, rewrite each group as one rule, and delete anything referring to a situation that has not occurred in months.

Then do the part that makes pruning survivable: keep the failures in a separate note rather than in the instruction. A short record of what went wrong, with an example, means a deleted clause can be restored deliberately if the problem comes back, and it removes the fear that made everyone hoard clauses in the first place.

Run the pruned version alongside the old one for a few real inputs before you commit. That costs an hour and it is the only way to find out which of the removals mattered, which is a question no amount of reading the instruction will answer.