Templates and Saved-Prompt Hygiene
A folder of good prompts you can't find is worth nothing. A naming convention and a version discipline turn it into a real library.
A prompt you can't find is a prompt you'll rewrite
You've written a genuinely good prompt before -- the phrasing that finally got the tone right, the structure that made an assistant stop missing your one non-negotiable requirement. And then, weeks later, faced with the same task, you didn't reuse it. You rewrote it from scratch, worse, because you couldn't remember exactly where you'd saved it or what you'd called it. That's not a memory problem. It's a naming and organization problem, and it's completely solvable.
This lesson is the notes-layer discipline from lesson 778, applied specifically to the reusable instructions you write for AI tools. The goal isn't a bigger collection of prompts -- it's a library where the best version of any given prompt is findable in seconds, every time you need it.
Three fields, one convention
The structure that makes a prompt library actually searchable is small on purpose: category, name, and version.
Category is the JOB the template does -- email, doc, code-review, research -- not the tool you happen to run it in today, because the tool might change while the job stays the same. Name should be specific enough that you can tell when to use it just from reading the name, not vague enough to need a description underneath it. "Cold-outreach-followup" tells you exactly when to reach for it. "Email template 3" does not. Version tracks meaningful changes -- and the rule for what counts as "meaningful" matters more than it looks: bump the version when an edit changes the OUTPUT, not on every wording tweak. Fixing a typo that doesn't change what the prompt produces isn't a new version. Changing the output format from a paragraph to a bulleted list is.
Put together, a well-formed entry reads like email / cold-outreach-followup / v3 -- and that string alone tells you the job, the specific use case, and that you're looking at the third meaningfully-revised iteration, all without opening the file. The same convention scales cleanly across every category you'll actually accumulate: doc / weekly-status-summary / v2, code-review / pr-description-draft / v1, research / competitor-claim-check / v4. Each entry answers the same three questions -- what job, which specific version of that job, and how many meaningful revisions deep -- regardless of how many templates the library eventually holds.
The full lifecycle: a prompt isn't finished when you save it
Saving a prompt is the middle of its life, not the end. A working library has a real lifecycle, and understanding it is what keeps the library current instead of slowly filling up with stale entries nobody trusts anymore.
Draft is the first working version -- don't over-polish it yet. Test means actually running it on a real task, not a toy example; a prompt that only ever ran once, on a made-up test case, hasn't proven anything. Save puts it into the library under the naming convention. Version fires on any later edit that changes the output. And retire happens when the tool it was written for changes, or the task itself evolves past what the prompt was built for -- and crucially, retirement isn't a dead end. It loops back to a fresh draft, because the underlying job the retired prompt served is usually still real; only the specific template needs to catch up.
Skipping the test step is the most common way a library fills up with prompts that looked right on the first try but never actually got verified against real work. Skipping retirement is how a library fills up with stale entries that quietly stop matching the tool you're using today -- worth pruning during the monthly review in lesson 782, not left to accumulate indefinitely.
Retirement deserves one more word, because it's the stage most libraries skip entirely. A prompt written for one assistant's specific instruction-following style can genuinely stop working as well after you switch primaries per lesson 776's framework -- the words are the same, but the fit is gone. Rather than leaving a quietly-underperforming template in the library where it might get reused on autopilot, retiring it and looping back to draft keeps every entry in the library honest: if it's there, it's still earning its place.
The compounding effect
A prompt library built this way compounds in a way a folder of loose notes never does. Every genuinely good prompt you write becomes reusable instead of a one-off, which means your best work keeps getting better instead of getting rewritten from a slightly worse starting point every time. Combined with the notes layer from lesson 778, this is the infrastructure that makes lesson 781's privacy discipline and lesson 782's monthly review actually fast to run -- you're reviewing a small, well-organized library, not hunting through a year of scattered chat history.