How to Build a Shared Prompt Library for Your Team

Start small: collect 10 to 15 prompts for tasks the team repeats every week, test each on real examples, and save them as templates with blanks to fill, an example output, an owner and a last-checked date. Keep the library where people already work, and prune it monthly so only prompts that still work survive.

Most prompt libraries fail the same way. Someone pastes 200 prompts from the internet into a document, and nobody opens it after the second week. A useful library is small, comes from your own work and has someone looking after it. Below: how to harvest prompts from the team, a template for each entry, three sample entries from a physiotherapy clinic, five places to keep the library compared, and a routine that stops it going stale.

Follow me on Instagram@sagnikteaches

Harvest prompts from your own work, not the internet

The best prompts in your business already exist. They're sitting in people's chat histories, rewritten a little every time. Run a 20-minute harvesting session:

Connect on LinkedInSagnik Bhattacharya

1. Ask each person to bring their three most repeated writing or admin tasks, and the prompt they actually used last time, copied and pasted rather than remembered.
2. Group the prompts by task. You'll usually find three or four people doing the same job with different prompts.
3. For each task, test the versions side by side on the same real example and keep the best one, or merge the best parts.
4. Ask: "What does a good result look like?" and save one good output as the example.

Step 3 is where the value is. In an illustrative five-person removals firm, three people turned out to be writing quote follow-ups with three different prompts:

Subscribe on YouTube@codingliquids

OWNER:     "Write a follow-up email for a removals quote."

SURVEYOR:  "Follow up on this quote. Mention we still have
            [DATE] free. Keep it friendly."

OFFICE:    "Follow up on the attached quote. Mention our goods-
            in-transit cover and that the price includes
            packing materials. Don't offer discounts."

Run side by side on the same quote, the owner's version came back with "we'd be happy to offer 10% off if you confirm this week", a discount nobody had authorised. The surveyor's was the most persuasive, because a free date is a real reason to reply. The office version was accurate but ran to 280 words. The merged entry kept the surveyor's date slot, the office's cover line and no-discount rule, and added "under 100 words". It took ten minutes to agree, and the harvest session was the only time all three versions were ever in the same room.

Prompts that come from your own work already contain your context: your customers, your tone, your products. Generic prompts don't, which is why they produce generic results. If people struggle to describe the business to the AI, how to give AI your business context has a paragraph you can reuse across the whole library.

What goes into each library entry

A prompt on its own isn't enough. Colleagues also need to know when to use it, what to paste in, and what to check. Use the same fields for every entry:

NAME:            [Verb first, e.g. "Reply: new patient enquiry"]
USE IT FOR:      [One sentence]
DON'T USE FOR:   [The near-miss cases, e.g. complaints]
TOOL:            [Which approved tool, and which project/assistant]
DATA RULE:       [Green / amber / red; what must be removed first]

PROMPT:
[The full prompt, with [BLANKS] in capitals for anything
the person must fill in]

EXAMPLE INPUT:   [A short, anonymised real example]
EXAMPLE OUTPUT:  [What good looks like]
CHECK BEFORE USE:[The 2-3 things a person must verify]

OWNER:           [Name]    LAST TESTED: [Date]    VERSION: [1.2]

"Don't use for" and "check before use" are the fields people skip, and they prevent the most trouble. A reply prompt that works well for enquiries will produce a breezy, cheerful response to a complaint unless someone knows not to use it there.

Three sample entries from a physiotherapy clinic

These come from an illustrative physiotherapy clinic: an owner, two receptionists and six physiotherapists. Health information gets extra legal protection as sensitive personal data, so every entry carries a data rule.

NAME: Reply: new patient enquiry
USE IT FOR: First replies to enquiries by email or web form
DON'T USE FOR: Complaints, cancellations, anything about a
  current patient's treatment
DATA RULE: Amber. Paste the enquiry without surname, email,
  phone number or date of birth.

PROMPT:
You reply to enquiries for a physiotherapy clinic. Our services,
prices and opening times are below. Only use these details; if
the enquiry asks something not covered, say a member of the team
will confirm.
[PASTE CURRENT SERVICES AND PRICE LIST]
Write a reply under 120 words to this enquiry. Be warm and
plain. Offer the next step (booking link: [LINK]). Don't comment
on the person's symptoms or suggest a diagnosis.
Enquiry: [PASTE ENQUIRY]

