A prompt library decays the way a shared drive decays. Nobody decides to make it useless. One person adds a variant to solve a Tuesday problem, another copies a prompt and edits it in place, a third leaves the team, and eighteen months later there are ninety-one prompts, four of which anyone still trusts.
The decay is not a discipline failure. It is what happens to any collection of documents that has no owner, no version and no retirement rule. Prompt libraries need the same three things a code repository needs, and for the same reason: they are operational assets that other people depend on.
Prompt rot is quiet, and it is normal
Prompt rot shows up in symptoms that are easy to misread. Output becomes inconsistent between people doing the same task. New hires ask which of six prompts is current. An improvement made by one person is invisible to everyone else because it lives in their own notes. The task still gets done, so nothing looks broken — the cost is spread across everyone, which is exactly why nobody fixes it.
The moment to intervene is early, and the intervention is small: decide what the library is for. A library is a set of prompts that the team has agreed are the default way to do a specific job. Anything else — experiments, personal shortcuts, one-off rescue prompts — belongs somewhere else, clearly marked as scratch.
What belongs in a stored prompt
A prompt that survives contact with reality contains more than instructions. Store six things with every entry:
- The task, stated as a job title rather than a topic — "turn interview notes into a first draft" rather than "writing."
- The instructions themselves, with placeholders named clearly enough that nobody has to guess what goes in them.
- Required inputs, including anything that must come from a person rather than a document.
- A sample input and the output it produced, so the expected shape is visible.
- The known failure modes, in one or two lines. This is the field teams skip and later wish they had not.
- The model and settings it was validated on.
The failure-mode line is the one that repays its cost fastest. Knowing that a prompt invents statistics when the source material is thin prevents a whole class of embarrassing output, and it is knowledge that exists only inside someone's head until it is written down.
Naming and versioning that survives a year
Name by task and audience, not by cleverness. A name like weekly-roundup-v3-final-USE-THIS is a symptom, not a solution. Pick a convention that a newcomer can predict: task, optional variant, version. Keep the version in the file name or the entry metadata, never in prose inside the prompt where it will drift out of sync.
Version discipline matters most when a prompt is used in a recurring workflow. Changing a live prompt silently changes what everyone produces, and if the change is bad, nobody can tell whether the output got worse or the input did. When an entry is revised in a way that changes output meaningfully — different structure, different constraints, different length — bump the version and keep the previous one for one cycle. When it is a typo or a clarified placeholder, edit in place.
Two rules keep this from becoming bureaucracy. Never keep more than two live versions of anything. And never version a prompt nobody uses; retire it instead.
Give every prompt an owner
An unowned prompt is a prompt nobody is allowed to fix. Ownership here means one named person who answers for the entry: they approve changes, they are the one asked when output looks wrong, and they get told when the model underneath changes.
Ownership should follow the task, not the org chart. The person who does the job most often is usually the right owner, even if they are not senior. What matters is that the name is in the entry, and that the name changes when the person changes roles. Review ownership twice a year; orphaned entries are the ones that quietly become wrong.
Retiring prompts on purpose
Retirement is the part libraries never plan, and it is the reason they grow monotonous. A retired prompt should be archived rather than deleted, so the reasoning survives, but it must leave the active set immediately — otherwise the search results people see are the ones that no longer apply.
Three signals say it is time. The task it served no longer exists. The prompt has needed manual correction in each of the last three uses. Or the model now handles by default what the prompt was compensating for, which happens regularly as model quality changes. That third signal is the one people miss, and it is why the oldest entries are often the most verbose: they were written to defend against limitations that no longer exist.
A twenty-minute review loop
Once a month, one person walks the active list and does four things: count uses, note any that needed manual fixes, archive anything with zero uses in two months, and promote to default any variant that has quietly become the thing everyone actually runs.
Twenty minutes is enough because the loop is about attention, not analysis. The goal is that the library stays small enough to be read in one sitting, and that the person reading it recognises every entry. When someone opens the library and cannot recognise half the entries, the decay has already gone past the point where a monthly pass fixes it.
Measuring whether a prompt earns its place
You do not need analytics for this. Two counts per entry are sufficient: how many times it was used this month, and how many of those uses required an edit that the prompt could have prevented. High use with frequent corrective edits means the prompt is under-specified and should be improved rather than abandoned. Low use with no edits means it is solving a rare problem, which is fine, as long as someone still claims it.
Use the counts to make one decision a month, not to build a dashboard. The decisions are: improve, keep, or retire. A library where those three verbs get applied regularly stays trustworthy for years, because people can tell that a human is still paying attention to it.
Start with five prompts, not fifty
The instinct when formalising a library is to catalogue everything people have ever written. This produces an impressive document that nobody uses, because the useful entries are buried under a hundred abandoned drafts.
Start with the five prompts that cover most of your recurring work, in the formats above, with owners named. Run them for a month. The library will then grow from demand — someone hits a gap, proposes an entry, and it earns its place. A library that grows from use stays legible. One that grows from collection does not, and the ninety-one prompts nobody trusts is how it ends.