A prompt library: don't rewrite what already works

A good prompt is a tool, not a one-off note. Once you find a phrasing that reliably delivers a usable result — for meeting notes, a complaint response, or a contract summary — there's no point reinventing it every time you need it again. Tools don't get lost — you store them in one place and just pull them out next time.

A prompt library isn't a collection of text, it's recorded know-how. Every proven prompt has baked into it how your company writes meeting notes, what a proposal has to contain, what tone you use with clients, and what never goes out without a check. That knowledge lives in your head today, and it disappears with you when you go on vacation. Written down in a library, it can be handed off and improved.

This guide walks from a blank page to a working library that grows on its own: choosing where to store it, structuring an entry, versioning, sharing across a team, and ten prompts worth having first. You don't need to read it all at once — phases 1 and 2 take one evening, and you can add the rest as you go.

A typical scenario

Klára, a marketer, reinvents her prompt for summarizing social media analytics every single week. Phrased slightly differently each time, with slightly different results, and she never remembers what worked best last time. Before she gets back to the same quality as last week, she spends fifteen minutes tuning the request — and sometimes she still doesn't quite hit it. The same cycle repeats for five other tasks: a monthly client report, product descriptions, a brief for a designer, a reply to a negative review, a newsletter draft. Altogether, roughly two hours a week spent reinventing something she already knew how to do.

Three months into using a library, her week looks different. The analytics prompt is saved as an entry with a sample output and a note: “for month-over-month comparisons you have to supply both numbers, otherwise the model gets the percentages wrong.” She drops in the numbers, gets an output that goes into the report almost unchanged. Her six most-used prompts live in text snippets. She handed the library to a new colleague on day one, and that colleague turned in a usable report in her second week, not her second month.

The change isn't that Klára writes better prompts than before. The change is that the good ones stopped disappearing.

Phase 1: what belongs in the library and what doesn't

The most common reason prompt libraries die isn't laziness, it's clutter. If you save everything, six months in you have a hundred and fifty entries and it's faster to just write the prompt again. A library only has value when it holds few things, and all of them work.

The rule of three uses

Save a prompt only once you've used it for the third time. The first use is an experiment, the second is a coincidence, the third is a pattern. Until then, let it sit in your conversation history.

In practice this means: don't start a library by sitting down and inventing thirty prompts in advance — invented prompts never get used, because they didn't come from a real need. Start with an empty file and, for a week, save into it only what you actually did that day. After a month you'll have ten to fifteen entries, and that's a library, not a wish list.

What belongs in

A candidate for saving meets three conditions. First, it recurs — you do it once a week, once a month, or every time a new client comes on board. Second, it has a stable structure: the input changes, not the request. Third, you care about output quality enough that you won't settle for the first attempt.