CHECK BEFORE USE: prices and times match the current list;
no clinical advice; the first name is correct.

NAME: Rewrite: home exercise sheet in plain English
USE IT FOR: Turning a physio's written exercise instructions
  into a patient-friendly sheet
DATA RULE: Red for identifiers. No name, date of birth,
  condition details or notes. Instructions only.

PROMPT:
Rewrite these exercise instructions so someone with no medical
background can follow them at home. Keep every exercise, every
number of sets, repetitions and hold times exactly as written.
Don't add, remove or reorder exercises. Don't add advice about
pain, conditions or progress. Use short sentences and numbered
steps.
Instructions: [PASTE]

CHECK BEFORE USE: every number matches the original; nothing
added; the physio reads it before it's given to the patient.

NAME: Draft: monthly patient newsletter
USE IT FOR: The monthly email to patients who've opted in
DATA RULE: Green. No patient information at all.

PROMPT:
Draft a 250-word newsletter for a physiotherapy clinic from
the notes below. Friendly, practical, no hype. Don't promise
results from treatment or make claims about recovery times.
Include one simple tip related to [TOPIC] and end with the
booking link: [LINK].
Notes: [PASTE BULLET POINTS]

CHECK BEFORE USE: no health claims; the tip is approved by
a physio; dates and offers are current.

Here's why the exercise-sheet entry insists on "every number matches the original". A physio's instructions:

Bridge: 3x10, 5s hold at top.
Clams with band: 2x15 each side.
Calf raises on step: 3x12, slow down.

An illustrative first output:

1. Bridge: Lie on your back with your knees bent. Lift your
   hips and hold for 5 seconds. Do 3 sets of 10.
2. Clams with a band: Lie on your side with a band around your
   knees. Open and close your top knee. Do 2 sets of 15.
3. Calf raises: Stand on a step and rise onto your toes, then
   lower slowly. Do 3 sets of 12. Stop if you feel any pain.

Two problems, and neither is obvious at a glance. "Each side" vanished from the clams, so the patient does half the exercise. And "Stop if you feel any pain" was added, which sounds harmless but isn't the physio's instruction for a rehab exercise where some discomfort is expected. Both would reach the patient if the check step said only "read it through". This is the example output worth saving in the entry, with the two errors marked, so new users know exactly where to look.

Notice how much of each prompt is about limits: only use these prices, don't comment on symptoms, keep every number. The limits are what make a prompt safe to share with people who didn't write it.

Where to keep it: five options compared

For details of the Copilot option, see Microsoft's page on Prompt Gallery in Copilot.

For most small teams, the best arrangement is both: a master list in a shared document, which is the single source of truth and doesn't depend on any vendor, plus your five most-used entries set up as shared assistants inside the tool so people can use them in one click. If you ever change tools, the master list moves with you; keeping your data and prompts portable explains why that matters.

Naming and organising so people find the right prompt

• Verb first: "Reply:", "Rewrite:", "Summarise:", "Draft:", "Check:". People look for what they want to do.
• Group by role, then task: reception, clinical, owner. Nobody should scroll past forty entries to find theirs.
• A "start here" section with the five most-used prompts at the top.
• Two tags only: "customer-facing" (always checked by a person) and "internal". More tags than that and nobody applies them.
• A ceiling of about 30 entries for a team under 20. If you need more, some are probably duplicates.

Renaming is usually the first job after a harvest, because prompts arrive named after whoever wrote them. Part of the clinic's list, before and after (illustrative):

"Use this one not the old one" is the giveaway: it means an old version is still circulating. When you rename, find the old copies and delete them, or people will keep using whichever one they bookmarked.

Customer-facing entries benefit from consistent wording across the team. For replies especially, pair prompts with approved reply templates; writing reply templates that keep AI replies on-script shows how the two work together.

Building data rules into the prompts themselves

A policy document tells people what not to paste. A well-built prompt reminds them at the moment they're pasting. Three techniques:

