Building a Shop Prompt Library the Office Will Actually Use

Why this matters

In most shops that use AI, every person has their own way of asking for the same thing. The coordinator's delay emails sound one way, the owner's sound another, and the new hire's include a discount nobody approved because her improvised prompt said "make it apologetic." A shared prompt library fixes that the same way a price book fixes pricing: one tested version of each recurring request, kept by one person, changed on purpose. The hard part is not writing the prompts. It is building something the office reaches for instead of typing from memory, and noticing when a prompt that worked in spring has started producing something different by fall.

How to write one good prompt is covered by a sibling card; see related: How to Write a Prompt That Gets a Usable Scope of Work. This card is about the collection: what goes in, how each entry is kept, and how entries are retired.

Pick the six to eight jobs that repeat

A library earns its keep on frequency. Pull the last month of AI use in the office (ask people, or look at their chat histories together) and list the requests that came up at least weekly. In a typical residential shop the list lands close to this:

1. Estimate scope description from tech notes
2. Delay or reschedule email to a customer
3. Clean invoice line description from a messy tech note
4. Reply to a customer complaint, first draft
5. Job posting for a technician role
6. Summary of a long manufacturer document the office pasted in
7. Review response, positive and negative variants
8. Internal SOP draft from a tech's spoken walkthrough

Stop at eight. A library of thirty prompts is a library nobody searches, and the long tail of one-off requests is better served by people knowing the four elements of a good prompt than by a template for each.

Leave out anything that should not be done with AI at all. Pricing, warranty decisions and safety advice to customers do not get library entries, because an entry implies permission. The shop's rule on which tasks are allowed is set in The Shop AI Use Policy SOP.

Build each entry as a card with the same fields

Every prompt lives on a card. The card is the unit people copy from, and its fields are what keep it trustworthy:

NAME:      DELAY-EMAIL v3
OWNER:     Office manager (Rosa)
USE FOR:   Tech running late or job moved, same week
NOT FOR:   Cancellations, complaints, anything with a
           credit or refund
PROMPT:
  You are writing a short email from a home service
  company to a customer. Plain, warm, no exclamation
  marks. FACTS: original window [WINDOW], new window
  [NEW WINDOW], reason in one line [REASON]. RULES:
  no discounts, credits or apologies beyond one
  sentence. No promises about later appointments.
  Under 90 words. Sign as [OFFICE NAME].
CHECK:     New window matches the board. Reason
           matches the tech's note. No offer added.
GOOD OUTPUT: see example on back
LAST TESTED: 2026-10-03, 3 of 3 clean
CHANGED:   v2 -> v3 added "no discounts" after the
           tool began offering 10 percent off

Why each field is there:

• NAME with a version. "DELAY-EMAIL v3" in the subject line of a saved file or the title of a shared note is searchable and tells you whether the copy in someone's notes is current.
• OWNER. One person, by name. Without an owner, nobody fixes a prompt that has drifted, because everyone assumes someone else will.
• USE FOR / NOT FOR. The NOT FOR line does more work. Delay emails slide into cancellations and complaints, and those need different handling.
• PROMPT with bracketed placeholders. Brackets show exactly what the user fills in and make it obvious when someone pasted a customer name into the template itself.
• CHECK. The two or three things a reviewer verifies on this specific output, so review is a short list rather than a general read. The full checking standard belongs to The Verify-Before-You-Send Rule for AI Output; the card only names what matters for this prompt.
• GOOD OUTPUT. A real, approved example. People calibrate against examples far better than against instructions.
• LAST TESTED and CHANGED. The audit trail that makes drift visible.

Put it where the office already works

The library lives wherever the office already has its hands: a pinned shared document, a folder of text snippets in the email client, the canned-reply feature of the field software. Not a new app. A library one extra click away from where the email gets written loses to typing from memory every time someone is busy, which is whenever it matters.

Each card's PROMPT block should be copyable in one action. If people have to assemble it from three places, they will paraphrase it, and the paraphrase is a new, untested prompt.

Give it one owner and a test date

The owner's job is small and specific:

