I once had a folder called "good prompts." Sounds healthy. The problem was that after six months it held forty files named things like report-prompt-2.txt, and whenever I needed a specific one I found it faster by… typing it from scratch.
The other half of the problem was quieter. Buried in there were a few prompts I kept using even though I knew they were just so-so — not because they were good, but because pulling one out was faster than rethinking. I was paying a small price every time I reused something I should have replaced long ago, all for "better than nothing."
That folder was not alive. It was a prompt graveyard with an optimistic name.
01A static closet fails in both directions
A closet does one thing: it holds. Things go in, things sit there. It does not tell you which is still usable, which is stale, which is better than which. With prompts, that passivity breeds two kinds of failure at once.
✕ Library as a static closet
✓ Library as a living asset
The difference is not in how many prompts you have — it is in whether you know which state each one is in. A library of ten prompts where each has a clear place beats a library of forty piled into one equal heap.
Watch the second failure, because it is quieter than the first. "Cannot find the good prompt" is at least visible — you are annoyed at the wasted effort. But "still using the bad prompt" annoys nobody, because it still runs and still produces something. You just pay a silent fee: so-so output, repeated, indefinitely — because the better prompt never got written, since the bad one kept being "good enough."
02Every prompt should sit in exactly one state
The fastest way to bring a library back to life is not to reorganize the folders — it is to give each prompt a lifecycle state, and to know which event pushes it to the next one. You need no software; a tag in the filename or a line at the top of the prompt is enough.
Trigger: it just worked again, cleanly. Do not let it sink back into the draft pile. Tidy it, name it clearly, add a "use when" — turn the luck into something reusable.
Trigger: you changed the project structure, the rules file, or the model behaves differently. The old prompt is now an untested assumption. Flag the doubt before it quietly produces something outdated.
Trigger: a new prompt does the old one's job better. Do not keep both "just in case." Move the old one out of reach — archive it for history if you like, but do not leave it on the same shelf as the one you use.
The point is not the three labels — it is the event attached to each. A state does not change because you wish your library were tidier; it changes because something specific just happened. Tying state-transitions to real events is the only way the cleanup happens by itself instead of waiting for a grand tidy-up day that never comes.
03A dead library is one nobody removes anything from
There is a single sign that your library is dying, and it is not "few new prompts." It is this: *it has been a long time since you removed anything from it.*
A living library breathes both ways — it takes new ones in, and it pushes the spent ones out. If it only swells and never shrinks, it has stopped being an asset; it is turning into the exact forty-file "good prompts" folder I used to have. An asset that grows without bound and never gets pruned eventually costs more to hold than the value it creates.
So the health metric is not how many you have saved — it is when you last retired a prompt. If you cannot recall, your library has stopped living. A good prompt deserves to be saved so it can be reused; a bad one deserves to be sent off so it stops quietly charging you. Keeping both in the same place, as equals, is the surest way to forget which is which.