Prompt Libraries
Turning the prompts that work into a shared asset instead of something each person rediscovers.
In most businesses using AI, the useful prompts live in three people's chat histories and nowhere else.
Everyone works out what gets good results, nobody writes it down, and each new person starts from scratch. It's the same failure as undocumented processes, in a newer tool.
A prompt library fixes it, and it's a small piece of work.
Read the documentation standards · Request Your Free Systems Audit
What belongs in one
Not every prompt. Most are one-offs and should stay that way.
A prompt earns a place when it is:
Repeated. Used more than a few times, by more than one person.
Tuned. It took iteration to get right, and that iteration is worth preserving.
Consequential. The output goes somewhere it matters — to a customer, into a document, into a decision.
Everything else is conversation.
The structure of an entry
A prompt on its own isn't enough. The context is half the value.
───────────────────────────────────────────
[Name — what it produces]
───────────────────────────────────────────
PURPOSE
[What this is for, one sentence]
WHEN TO USE
[The situation. And when not to.]
INPUTS NEEDED
[What you must supply for it to work]
THE PROMPT
[The text, with [PLACEHOLDERS] clearly marked]
EXPECTED OUTPUT
[What good looks like — ideally a real example]
KNOWN LIMITATIONS
[Where it produces poor results]
Owner: [name]
Version: [number]
Last reviewed: [date]
Known limitations is the section that saves the most time. It stops the next person spending twenty minutes discovering the same failure.
Writing prompts worth keeping
State the role and the output format
Both reduce variance. "Write a summary" produces something different every time. "Write a three-sentence summary for a customer who hasn't seen the product" produces something consistent.
Give examples
One good example of the output you want does more than three paragraphs of description. Two examples that differ usefully do more still.
Say what to leave out
Negative instructions matter as much as positive ones. "Don't include pricing" and "don't invent details not present in the source" prevent the two most common problems.
Mark the variable parts clearly
Summarise the following enquiry in three sentences.
Enquiry:
[ENQUIRY TEXT]
Do not include pricing. If the enquiry is unclear about what
they want, say so rather than guessing.
Anyone can use that without being told how.
Don't over-engineer
A prompt that works is a prompt that works. Elaborate structures copied from somewhere else usually add length rather than quality. Test the simple version first.
Organising the library
By task, not by tool. The job is stable; which model you use for it isn't.
Flat beats deep. Fifteen prompts in one list is more usable than fifteen across five nested folders.
Searchable. People will look for "customer reply" or "summarise," not for a category name.
One location. The same rule as all documentation: the most common failure is ending up with three places and no one knowing which is current.
Maintenance
Prompts go stale in ways documents don't — the model changes underneath them.
Review quarterly. Run each prompt, check the output is still what you expect.
Re-test after any model change. A prompt tuned for one version may behave differently on the next, usually subtly rather than obviously.
Version when you change it. And keep the previous version until the new one is proven.
Delete what nobody uses. A library of sixty prompts where eight are used is a search problem.
Who owns it
One person. Not to write every prompt — to decide what enters the library, keep the structure coherent, and run the quarterly review.
Without this, you get a library where half the entries lack context, three of them do the same thing differently, and nobody trusts any of it.
Shared prompts and personal prompts
Keep them separate.
Personal prompts are someone's working method, and they shouldn't have to meet a standard before being useful.
Shared prompts are infrastructure. They carry the structure above, they have an owner, and they get reviewed.
The route between them should be easy: someone finds a personal prompt is being asked for by colleagues, it gets written up properly, it joins the library.
What not to put in prompts
Credentials or secrets. Including in examples.
Customer data. Use placeholders. A prompt library containing real customer details is a data problem waiting to be noticed.
Anything confidential as an example. Examples get copied, shared and pasted into tools you didn't choose.
From library to workflow
A prompt used often enough and reliably enough stops belonging in a library and starts belonging in an automation.
The signals: it runs on a predictable trigger, the inputs come from a system rather than a person, the output goes somewhere specific, and the quality has been consistent over a reasonable period.
When all four are true, the prompt becomes part of a workflow, and the same rules apply as any other automation — specification, error handling, acceptance tests, monitoring.
Until then, the library is the right home.
The prompts that work are an asset. Treat them like one, or everyone keeps rediscovering them.
Want your AI work properly organised?
A free systems audit covers how your business uses these tools and where the effort is being duplicated.