Typical candidates: preparing recurring documents (notes, reports, proposals, briefs), communication in sensitive situations (complaints, rejections, follow-ups), review passes (what's missing from a text, what could go wrong, what the other side might object to), and format conversions (notes into an email, a transcript into tasks).

What doesn't belong in

One-off requests. A prompt for one specific presentation you'll never do again is waste. Leave it in your history.

Sensitive data. Never put client names, contract numbers, amounts, or employee personal data into a library. A prompt is a template — where a client's name would go, there should be a placeholder in square brackets instead. That's what makes a library shareable, and what keeps it usable when the client changes. And the general rule applies: sensitive data belongs only on a paid account with contractual data protection, and even there, only in anonymized form.

Standing preferences. Sentences like “answer in English” or “be concise, no opening fluff” don't belong in every prompt — they belong in custom instructions, which apply automatically to every conversation. The custom instructions tip covers the difference.

Long context that doesn't change. Your company's tone of voice, a product description, a list of internal abbreviations — that belongs in a Project (persistent context attached to a whole set of conversations), not in the body of a prompt. Details in the projects and persistent context tip.

Turning an ad-hoc request into a template

Most prompts start life in a chat as a specific request with specific data. Before you save one, you have to “dry it out” — replace the specifics with placeholders and add whatever you only spelled out in a follow-up message. AI does this faster than you can:

Here's a request I wrote in a chat, and it was a one-off:

[paste the original prompt, including the specific data]

Turn it into a reusable template:
1. Replace everything specific with a placeholder in square brackets
   that has a descriptive name — not [X], but [client name],
   [email text].
2. Add anything that was missing from the request but that the
   output needs to be good (output format, length, tone, who it's
   for, what not to do).
3. Write a list of every placeholder I need to fill in when I use
   this, with one sentence per placeholder on what goes there.
4. Flag which parts of the prompt are actually my standing
   preferences and should live in settings instead of in every
   prompt.

Return the template as one continuous block of text so I can copy
it. Don't explain anything around it.

It returns a template you can drop straight into your library, plus a list of placeholders to fill in. Watch out for step 2 — the model tends to add requirements you don't actually want (typically “add a summary at the end” or “use emoji”). Read the template line by line and delete whatever doesn't belong; otherwise you end up saving someone else's habits.

Phase 2: where to keep the library

There's no single right place. Most people end up using a combination: quick prompts in text snippets, the full library in a database, and the most-used sets as Projects.

Text snippets: for what you use daily

A text snippet is an operating system or keyboard feature that expands a saved block of text after you type a few characters. On a Mac it's Text Replacement in Keyboard settings; Windows and Android have similar keyboard features; on iPhone it's Text Replacement. The text snippets on Mac tip covers it in detail.

For prompts, this is the fastest path: you type ;notes and the whole meeting-notes prompt expands. A proven convention: a prefix like ; or qq (characters you never type in normal text) plus a short word — ;notes, ;email, ;sum.

There are two limitations. Snippets don't handle long text well — above roughly twenty lines, expansion starts to stutter, and in some apps the snippet doesn't fire at all. And they have no history: you can't see what the previous version was or why you changed it. So keep only your ten to fifteen most-used prompts in snippets, in shortened form, and keep the full version elsewhere.

A Notion database: for a library that's meant to grow

Once you have more than twenty prompts, you need filtering and search. A database in Notion (or a similar tool) is built for exactly this: each prompt is a row, attributes are columns, and you set up views according to how you actually use the library.

A minimal set of columns: Name (verb plus object), Category (a fixed select, not free text), When to use (one sentence), Version, Last used, Owner (for a team library), and Status (active / needs review / retired). The prompt text belongs in the page body, not in a cell — cells are hard to read and copy from.

Views worth setting up: “My frequent ones” (filtered by category, sorted by last-used date), “Needs review” (status), and “New this month.” Save the entry structure as a page template in the database, so filling it in is a matter of clicking, not retyping.

A Project in Claude: for prompts that belong together

A Project is a space with persistent context — you upload reference material and write instructions that apply to every conversation inside it. For a prompt library, that's a major shortcut: you don't need to copy the prompt, because most of its substance already lives in the project.

In practice: set up a project called “Client communication,” put your tone of voice and a list of things you never send without approval into the instructions. Upload three sample emails that turned out well into the project's knowledge. After that, you just write “reply to this” and paste the text — the model already knows the rest.

The downside: a project isn't portable to another tool, and it's harder to search than a database. So a combination works best — the canonical version of a prompt lives in the database, a working copy lives in the project.

A plain text file: the minimalist option

Even a single markdown file in the cloud works: it opens everywhere, you can search it, and it never breaks. Above fifty prompts, though, you'll get lost in it. So keep a strict structure — category heading, prompt heading, metadata, text block.

Phase 3: what a good entry looks like

Saving just the prompt text isn't enough. A month from now you won't remember how it differed from the similar one next to it, or why you changed it. An entry that survives has five parts.

Five required parts

Name describes the activity: “Prepare meeting notes with action items,” not “Meeting.” When a name starts with a verb, it's faster to search for and it shows you what you'll get.

When to use is one sentence that distinguishes this prompt from the one next to it: “for an internal meeting mostly about tasks” versus “for a client meeting mostly about decisions.” Without this sentence, a year from now you'll have three nearly identical prompts piled up and no idea which one to open.

Prompt text is the actual request, with placeholders in square brackets. Name them descriptively — if the prompt has [X] five times, you'll mix them up when filling it in.

Sample output is the part almost everyone skips, and it's the most valuable one. Copy the first ten to twenty lines of a good output into the entry. It shows you what to expect from the prompt, lets you notice when a result gets worse after a model update, and helps a newcomer grasp the prompt's purpose faster from the sample than from a description.

Version and change note keeps a history: a version number plus one sentence on what you changed and why. Without it, six months from now you won't know whether the current shape is the result of careful tuning or an accidental shortening.

A copy-paste entry template

This is the structure to save as a template — as a database template in Notion, or as a block you copy in a text file:

NAME: [verb + object, e.g. Prepare meeting notes with action items]
CATEGORY: [emails / reports / review / research / writing]
WHEN TO USE: [one sentence — how it differs from similar prompts]
TOOL: [where it works best and why, if that matters]
VERSION: [1.0] — [date]

PROMPT:
[full prompt text with placeholders in square brackets]

WHAT TO FILL IN: [list of placeholders, one sentence each]

SAMPLE OUTPUT (version 1.0):
[first 10-20 lines of a good output]

WATCH OUT FOR:
- [a typical failure I've seen]
- [what to always check in the output]

HISTORY:
1.0 [date] — first version
1.1 [date] — [what changed and why]

It looks like a lot of writing, but filling it in takes three minutes and you only do it once. If this is too much for your case, drop TOOL and HISTORY; SAMPLE OUTPUT and WATCH OUT FOR are what makes the difference between a library and a pile of text.

Categories: a fixed list, not free tags

Pick your categories up front, make them a fixed select, and don't add more — four to six is enough. A proven set: communication, documents, review, research, writing. If you allow free tags, in three months you'll have twenty categories with three prompts each and be back to searching by eye.

Phase 4: versioning and improving after every use

This is where the difference between a collection and a library shows up. A collection is static — you save a prompt and use it until it stops working. A library learns: every use reveals something the request was missing.

The “thirty seconds after the output” habit

The rule is simple. Whenever you write a follow-up message after an output, that correction belongs in the prompt. If you had to add “but shorter,” “it's missing deadlines,” or “without that intro,” it means the prompt should have included that information from the start. Open the entry, add the line, bump the version. Thirty seconds.

This one habit does more for the quality of your library than everything else in this guide combined. After ten uses, a prompt is tuned enough that it barely needs corrections anymore.

A prompt for improving a prompt after the fact

You don't have to figure this out yourself. The model that generated the output can describe fairly precisely what the request was missing — if you ask it the right way:

Here's the prompt I used:

[paste the prompt]

Here's the output I got:

[paste the output]

And here's what I had to say after the output to make it usable:

[paste your follow-up corrections, or describe what was wrong]

Analyze this and answer in four blocks:
1. What was missing from the original request — specifically, point
   by point. Not a general “it should have been more precise,” but
   which piece of information or rule.
2. Which phrasings in the request were ambiguous and how you
   interpreted them.
3. A rewritten version of the prompt that would have produced,
   right away, the result I only got to through corrections.
4. What's redundant in the prompt — parts that didn't affect the
   output at all and just make it longer.

In point 3, keep my placeholders and don't add any new requirements
I didn't actually state.

Point 4 is why it's worth running this even on prompts that already work: prompts accumulate — you add rules, you never remove any, and six months later you have forty lines, half of which do nothing. Watch out — the model will sometimes flag as unnecessary a rule that's actually there as a safeguard against behavior that only shows up occasionally. Before deleting anything, try to remember why you wrote it.

Testing on edge-case inputs

A prompt that works on a clean input breaks on the messy one: meeting notes where nothing got closed out, a complaint with no clear ask, a monthly report with missing data. Before you call a prompt finished, have it find where it falls apart:

Here's a prompt from my library that I use repeatedly:

[paste the prompt]

A typical input it works on looks like this:

[paste a shortened example input]

Try to break it. List:
1. Five types of input this prompt would fail on or produce
   misleading output for — for each, say exactly what goes wrong.
2. For each case, suggest one sentence to add to the prompt that
   would handle it.
3. Which of those sentences contradict each other or would bloat
   the prompt unnecessarily — what I should instead handle case by
   case at the point of use.
4. One rule the prompt should always include that almost no one
   ever thinks of.

Don't rewrite the whole prompt, just return the sentences to add.

It returns a list of weaknesses, of which usually two or three are worth adding. Point 3 is there as a brake — without it, the model will suggest fifteen rules and double the length of your prompt. The most common useful finding is handling empty inputs: “if the source material is missing a deadline or an owner, write NOT SPECIFIED, don't guess” saves a lot of silent errors.

Quarterly review and retirement

Not every prompt deserves improving. Throw out the one you haven't used in six months, the one with a newer twin, or the one a tool feature replaced — transcribing a recording or reading text out of an image is something tools do natively now. Don't delete a retired prompt right away; move it to “retired” status and delete it for good after a quarter.

Once a quarter, go through the whole library. It takes an hour, and it's the only maintenance it needs:

Here's a list of prompts from my library — for each, its name,
category, date last used, and the first three lines of the request:

[paste the exported list]

Do a review:
1. Which prompts overlap enough that only one should remain — for
   each pair, note what's the same and what differs.
2. Which look like they're no longer needed (unused, or handling
   something tools now do on their own).
3. Which categories are overcrowded and how they could be split.
4. What kinds of tasks are missing from my library, based on what's
   in it — where the gap is, given the shape of my prompts.

For point 1, don't suggest merging where the recipient or the
output's tone differs; those are legitimately two different
prompts.

Point 4 tends to be surprisingly accurate — the shape of a library reveals what's not covered in your work. Treat the findings as suggestions: the model can't see how often you actually use something, so verify “unused” prompts against your own memory.

Phase 5: sharing with a team

A personal library saves you time. A team library changes how fast new people ramp up and how consistent your output is externally. It's also where the most common mistake happens: a shared folder anyone can drop anything into turns into a junk pile within a month.

A structure that survives

Split the library into two layers. The shared layer holds approved prompts the whole team uses — tuned, with a sample output, and with an owner. The personal layer is a sandbox for experiments. A prompt moves from personal to shared only once the author has used it at least three times and someone else has confirmed it works for them too.

Every shared prompt has an owner — a specific person, not “the team.” That person updates it, and that's who gets told when it stops working. Without an owner, nobody fixes anything.

Onboarding: the library on a newcomer's first day

The strongest effect of a team library shows up when someone new joins: instead of “ask if you need something,” they get a set of prompts that record how your team actually does things. But they need a guide to it — not a list, but an order and context:

Here's a list of prompts from our team library — name, category,
and one sentence on what it's for:

[paste the list]

We're onboarding a [role, e.g. junior project manager], who will
be responsible for [main duties]. They've only used AI casually
so far.

Put together a guide to the library for them:
1. Five prompts to learn in the first week, in order — for each,
   note exactly when they'll use it and what to check in the
   output.
2. Five more for the second week.
3. Which prompts they should leave alone for now, because they're
   for situations they don't know yet, and why.
4. Three things they should verify themselves in every output,
   because they're the one responsible for it, not the tool.
5. One page of “how we do things here” that summarizes what our
   standards are, based on what's in the prompts.

Write it practically, as instructions, not as a training course.

Point 5 is worth noting: what's written into the prompts lets you reverse-engineer a company standard nobody ever formally wrote down. Point 4 is a safeguard — a newcomer needs to know from day one that AI proposes, a person approves, and that they're the one responsible for a sent email or a submitted report, not the tool.

Reviewing before you share

Before you open the library to a wider group, go through it for sensitive data. People write specific things into prompts without thinking about it — a client's name in an example, an amount in a sample output, a project's codename:

Go through this prompt library text and find everything that
shouldn't leave our team:

[paste the library content or one category]

List findings in a table: finding | where it is (prompt name) |
type (person's name / client name / amount / internal info /
contact) | what to replace it with.

Look especially in sample outputs — that's where specific data
gets left in most often.

Don't fix anything, just list. If you're not sure whether something
is sensitive, flag it too and say why.

It returns a list you go through manually. Watch out — the model reliably catches names and numbers, but it's worse at recognizing internal context that's only sensitive to your organization — an unreleased product's name, a project codename you're not publicizing yet.

Run the same pass on anything you send outside the company. A prompt about note structure is harmless; a prompt for a price proposal that reveals your margin logic doesn't belong outside.

Phase 6: ten prompts everyone should have

A starter set. Not because it's universally the best one, but because it covers activities almost everyone at a computer does. Treat it as a rough draft — after five uses, these won't be the same prompts anymore, they'll be yours.

1. Meeting notes with action items — turns notes into a write-up with decisions and tasks with deadlines kept separate.
2. First draft of an email reply — turns an incoming message and your note on intent into a draft you'll still edit.
3. Summary of a long document with risks — pulls the substance and, above all, the potential problems out of a contract or a proposal.
4. Reviewing a message before you send it — flags what's ambiguous, what's missing, and what could be misread.
5. Meeting prep — turns source material into a meeting structure, questions, and the other side's anticipated objections.
6. Breaking a big task into steps — turns a vague ask into a list of concrete steps and tells you what's first.
7. Turning notes into a document — turns a pile of bullet points into text with headings and a logical flow.
8. Explaining something you don't understand — a technical text or a legal paragraph, at your level.
9. Playing devil's advocate on your own idea — finds the weaknesses in what you want to propose before someone else does.
10. A weekly recap — turns your calendar and notes into an overview of what got done and what's still hanging.

Three of them are worth writing out in full, because for these the request makes the biggest difference to the output.

Meeting notes with action items

Here are my meeting notes (raw, in the order they came up):

[paste notes or a transcript]

Context: [type of meeting, how many people, how often it happens].

Turn this into notes in three parts:
1. DECISIONS — what got closed out. For each: what was decided,
   who decided it, and one sentence on why (if the notes say).
2. ACTION ITEMS — a table: task | owner | due date | depends on.
3. OPEN ITEMS — what was discussed but not closed out, including
   who needs to bring a decision next time.

Rules:
- Where the notes are missing an owner or a deadline, write
  NOT SPECIFIED. Don't guess and don't assign tasks based on
  context.
- Don't add anything that isn't in the notes, including general
  conclusions.
- Phrase tasks starting with a verb in the infinitive.
- No intro and no summary at the end, just the three parts.

It returns notes you can send out almost unchanged. The NOT SPECIFIED rule is the key part — without it, the model fills in deadlines like “by end of week” and assigns owners based on who's mentioned most often in the notes; it looks plausible and it's made up. Always read the notes before sending them out — they're a commitment. The meeting notes tip has a longer version.

Summarizing a document with its risks

I'm attaching a document: [type — contract / proposal / report /
terms]. I'm reading it as [role, e.g. the party ordering a
service]. What I care about most: [what to focus on, e.g.
obligations and notice periods].

