Building a reusable personal prompt library

The concept

The compounding return on everything in this course comes from not writing the same prompt twice. A prompt that took you fifteen minutes to get right and produced an excellent result is a business asset — it encodes your judgement about how a job should be done. Thrown away, it's fifteen minutes. Saved, named, and reused, it's a permanent capability increase for you and for anyone you hand it to. The agencies getting real leverage from AI aren't the ones with better models; they're the ones with a library.

The other reason to build one: a library is delegable. A junior with your prompt library produces work at a level they couldn't reach alone, and the library trains them in your standards while they use it. It's your house style made executable.

The structure

Keep it stupidly simple. A folder of markdown files. Not a database, not an app, not Notion with seven properties — you'll stop maintaining it.

prompts/
  README.md               ← index: one line per prompt, what it's for
  _template.md            ← the Module 2 skeleton
  _voice/
    voice-rawasi.md
    voice-strike-media.md
    voice-mfz-linkedin.md
  copy/
    social-captions-ar.md
    ad-headlines-en.md
    script-30sec-tvc.md
  business/
    proposal-outline.md
    contract-review.md
    client-email-delay-ar.md
    meeting-summary.md
  creative/
    image-product-hero.md
    image-lifestyle-editorial.md
    video-8sec-tracking.md
  agents/
    system-content-agent.md

The naming rule

<what it makes>-<variant>-<language>.md. Name by output, not by topic — you search for what you need to produce, not for what it's about. client-email-delay-ar.md is findable at 11pm. email-stuff.md is not.

What goes inside each file

Five things, in this order:

# Client email — production delay (Arabic)

**Use when:** telling a client a shoot or delivery date has moved.
**Last worked well:** 2026-07-14, pharma client, zero pushback.

## Fill in first
- [ ] the real dates, old and new
- [ ] whose fault it was
- [ ] whether a concession is authorised (default: NO)

## The prompt
[the full prompt, with [BRACKETS] where you substitute]

## Notes
- Two versions (warm/clinical) is right — the warm one wins ~70%.
- Do NOT let it lead with the apology. It always tries.

That "Notes" section is what turns a prompt into knowledge. It's where your hard-won corrections live.

How to build it without a project

Don't set aside a day to write your library — you won't. Instead adopt one habit: whenever a prompt produces something you'd happily send to a client, stop and save it. Sixty seconds. Paste it in a file, name it, add one line about why it worked. Do that for a month and you'll have twenty prompts covering most of your recurring work, all of them battle-tested rather than theoretical.

Then two maintenance rules:

• Prune quarterly. Delete anything you haven't used. A library of 25 live prompts beats one of 200 dead ones.
• Update on failure, not just on success. When a saved prompt disappoints, fix the file — don't fix it in the chat and lose the improvement.

Before → After