Every team ends up with a prompt library, and most of them become archaeology within a year: six versions of the same instruction, no dates, and nobody sure which one is current. The failure is not the model; it is the absence of conventions.
Four conventions fix most of it. They are unglamorous and they are the difference between a library and a folder.
The short answer
One file per prompt, a stated input and output shape, a check, and a date. If the prompt cannot state what it returns, it is not ready to be shared.
Convention one: one file, one job
A prompt that does three things is three prompts in a trench coat. Splitting them makes each one testable and lets the model do one job well.
The split is also how you discover that one of the three was never a prompt — it was a skill. If the instruction repeats weekly with the same structure, it belongs in a SKILL.md rather than a prompt folder.
Convention two: state the shape
Every prompt should say what comes back. A list of fields, a section order, or a single paragraph — but something. Without it, two people running the same prompt get outputs they cannot compare, and the library stops being a library.
A prompt that returns an unlabelled wall of text is a prompt nobody will reuse.
Convention three: a check you can run
The check can be trivial: does every finding have a file and a line, does every step have an owner, is there exactly one recommendation. The point is not rigour; it is that a change to the prompt can be evaluated.
Without a check, every edit is a judgement call, and the library drifts one opinion at a time.
Convention four: a date and an owner
Two fields prevent most of the decay: when it was last run, and who is responsible for it. A prompt with a date from eight months ago is a prompt that probably no longer works with the current model.
The date also answers the question that kills libraries: which version is current. The answer should be the file, not someone's chat history.
The comparison
| Convention | Prevents | Cost |
|---|---|---|
| One file, one job | Prompt sprawl | A few more files |
| Output shape | Incomparable results | One paragraph |
| A check | Silent drift | One line |
| Date and owner | Stale prompts | Two fields |
All four are cheap. The reason libraries fail is that nobody writes them down as rules, so each new prompt is created ad hoc.
When to promote a prompt to a skill
The test is frequency and sameness: if you paste it every week with the same structure, it is a skill. The prompt becomes the prototype; the skill is the version with a trigger and a check.
Prompts that stay prompts are the genuinely variable ones: a different audience, a different format, a different tone each time. Those should not be standardised, because standardising them would produce the averaged voice everyone complains about.
A worked example
A team has a prompt for release notes. It has drifted into six versions, each returning a different structure. The fix is not a better prompt; it is a version in the library with a stated output shape (three sections), a check (every shipped item appears with a date), and an owner.
Two months later, the format changes. The owner edits one file, the date changes, and the team uses the new version. That is the whole maintenance model.
Frequently asked questions
Should prompts live in git? Yes — with the code, so reviews and edits travel together.
How do I stop people pasting prompts from elsewhere? You do not. You make the library the easiest place to get a working prompt, which is a design problem, not a policy one.
Where do prompts and skills overlap? The overlap is the migration path. See prompt to skill and prompt library.
Last checked: 12 November 2026.
Related: prompts that survive contact with reality, a skill library that stays useful, and prompts.