Process it like this:
1. What the document is about — five sentences, no jargon.
2. Key points that affect me — each with a reference to the
   section or page it's on.
3. What's risky or unfavorable for me — for each point, say
   specifically why, not just that it's a risk.
4. What's missing from the document that should be there for
   this type of document.
5. Five questions I should ask the other side before I sign this.

Always cite a specific place in the document. Where you're not
sure of the interpretation, say so instead of guessing.
Don't give legal advice, just describe what the text says.

It returns an overview you can work from. But a summary doesn't replace reading a document you're about to sign, and the last line of the prompt is there on purpose — the model tends to present interpretation as certainty. Legal review is a lawyer's job; this is prep so you can talk to one from an informed position.

Reviewing a message before you send it

Here's a message I'm about to send:

[paste the text]

Recipient: [who, what's their relationship to the topic, what do
they know about it].
What I want to achieve: [goal — approval, information, a changed
decision].

Don't rewrite it. List findings:
1. Sentences that can be read two ways — for each, give both
   readings.
2. What the recipient is missing to be able to do what I'm asking
   (context, deadline, a specific request, backup material).
3. Places where the tone doesn't match the goal — where I'm too
   soft to push something through, or unnecessarily sharp.
4. What's unnecessary and can be cut without losing anything.
5. One opening sentence that would let the recipient immediately
   grasp what this is about, if I don't already have one.

