Prompts & Writing
Building a Prompt Library Your Team Will Actually Use
By Jim Vernon, Editor, AI Intelligence International · Published 4 February 2026 · Reviewed against our editorial standards · About the author
The usual arc is enthusiastic collection, a document of ninety prompts, and total abandonment by week eight. Nobody can find anything and half of them no longer work.
Libraries that survive are small, owned, tested and organised by task rather than by tool.
Key takeaways
- Organise by job to be done: People search for 'reply to an angry customer', not 'few-shot classification prompt'.
- Every entry needs the same fields: Task, when to use it, the prompt, an example of good output, known limitations, owner, last tested date.
- Test set per entry: Attach three real inputs to each prompt.
- Ownership and contribution: One named owner per category, with authority to reject additions.
Organise by job to be done
People search for 'reply to an angry customer', not 'few-shot classification prompt'. Name entries after the task in the language your team uses.
Cap the library at what a person can scan in a minute — for most teams, fifteen to twenty-five entries. Anything beyond that needs search, and nobody builds search for a prompt library.
Group into four or five categories at most.
Every entry needs the same fields
Task, when to use it, the prompt, an example of good output, known limitations, owner, last tested date.
The limitations field is what builds trust. A prompt presented as universally reliable will be blamed the first time it fails.
Last tested is what stops silent rot. Anything untested for six months should be flagged automatically by convention.
Test set per entry
Attach three real inputs to each prompt. When someone edits the prompt or the vendor updates the model, running three inputs takes five minutes and prevents a regression reaching customers.
This is the single practice that distinguishes a library from a scrapbook.
Store the expected characteristics of a good response rather than an exact expected output, since outputs vary.
Ownership and contribution
One named owner per category, with authority to reject additions. Open contribution without editing produces the ninety-prompt document.
Require a contributor to show three successful uses before an entry is added. Prompts that worked once are noise.
Review quarterly and delete aggressively. A deleted prompt costs nothing; a wrong one costs trust.
Make it available where the work happens
A library in a wiki nobody opens has no users. Put entries where the task occurs: in the helpdesk tool, in document templates, in the code editor, as saved assistants.
Duplication is acceptable if it means the prompt is at hand. Discoverability beats tidiness.
Track which entries are used. Unused entries are candidates for deletion or for better naming.
Measuring whether it works
Two signals: the share of outputs sent without material edits, and the number of people using the library monthly. Both are easy to sample informally.
If usage is low but people are using AI heavily, the library is not matching the real tasks. Interview three users rather than adding more entries — the answer is nearly always that the tasks in the library are not the tasks people actually do.
Structure that survives contact with real users
Organise by task, not by tool or by author. People search for 'reply to a late payment' rather than 'Marketing prompts v3', and a library organised the wrong way is a library nobody opens twice.
Give every entry four fields: what it is for, the prompt, an example of good output, and the owner. The example is what makes an unfamiliar prompt usable by someone who did not write it.
Cap the library. Forty maintained prompts beat three hundred abandoned ones, and the discipline of deleting is what keeps the good entries findable.
Curation is a job, not a culture
Libraries decay because contribution is easy and maintenance is nobody's task. Name one owner, give them thirty minutes a month, and have them delete anything unused for a quarter.
Track usage in the crudest way available — a reaction, a copy count, a quick poll. Without any signal, deletion becomes an argument rather than a decision.
Publicise additions in the channel the team already reads. A prompt library nobody hears about performs identically to one that does not exist.
Governance without bureaucracy
Two rules are enough for most teams: no confidential data in the prompt text itself, and anything customer-facing must carry a review note saying who checks the output before it ships.
Where a prompt encodes policy — refund terms, safety wording, regulated claims — link to the source document rather than copying it, so the prompt cannot drift away from the policy.
Review the whole library once a year against your current tools and terms. Most entries will still be right; the ones that are not are usually the ones with the most usage.
Frequently asked questions
Should prompts be secret?
Rarely worth protecting. The value is in the maintenance process and the domain knowledge encoded, neither of which transfers with the text.
Wiki, repo or dedicated tool?
Whichever your team already opens daily. Tool choice matters far less than ownership and proximity to the work.
How do we handle model changes?
Re-run the test sets for the top entries after any vendor update, and record the date. Ten entries take under an hour.
Who should own it overall?
Someone who does the work, not a central innovation team. Distance from the task is the main predictor of a dead library.
Where should the library live?
Wherever the team already works — the wiki, the shared drive, the assistant's own saved prompts. A new dedicated tool adds a login and halves adoption.
Should prompts be locked?
Editable with an owner named is the practical middle. Locked libraries go stale; unowned ones fill with near-duplicates.