Build Your Personal Prompt Library

Tier: Foundation · Hands-on time: ~40 minutes

This playbook sets up a lightweight prompt library — plain Markdown files in a git repo — that you will still be using in two years.

When to use

• •
  You have caught yourself rewriting the same prompt for the third time.
• •
  A prompt finally worked well and you want to keep it working (models and your needs both drift).
• •
  Your team wants to share what works without a heavyweight tool.

Prerequisites

• •
  git installed; a private repo (or just a local one).
• •
  3–5 prompts you already use — this playbook's siblings (pb-01 to pb-04) supply good starters.
• •
  Any text editor.

The workflow

1. 1.

   Create the repo and structure.

   Copy

   mkdir -p ~/prompt-library/{summarize,extract,write,review,research}
   cd ~/prompt-library && git init
   printf "# Prompt Library\nOne prompt per file. See TEMPLATE.md.\n" > README.md
   

   Folders are workflow areas, not tools — prompts outlive tools.

2. 2.

   Define the one-page template. Save as TEMPLATE.md:

   Copy

   # <verb-first name, e.g. "Extract action items from transcript">
   
   - **Version:** 1.0 (YYYY-MM-DD)
   - **Use when:** <one line>
   - **Model tier:** <small / mid / frontier — see pb-10>
   - **Inputs to fill:** <the {{PLACEHOLDERS}} the user must replace>
   - **Known failure modes:** <what to watch for>
   
   ## Prompt
   
   <the full prompt text, with {{PLACEHOLDERS}} for variable parts>
   
   ## Example output (abridged)
   
   <a few lines of known-good output, so future-you recognizes drift>
   

3. 3.

   Migrate your first five prompts. Copy each working prompt into a file, replace the variable parts with {{PLACEHOLDERS}}, fill the metadata honestly — especially "Known failure modes," which is the field that saves future-you. Commit:

   Copy

   git add -A && git commit -m "Seed library: summarize, extract, minutes, voice-draft, review"
   

4. 4.

   Adopt the update discipline. When a prompt misbehaves, fix the prompt file (not just the chat), bump the version, and record why in the commit message:

   Copy

   git commit -am "extract/tickets v1.1: forbid phone numbers as ticket_ids"
   

   The git log becomes your changelog — git log --oneline extract/ shows the prompt's whole history.

5. 5.

   Wire prompts into your tools. Paste library prompts into whatever persistent-instruction slot your tools offer (custom instructions, projects, system prompt boxes, editor rules files). The repo stays the source of truth; tools hold copies.

6. 6.

   Monthly 10-minute prune. Delete prompts unused for 60+ days, promote chat-history gems into files, and re-test your top three against the current model version — model updates silently change behavior.

Tool variants

• Git repo of Markdown (recommended baseline): free, portable, diffable, survives every tool change; team-shareable by making the repo shared.
• Notes app with folders/tags: lower friction, fine solo; you lose diffs and history, so paste the version line manually and never edit without bumping it.
• Built-in prompt/snippet features of your AI tool: best ergonomics inside that tool, but vendor-locked — keep the repo as master and treat tool storage as a deploy target, not the source.

Verification

• •
  git log shows at least one meaningful version bump with a reason within your first two weeks — if every prompt is stuck at v1.0, you're collecting, not maintaining.
• •
  Pick a random library prompt and hand it to a colleague: they can run it successfully using only the file (metadata sufficient, placeholders obvious).
• •
  Each file's example output still matches what the current model produces — re-test top prompts monthly.
• •
  Time check: reusing a library prompt takes under 60 seconds from need to pasted-and-filled.

Pitfalls

• Hoarding. Fifty half-tested prompts are worse than eight maintained ones. The prune step is load-bearing.
• Missing placeholders. A prompt with last month's project baked in will get pasted with last month's project still in it. Aggressively {{PLACEHOLDER}} anything variable.
• No failure-mode notes. "Works great" ages badly; "drops items on batches over 20" keeps working forever.
• Tool-first storage. Storing prompts only inside one vendor's app means losing your library the day you switch tools or the feature is redesigned.
• Secrets in prompts. Example inputs pasted into prompt files often contain real client data — sanitize before committing; a git repo remembers forever.

Restricted-environment variant

• •
  Keep the library in a private repo on your organization's git host, never a personal public GitHub — prompt files leak project context (codenames, architecture, client hints).
• •
  Sanitize example outputs: replace real names/systems with placeholders before committing; run a quick git grep for client names before any push.
• •
  If policy forbids external hosting entirely, a local bare repo (git init --bare on a shared internal drive) gives the team sharing plus history with zero cloud exposure.

Success criteria

• •
  Library exists in git with ≥5 prompts in the template format, each with version, failure modes, and example output.
• •
  At least one prompt has a v1.1 with a documented reason.
• •
  You reach for the library before writing a prompt from scratch — observed at least 3× in one week.
• •
  A teammate has successfully used one of your prompts without asking you anything.