Rank the findings by how much they threaten my goal.

The ban on rewriting matters: if you let the model fix the text, you get a different text, but not a better skill. The findings from point 1 tend to be surprising — an author almost never sees the ambiguity in their own writing. For short messages, ask only for points 1 through 3.

For the remaining six prompts on the list, the same rules apply as for these three: always specify who the output is for and what you want to achieve with it, say explicitly what should happen when source material is missing, and forbid the model from adding information you didn't provide. The devil's-advocate prompt also has its own dedicated guide in the AI as a devil's advocate tip.

Common mistakes

• Saving everything. A library with a hundred prompts is worse than no library — you can't find anything in it and you stop opening it. Save after the third use, and clear it out once a quarter.
• Saving a prompt without a sample output. Two months later you won't know what to expect from it, or notice that the result got worse. Ten lines of a good output is the cheapest investment a library can make.
• Leaving specific data in prompts. Client names and amounts in a template mean you can't share the library, and the prompt ages out along with the client. Placeholders in square brackets, always.
• Improving a prompt only in your head. If you write a correction after an output and don't save it, you'll write it again tomorrow. The “thirty seconds after the output” habit is the whole trick.
• Copying someone else's prompts unchanged. A prompt from the internet is a rough draft, written for someone else's context and often a different language. Use it, adapt it to your own case, and only then save it.
• Mixing up a prompt, instructions, and context. Standing preferences belong in custom instructions, unchanging reference material belongs in a Project; a prompt should keep only what changes from case to case.