• Placeholders that say what to remove: [PASTE ENQUIRY WITHOUT CONTACT DETAILS] rather than [PASTE ENQUIRY].
• A stop instruction: "If the text contains a full name, date of birth, address or phone number, don't continue; tell me to remove it first." It won't catch everything, but it catches the obvious slips.
• A data level on every entry, using the same green, amber and red categories as your policy.

What the stop instruction looks like in use, and where it falls short: a receptionist pastes a web-form enquiry that still includes the sender's full name and mobile number. An illustrative response: "This enquiry contains a full name and a phone number. Please remove them and paste it again." Good. But the next enquiry says "I'm 64 and had my knee replaced in March", and the tool carries on, because an age and a medical history aren't on its list. Treat the stop instruction as a seatbelt, not a driver: the amber rule and the placeholder wording still do most of the work, and it's worth adding "age or medical history" to the list once you've seen a slip like that.

If you haven't defined those categories, how to classify business data before using AI tools gives you a simple scheme. And keep the library itself inside a business account, since prompts often contain pricing, processes and internal detail you wouldn't publish.

Keeping it alive: owner, testing and retirement

Prompts drift. AI models are updated, your prices change, and a prompt that worked in spring produces something longer and stiffer by autumn. One person should own the library, often the team's AI champion (see choosing and supporting an AI champion), with a 20-minute monthly routine:

1. Re-test the five most-used prompts on a fresh real example. Compare with the saved example output.
2. Update anything that references prices, dates, services or staff names.
3. Ask the team which prompts they used and which they didn't. Retire anything unused for two months.
4. Add any new prompt someone has been using successfully, after testing it.
5. Update the version number and last-tested date on every changed entry.

A short change note under each entry makes the history readable. The clinic's enquiry-reply entry after a few months might carry (illustrative):

v1.0  Jun  First version, merged from 4 team prompts
v1.1  Jul  Price list updated (sports massage price change)
v1.2  Aug  Replies drifting to 200 words: added "under 120
           words" and a sample reply
v1.3  Sep  Added "don't mention waiting times" after two
           replies promised same-week appointments

When someone reports "the enquiry prompt used to be better", the log tells you which change to look at first.

Give the team a simple way to report a failing prompt, such as a message in a shared channel, and aim to fix reported problems within a week. A library people trust gets used; one that's been wrong twice gets ignored.

Launching it so the team actually opens it

A library nobody knows about is a document. Three steps turn it into a habit:

• Show, don't announce. At a team meeting, take one real task from someone's week and run it through the library entry live, including the check. Five minutes is enough.
• Put the link where people start work. Pin it in your team chat, bookmark it on shared computers, and mention it in the instructions of each shared assistant.
• Ask one person per role to trial it for a fortnight and report back on what was missing or confusing. Their fixes make the second version far better than anything you'd write alone.

The trial feedback is rarely about the prompts themselves. At the clinic, the receptionist's fortnight produced three notes: "[LINK] doesn't say which link, and we have two booking pages"; "there's no entry for rescheduling, which is half my replies"; and "I can't tell which entries are safe to use with a patient's details". The first was fixed by naming the blank [NEW PATIENT BOOKING LINK]; the second became entry 13; the third led to the data level being moved from the bottom of each entry to the line directly under its name, where it's seen before anything is pasted.

After launch, the most useful single question at team meetings is "Did anyone write a prompt this week that worked better than the library one?" That's how the library keeps improving.

When an entry should become an automation

Some library entries outgrow copy and paste. If a prompt is used more than about 20 times a week, always takes the same kind of input, and its output always goes to the same place, it may be worth automating: for example, a web-form enquiry that's drafted into a reply automatically and waits in the inbox for a person to approve. Signs an entry is ready:

• People paste the same fields in the same order every time.
• The check step rarely finds problems any more.
• The main cost is now the copying, not the thinking.

A quick sum shows whether it's worth it. Say the clinic's enquiry-reply entry is used about 35 times a week, and each use involves around three minutes of opening the tool, pasting the price list and enquiry, and copying the reply back into the inbox. That's 105 minutes a week of pure handling, close to 90 hours a year. An automation that drafts the reply as soon as the web form arrives, and leaves it waiting for a receptionist to check and send, removes most of that. An entry used five times a week saves about 15 minutes, which rarely justifies building and maintaining anything.

