Every team that uses AI for more than a month ends up with a prompt library, whether anyone planned one or not. It lives in a Slack thread from March, three people’s chat histories and a Google Doc called “good prompts FINAL v2”. An AI prompt library worth having is smaller and more boring than that: a short list of tasks your business repeats, each with an owner, a clear set of inputs and a record of when someone last checked that it still works.
This article assumes you already know how to write a decent prompt. If you don’t, start with the beginner’s guide to prompt engineering for small businesses and come back. What follows is the part most guides skip: structure, ownership, versions and retirement.
A saved prompt is not yet a work instruction
A saved prompt is text that once produced something good. A work instruction is that text plus everything a colleague needs to repeat the result without asking you: what to paste in, what the output should look like, who judges it and which tool it was written for.
Consider a prompt that says “Write a follow-up email based on these notes in our usual tone.” To its author, “these notes” means the tidy bullet list they make after every call. A new hire pastes in a raw transcript, gets a cheerful 400-word email and sends it. The prompt didn’t fail. The library did, because it stored the words and threw away the context.
The rule for the whole system: if someone who has never spoken to the author can’t use a prompt correctly, it is a draft and stays out of the shared library.
The fields each record needs
You can run this in a spreadsheet, a Notion database or an Airtable base. The tool matters far less than the fields. Treat these as mandatory; the third column explains why each one exists.
| Field | What goes in it | Why it earns its column |
|---|---|---|
| ID and name | Short code plus plain name, e.g. CLI-03 Client recap email | People search by task, and the ID survives renames |
| Task | One sentence describing the job and when to use it | Stops misuse on unrelated jobs |
| Owner | One named person, not a team | Someone has to answer questions and approve changes |
| Required inputs | Exactly what the user must paste or attach, in what form | Most bad outputs come from bad inputs, not bad prompts |
| Prompt | The full text, with placeholders in [SQUARE BRACKETS] | Placeholders show what changes each time and what never should |
| Sample output | One approved real or sample result, labelled as such | Shows the target faster than any description of it |
| Review criteria | Three to six checks a human makes before using the output | Makes “good enough” explicit |
| Model or environment | Where it was written and checked, e.g. ChatGPT project, Claude, Copilot | The same text can behave differently in a different tool |
| Version | v1.0, v1.1, v2.0 | Lets people know they are using the current one |
| Last review date | Date the owner last confirmed it still works | The cheapest early warning you will ever get |
| Status | Draft, Active, Under review, Retired | Only Active entries go in the default view |
A copyable starter library
Here is a starting table with six entries for an illustrative business: Fieldnote Studio, a four-person design and marketing studio invented for this article. The owners and dates are sample data. Replace the tasks with the jobs your own team repeats most. Three trusted entries beat forty untested ones.
| ID | Name | Task | Owner | Required inputs | Environment | Version | Last review | Status |
|---|---|---|---|---|---|---|---|---|
| CLI-03 | Client recap email | Turn call notes into a recap with decisions and next steps | Mara (account lead) | Bullet notes, client name, agreed deadlines | ChatGPT project “Client comms” | v1.2 | 2026-09-30 | Active |
| BRF-01 | Brief gap check | List missing information in an incoming client brief | Jonas (strategy) | Full brief text, project type | Claude project “Briefs” | v2.0 | 2026-09-12 | Active |
| SOC-02 | LinkedIn post from case note | Draft a post from an approved project summary | Ana (content) | Approved summary, client permission yes or no, link | ChatGPT project “Content” | v1.0 | 2026-10-02 | Active |
| PRO-04 | Proposal scope section | Rewrite internal scope notes as a client-facing scope section | Jonas (strategy) | Scope notes, price band, exclusions list | Claude project “Briefs” | v1.1 | 2026-08-20 | Under review |
| OPS-01 | Weekly status summary | Summarise the week’s project tracker export for the Monday meeting | Mara (account lead) | CSV export, list of at-risk projects | Copilot Chat | v1.0 | 2026-09-25 | Active |
| SEO-02 | Meta description set | Write three meta description options for a published page | Ana (content) | Page URL or text, primary keyword | ChatGPT project “Content” | v0.3 | 2026-10-10 | Draft |
Notice that PRO-04 is under review and SEO-02 is still a draft. That is normal. A library where everything is permanently Active is usually a library nobody is reviewing.
One complete record, filled in
Below is the full record for CLI-03, the client recap email. Everything here, including the sample output, is illustrative. The prompt itself borrows heavily from the principles in the guide to writing AI instruction prompts that say what to do: tell the model the format and the limits rather than a list of vague prohibitions.
| ID and name | CLI-03 Client recap email |
|---|---|
| Task | Turn the account lead’s notes from a client call into a short recap email confirming decisions, open questions and next steps. Use within 24 hours of the call. Do not use for disputes, pricing changes or anything with legal weight. |
| Owner | Mara (account lead) |
| Required inputs | 1. Bullet notes from the call (not a raw transcript). 2. Client contact’s first name. 3. Any deadlines agreed on the call, with dates. 4. Anything the client asked us to hold back from writing down. |
| Prompt |
You are drafting a recap email from a small design studio to a client after a project call. Use only the information in the notes below. Do not add commitments, dates or prices that are not in the notes. Client first name: [NAME] Agreed deadlines: [DEADLINES] Notes: [PASTE NOTES] Write the email in this structure: a one-line greeting using the first name; a two-sentence summary of what the call was about; a section headed “What we agreed” as a short list; a section headed “Open questions” as a short list, or omit it if there are none; a section headed “Next steps” listing who does what by when. Keep it under 180 words. Plain, friendly British English. No exclamation marks. End with “Best, Mara”. After the email, add a line starting “CHECK:” listing anything in the notes that was ambiguous or that you left out. |
| Sample output (illustrative) |
Hi Tom, Thanks for the time today. We went through the first round of packaging concepts and agreed how to take the label design forward. What we agreed: we will develop concept B further; the green stays, the serif headline font goes. Open questions: whether the 250 ml size needs its own layout. You will check with production. Next steps: Fieldnote sends revised concept B by 24 October. You confirm the 250 ml question by 21 October. Best, Mara CHECK: Notes mention “budget chat later” with no detail. Not included. |
| Review criteria | 1. Every date and decision appears in the original notes. 2. Nothing from input 4 has been included. 3. Under 180 words. 4. The CHECK line has been read and resolved before sending. 5. Mara or the person who ran the call sends it, not the person who generated it. |
| Model or environment | ChatGPT project “Client comms”, project instructions contain the studio’s tone notes |
| Version | v1.2 (v1.1 added the CHECK line after a recap went out with a guessed deadline) |
| Last review date | 2026-09-30 |
| Status | Active |
The CHECK line is the single most useful addition in that record. It asks the model to point at its own uncertainty, which turns the human review from “does this look fine” into “resolve these two specific things”. The version note records why the change happened, so nobody reverts it later because the old prompt was shorter.
Keep brand voice rules in one place and reference them instead of pasting adjectives into every prompt. The brand voice and identity prompts are a reasonable starting point for writing those rules down in the first place.
Where the library should live
Most AI tools now have some way to save and share instructions, and it is tempting to treat one of them as the library. Microsoft’s Copilot Prompt Gallery lets users save prompts and share them with a Microsoft Teams team. ChatGPT projects can be shared with collaborators, carrying their files and instructions with them. Claude Team and Enterprise plans let you share projects with view or edit permissions, and Google lets people share Gems, its customised versions of Gemini. Custom GPTs are another option, though OpenAI notes that personal ChatGPT accounts can no longer create new GPTs, so on Free, Go, Plus or Pro you would be relying on projects instead. (Features checked 18 October 2026.)
These are good distribution channels and poor master records. None of them shows owner, review criteria and version history on one screen, and each locks the library inside one vendor. For a small team the sensible setup is to keep the master record in a spreadsheet or database that everyone can read, and use the tool features to deliver the Active prompts where people actually work. If the two ever disagree, the master wins.
Names, permissions and who can change what
Naming sounds trivial until a search for “email” returns nineteen results. Use a short prefix by area (CLI for client work, SOC for social, OPS for operations) followed by a number, then a plain name that describes the output rather than the cleverness of the prompt. “Client recap email” is findable. “Mara’s magic follow-up” stops being magic the day Mara leaves.
For permissions, keep it simple. Everyone can read Active entries and copy them. Anyone can suggest a change through a comment. Only the owner edits the prompt and bumps the version. If you use shared projects in Claude, the view and edit roles map neatly onto this. In a spreadsheet, protect the prompt column and leave the comments open.
Use version numbers with some discipline. Wording tweaks go from v1.1 to v1.2. A change to inputs, output structure or tool is v2.0, because people must change how they use it. Keep old versions in a history tab.
Retiring prompts before they cause trouble
Prompts go stale for dull reasons. The model behind your tool changes and starts ignoring a constraint, your services change while the prompt still describes the old ones, or the owner leaves. Stale entries are worse than missing ones, because people trust them.
Three rules handle most of this. First, any entry without a review in the last 90 days moves to “Under review”. In a spreadsheet, one conditional formatting rule on the date column makes those entries impossible to miss. Second, when an owner leaves, their entries go to Under review until someone else takes them on. Third, retire rather than delete: set the status to Retired, add a one-line reason and the replacement ID if there is one. Someone will eventually ask why the studio stopped using BRF-01 v1, and the answer will be there.
At review time, the owner reruns the sample inputs and checks the result against the review criteria. For a library this size, that is enough.
Making sure people use the right version
The last problem is behavioural. People keep personal copies, and a personal copy is a fork that never gets updated. The fix is to make the shared version easier to reach than the private one. Pin a link to the library in the team channel and the onboarding notes. Ask people to keep the ID and version (for example “CLI-03 v1.2”) in the title of any chat or document where they used it, so that when an output looks off you can ask “which version did you use?” and get an answer. And once a month, spend fifteen minutes in the team meeting on one question: which prompt did someone rewrite on the fly this month, and should that rewrite become the new version?
If your team is still choosing which jobs to hand to AI in the first place, the guide to picking a first process for workflow automation uses a similar idea of owners and review points. If you would rather have someone set up the library and the first dozen records with your team, BBDirector does that kind of work, and you can get in touch here.
