What is the real problem?
Not that there is nowhere to store them. That a good prompt is born once and then gets lost.
Someone spends half an hour assembling an instruction that produces exactly the kind of quote letter that is needed. Two weeks later they no longer remember which version was the good one. Their colleague does not even know it exists and writes their own, worse. Six months on, three people use three different prompts for the same thing, and nobody knows which is best.
Do not build a tool
The first idea is always a dedicated interface or a piece of software for the purpose. Don't — it is doomed, because you have to go there, and nobody goes.
A prompt library belongs where the team already works: the shared drive, the wiki, the notes app, the project tracker. A spreadsheet or a few documents is plenty up to the first hundred prompts.
The question is not what the most elegant solution is, but where people will actually look.
What should an entry contain?
Six fields. Fewer is not enough, more will not get filled in.
- Name — what it is for, in human language. "Quote cover letter for an SME", not "prompt_v3_final".
- When to use it — one sentence. This is what stops it being pulled out for the wrong situation.
- The prompt — exactly as it should be pasted, placeholders included:
[customer name],[text of the letter]. - One example — a real input and the good output that went with it. This is the most valuable field: it is what shows the next person what to expect.
- Owner — a name. Someone to tell when it stops working.
- Last checked — a date. More on this in a moment.
The date without which the whole thing goes stale
A prompt is not for ever. When the provider updates or retires the model, the prompts tuned to it will behave differently — and that is not a theoretical risk but a regular event.
The symptom is insidious: nothing errors, the output is just slightly different. Longer. Formatted differently. One field missing. Nobody notices for months, because everyone assumes that one case was just odd.
That is why you need the "last checked" date, and why it is worth keeping the saved example: if today's output differs materially from the saved one, you know something changed.
If you have a test set of twenty tasks — which is the subject of How to Read an AI Benchmark — then that same set works for maintaining the prompt library. On a model change you run it, and in half an hour you know what broke.
How should you name them?
By task, not by technology. People search for what they want to do.
Good: Customer complaint — draft reply, Minutes — pull out the decisions, Extract invoice data from a photo.
Bad: GPT prompt 4, Marketing v2, Tested prompt.
If there turn out to be a lot, group them by job role too — sales, customer service, finance — not by model or technique.
Start with five
The most common mistake is sitting down and trying to collect fifty prompts at once. The result is a long list of which ten get used, while the rest make noise.
Start with the five tasks you genuinely do every week. If those work and people actually use them, it grows on its own. If they don't get used, fifty would not have helped either.
As for writing the prompts, that is what meta-prompting is there for: you can have the model assemble them too, if phrasing is the hard part.
What belongs in the system prompt instead?
Whatever is the same for every task — the company name and how it is spelled, the tone, the forbidden topics — does not belong in the library but in the system prompt. You set it once there, and you do not have to copy it into every entry.
A practical signal: if the same paragraph appears in three library entries, then it is actually framing, not a task.
Two things worth forbidding
Customer data in the examples. A saved example is useful, but not with a real name and figure. It goes in once, then stays there, and a lot of people see the library.
A key or a password in a prompt. This seems obvious, and it still happens, when someone pastes in an API call as a template.
What to take away
Five entries where the team already works, each with an example, an owner and a date. This system is not elegant, but it works — and the maintenance depends on someone running them again when the model changes.