Keep the human approval step when you automate anything customer-facing. The prompt you've tested and refined in the library becomes the instructions for the automation, which is one more reason to keep it well documented.

Worked example: the clinic's library after three months

Back to the illustrative clinic. The harvesting session produced 34 prompts from eight people. Grouping them showed only 12 distinct tasks; the rest were variations of the enquiry reply, the exercise-sheet rewrite and the newsletter. The owner merged them into 12 entries and set up the three most-used as shared assistants in the clinic's AI tool.

• Time saved: physiotherapists timed exercise-sheet rewrites at about 12 minutes by hand and about 4 minutes with the shared prompt, including the check. Six physios writing around ten sheets a week each save roughly 8 hours a week between them.
• One drift caught: in month two, the monthly re-test found enquiry replies had crept up to about 200 words and turned formal. Adding "under 120 words" and a sample reply to the prompt fixed it.
• Pruning: after three months, 9 entries were in regular use, 3 had been retired (nobody used them), and 2 new ones had been added from the team.

The library ended the quarter smaller than it started, which is usually a sign it's working. Consistency improved too: patients received replies and exercise sheets in the same voice whoever wrote them, the same goal as writing AI prompts that sound like your business.

Further reads

• ChatGPT Prompts for Small Business Owners: 50 Tested Examples — Ideas for tasks your library doesn't cover yet.
• How to Get Your Staff to Actually Use AI Tools — A library helps only if people open the tool at all.
• How to Build a Brand Voice Guide That AI Can Follow — A voice guide your prompts can all point to.
• How to Build a Company Knowledge Base AI Can Answer From — When prompts need your policies and prices behind them.
• Why AI Gives Different Answers Each Time, and How to Fix It — Why a tested prompt can still give varied results.
• How to Train Staff to Use AI in a Small Business — Training sessions are a good source of first entries.
• How to Handle Staff Who Over-Rely on AI — Signs of AI over-reliance, a conversation script, a three-rule standard to put in writing, and when a pattern needs a formal process.
• AI Quick Wins: 12 Things a Small Business Can Set Up This Week — Twelve small AI jobs sorted by setup time, each with a copyable prompt, a real business example and the catch to watch for.
• How to Scale AI From One Workflow to the Whole Business — How to copy your first working AI workflow across the business: a readiness gate, a playbook template, adjacency rules and a pet shop's nine months.
• How to Review an AI Tool After 90 Days: Keep, Fix or Cancel — An evidence pack, a ten-point scoring sheet, a worked split verdict for four Copilot seats and a checklist for cancelling without loose ends.
• AI Literacy Requirements: What Your Staff Need to Know — A role-by-role checklist of what staff should know about AI, what Article 4 of the EU AI Act asks since the 2026 changes, and how to record it.
• How Much Time and Money Does AI Staff Training Take? — Training hours by role, free and paid course options with current prices, a costed plan for an eleven-person decorating firm, and how to check it paid off.
• How to Onboard New Hires Onto Your AI Tools and Rules — A first-month plan for new starters on your AI tools: accounts before day one, one-page rules, buddy-checked tasks and a sign-off for wider access.
• How to Use AI on Your Own Admin First, Then Roll It Out — A six-week owner-first plan: pick three of your own admin jobs, log what AI saves and gets wrong, write a playbook, then hand one task to one person.
• How to Run a 60-Minute AI Workshop for Your Team — A minute-by-minute plan for a one-hour AI session: preparation, live demos on real tasks, paired practice, data rules and the week after.
• How to Roll Out an AI Policy So Staff Actually Follow It — The launch plan for an AI policy: one-page rules, an amnesty for hidden tools, paid accounts that beat free ones, and checks that don't feel like spying.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Microsoft Learn (Copilot Prompt Gallery); Google Workspace Updates and Gemini Apps Help (sharing Gems); OpenAI help documentation (Projects in ChatGPT); Claude help documentation (project visibility and sharing), all checked September 2026.