• Test each card once a month. Run it three times on realistic fill-ins and read the outputs against the CHECK line. Three runs, because these tools produce different text each run and one clean output can hide an occasional bad one.
• Record the result on the card. "3 of 3 clean" or "2 of 3 clean, run 2 added a promise."
• Take reports. Anyone who sees a library prompt produce something odd tells the owner the same day, with the output pasted.

That is roughly an hour a month for eight cards. It is the cheapest insurance in the whole AI setup, because the tools change underneath you: vendors update the model behind a chat assistant without asking, and a prompt tuned to last quarter's behavior can start producing different text with no change on your side.

Worked example: a prompt that drifted

Rosa's delay email card was at v2 and had tested clean every month since spring. The v2 rules said: "plain, warm, apologize once, under 90 words."

On October 3 a coordinator mentioned that a customer had replied asking how to claim "the 10 percent." Rosa searched the sent folder and found that four of the last eleven delay emails sent from the template carried a closing line offering 10 percent off the next service. Nobody had approved a discount, and nobody had noticed, because the line sounded like something the shop might plausibly say.

Rosa ran v2 three times that afternoon. Two of the three outputs offered a discount. The vendor had updated the tool during the summer, and the newer behavior read "apologize" as license to add a goodwill gesture. The prompt had not changed. Its output had.

What she did, in order:

1. Pulled v2. Marked the card RETIRED with the date and the reason, so anyone holding an old copy would see it.
2. Counted the exposure. Four emails with the offer, out of eleven sent from the template since the last clean test on August 29. Four is about 36 percent of eleven. She sent the four to the owner.
3. Owner made the call. Honor the discount for those four customers, because the shop had made the offer in writing, and say nothing further. This is a business decision, not an AI decision, and it went to the person who owns it.
4. Wrote v3. Added an explicit rule: "no discounts, credits or apologies beyond one sentence." Added "no offer added" to the CHECK line.
5. Tested v3 three times: 3 of 3 clean. Recorded the date.

The number that mattered was not the four emails; it was the 35 days from the last clean test on August 29 to the customer's reply on October 3. The test due September 29 had slipped, so a customer found the drift before the shop did. Her change afterwards: the CHECK line on every customer-facing card now names the specific thing that card must never contain, so a reviewer looks for it on every send rather than once a month.

Retire a prompt when its job changes or its output does

Three triggers retire or revise a card:

• Drift. Fewer than three of three clean on the monthly test. Do not wait for a second bad month; one failed run on a customer-facing prompt means customers are receiving that output.
• The job changed. The shop changed its reschedule policy, its tone, its warranty. Every card that touches the change gets revised the same week.
• Nobody uses it. A card that went three months without use comes out. Dead cards make the live ones harder to find, and an unused card is not being tested in real use.

A retired card stays in an archive folder with its CHANGED history. When a dispute comes up later about what an email said, the version that was live that week is the evidence.

When one card should become two

A card that keeps collecting exceptions is two jobs sharing a name. The tell is a USE FOR line that grows clauses ("delay email, or cancellation if the customer asked, or a reschedule after a no-show") and a CHECK line that has to cover all of them. Split it. The reschedule-after-no-show email has a different job: it may mention a trip charge, which is a commitment, so it needs a sign-off the plain delay email does not.

The opposite case also comes up. Two cards whose PROMPT blocks differ by one rule ("formal" versus "friendly") are one card with a bracketed [TONE] placeholder. Merge them, keep the stricter CHECK line, and retire the other with a pointer to the survivor so old copies lead somewhere.

The test for either move is the same: could one reviewer apply one CHECK line to every output this card produces? If not, split. If two cards share a CHECK line word for word, merge.

How to know the library is working

Two checks, both quick. First, ask three people to show you how they wrote their last delay email. If any of them typed a prompt from memory, the library is in the wrong place or the card is hard to copy. Second, compare five sent messages from the same card. They should be recognisably the same shape with different facts. If they differ in what they promise, the CHECK line is not being used, and the fix is a shorter, sharper CHECK, not more training.

References

• See related: How to Write a Prompt That Gets a Usable Scope of Work
• See related: The Verify-Before-You-Send Rule for AI Output
• See related: The Shop AI Use Policy SOP
• See related: The Automation Change Control SOP