A prompt library: don't rewrite what already works

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.

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]

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.

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.

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.

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.

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.

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.

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.

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.