The best tools

• The system's text snippets (Text Replacement on Mac and iPhone, text replacement in Windows and Android keyboards) — for your ten to fifteen most-used prompts: a few characters expand the whole request, without switching windows.
• Notion or a similar database — for the full library: filters by category, a “needs review” view, change history, and a place for sample outputs.
• Projects in Claude — for sets of prompts that share context: instructions and reference material live in the project, so the request shrinks to one sentence.
• A shared document or database for the team — for the approved layer of the library, with an owner per prompt; everyone keeps their own personal sandbox separately.
• A plain markdown file in the cloud — the minimalist option, opens everywhere; works up to around fifty prompts.

What you get out of it

• Time: for someone who uses AI daily, you can expect an hour or two a week saved on reinventing requests — for recurring tasks, the path to a usable output shrinks from ten minutes to one.
• Money: the main savings for a team isn't faster writing, it's that a newcomer turns in usable work weeks earlier.
• Peace of mind: you don't have to remember the phrasing that worked back then — or worry that one person's vacation takes the way you write reports with them.
• Quality: the same prompt gives the same good output every time, so tone and structure stay consistent across months and across people.

Pro tip

An advanced trick: add one sentence to every prompt explaining why it's written the way it is. Not what it does, but why that one odd rule is there — “NOT SPECIFIED has to be there, otherwise the model makes up deadlines.” A year from now, when you're editing the prompt, that sentence stops you from deleting a safeguard you put there for a good reason and have since forgotten. It's the same principle as a comment in code: it records the reason, not the procedure.

And one closing rule over the whole library: a prompt is a tool for drafting, not for deciding. No matter how well-tuned the request, sending the email, approving the proposal, confirming the payment, and deleting anything remains a person's job. The library speeds up the path to a draft — the last click is still yours.