In many small teams, good prompts live in one person's chat history. A colleague asks for "that prompt for customer replies", gets a pasted version from last month, and the team ends up with five slightly different versions and no idea which one works. A shared library fixes this, but only if it stays small and somebody looks after it.
This article describes a lightweight setup that a team of five to thirty people can build in an afternoon, using a shared document or a folder the team already has.
What to save
Not every prompt deserves a place in the library. Save a prompt when all three are true:
- it is used at least a few times a month, by more than one person,
- the output feeds into real work, such as a customer reply, a summary or a draft report,
- you can describe in one sentence what a good result looks like.
One-off questions, experiments and anything with private customer data pasted in stay out. A prompt in the library should contain placeholders, such as [customer name] or [paste text here], never real data.
For each saved prompt keep a short card:
- Purpose in one sentence ("Summarise a supplier email into three action points").
- The prompt text with placeholders marked.
- Input needed and what must not be pasted in.
- Example of a good result.
- Tool and model it was tested with, since the same text can behave differently elsewhere.
- Owner and last review date.
If your team is still deciding which tasks are worth this effort, an AI audit of where it saves time and money gives a way to choose.
Name prompts so people can find them
Use one pattern for every title, for example area - task - version: "Support - reply to delivery complaint - v2". Agree on a short list of areas (support, sales, finance, operations, HR) and stick to it. Avoid names such as "good summary prompt" or personal names.
A flat list sorted by area is enough for most teams. Resist the urge to build folders within folders; with thirty prompts, search works better than a tree.
One owner per prompt
Every prompt has a single named owner, usually the person who uses it most. The owner:
- approves changes to the text,
- keeps the example and the test sample up to date,
- answers questions from colleagues,
- decides when the prompt is retired.
Everyone else may suggest an improvement by adding a comment or a copy marked "proposal". They do not overwrite the original. This keeps a working prompt from being broken by a well-meant edit on a busy Friday.
Also name one person who looks after the library as a whole. This is a small job, perhaps thirty minutes a month: check that every prompt has an owner, that names follow the pattern and that nothing contains private data.
Test before and after every change
A prompt is a small piece of instructions that produces different output each time, so "it worked for me once" proves little. Keep a test sample with each prompt: three to five realistic inputs, with the result you would accept. These can be anonymised examples from real work.
When the owner edits a prompt, or when the team switches to a different model or tool, run the sample again and compare the results with the saved ones. Write one line in the change log: date, what changed, whether the sample still passes. If a result is wrong or invented, that is a reason to fix the prompt or to add a human check; see why AI hallucinations happen and how to limit them.
For tasks where the output goes straight to a customer, a person should read the result before it is sent. The library does not remove that step.
Retire prompts on a schedule
Libraries fill up with prompts that nobody uses. Set a review every quarter, using the library manager or the owners:
- Not used for three months: archive it, do not delete it.
- Replaced by a better version: archive the old one and point to the new one.
- Fails its test sample after a tool change: fix it within a month or retire it.
- Owner has left: assign a new owner or archive.
Archived prompts go into a separate "archive" list with a one-line reason. If somebody asks for one a year later, you can find it, and you can see why it was dropped.
Start with five prompts
Do not try to collect everything. Ask each team member for the one prompt they use most, pick five, write the cards and test them. Show the team where the library lives and who owns what. After a month, look at what people actually used and add the next five. For inspiration on everyday prompts that are worth saving, see five prompts I use every day. If you also keep company documents for the AI to draw on, the same ownership thinking applies to an AI knowledge base.
Common mistakes
- Collecting too much. A library of two hundred prompts is a library nobody reads.
- No owner. Prompts without an owner drift and break quietly.
- Real data in prompts. Keep placeholders only; check this in the monthly look.
- No test sample. Without it, nobody can tell whether an edit helped.
- Hiding the library. Put the link where the team already works, such as the team chat channel header.
Summary
A shared prompt library works when it is small and looked after. Save only prompts that are used repeatedly, name them with one pattern, give each one an owner, keep a few test examples and retire prompts every quarter. It takes an afternoon to set up and about half an hour a month to maintain.
Sources
- Common practice for working with AI tools in small teams, offered as a practical guide. No client results or market figures are claimed in this article. Adapt the card fields, the review interval and the owners to your own team, and follow your company rules and local law on personal data.