Five Prompt-Library Habits That Keep Templates From Rotting

A prompt library rots quietly. Nothing breaks on the day it starts — a model gets a new version, someone edits a template in place to fix one bad output, and a few weeks later you cannot tell which file was ever good. Every habit below costs almost nothing per prompt; the expense is entirely in the skipping.

Date-stamp what a prompt was tested on

“Last edited” is not the same as “last verified”. Editors touch files for typos, renames and formatting. What you want is the date a human read the output and said “yes, that is what I wanted”.

Put it in a header block inside the file, not in a spreadsheet you will forget to open.

---
# prompts/support/summarise-ticket.md
tested_on: 2025-08-19      # last date a human read a real output
model: claude-3-5-sonnet  # the model that produced that output
runner: api                # api | chat-ui | agent-loop
temperature: 0.2
owner: me
status: good               # good | needs-review | draft
---

Two fields carry most of the value. tested_on lets you sort the library by neglect: anything older than a model release is a candidate for review, not a proven asset. runner matters more than people expect, because the same prompt behaves differently through a chat UI with a default system prompt than through a bare API call, and you will not remember which one you used.

The field costs a few seconds to fill in. Skipping it costs an afternoon of re-testing, because you cannot tell whether a prompt was ever checked or was copied from a blog post and never run.

Keep a last known good copy

The most destructive habit in prompt work is editing the canonical file in place when one output comes back wrong. You fix today’s case, lose yesterday’s working version, and have no idea whether the change helped.

Snapshot before you edit, and only after you have confirmed the output is acceptable.

#!/usr/bin/env bash
# scripts/snapshot.sh — save the current file as the known-good version
set -euo pipefail
prompt="${1:?usage: snapshot.sh prompts/support/summarise-ticket.md}"
stamp="$(date -u +%Y-%m-%d)"
mkdir -p good
dest="good/$(basename "$prompt" .md).${stamp}.md"
cp "$prompt" "$dest"
printf 'saved %s\n' "$dest"

Then commit it with a message that names the model, for example good: summarise-ticket @ claude-3-5-sonnet. When a prompt starts behaving badly, you have a real answer to “when did this last work” and a file to diff against.

Where the good copy lives matters less than having one. The tradeoffs are mostly about how fast you can get back:

Git is the better tool when the library is large or shared; dated copies are fine when you are the only editor. The failure mode is the same either way: editing the live file first and treating the backup as an afterthought. It is the same discipline that stops buyer customisations from being lost when a template changes, as described in versioning a template.

Note the model it was tuned for

A prompt is not model-neutral. Instruction-following strictness, tolerance for long context, how the model handles a requested JSON shape, and whether it needs explicit reasoning steps all differ between families and between versions of the same family.

Record the model, and record what you know about portability honestly. If you have not tried the prompt on a smaller or cheaper model, leave that field empty rather than guessing. An empty field means “unknown”, which is useful information. A wrong field means you will trust a prompt on a model it was never run against.

Two header fields cover this: model, and optionally model_notes for the one thing that keeps biting you, such as “needs a system prompt that forbids preamble” or “wraps JSON in markdown fences”.

Where a prompt depends on a lot of pasted material, how you pack that material matters as much as the instruction itself. That is the territory of context engineering, and it is worth keeping in mind while you write the header. Model choice and context packing are the two variables most likely to invalidate a prompt that used to work.

Leave exactly one field for the user’s context

Templates fail when they try to be flexible everywhere. Ten optional variables look thorough and get ignored: people fill in two, skip eight, and the output is written for a generic company that does not exist.

Leave one marked field for the context that actually changes the answer.

## Context (fill in before running)
- Audience: who will read this
- Constraint: the one thing that must be true about the output
  (length, jargon level, or required format)

## Task
Using only the context above, rewrite the notes below...

One field forces a decision about what genuinely varies between runs. If you want a second field, that is usually a sign you have two prompts, not one prompt with two knobs. Two files are easier to test, easier to date-stamp, and easier to hand to someone else.

Review the library when the model updates

Calendar-based review schedules fail because nothing forces them. Model updates do force the issue: when the alias you call in production starts pointing at a new version, every prompt in the library has an unknown status until you check it.

Make the review mechanical. List the library by tested_on and see what falls off the back.

for f in $(find prompts -name '*.md' | sort); do
  d=$(awk '/^tested_on:/ {print $2; exit}' "$f")
  m=$(awk '/^model:/ {print $2; exit}' "$f")
  printf '%s\t%s\t%s\n' "${d:-0000-00-00}" "${m:-unknown}" "$f"
done | sort

What to do with the list, in order:

• Prompts whose model no longer matches anything you run: set status: needs-review and stop using them in anything automated until you have re-run them once. The same logic applies to any pipeline you depend on — see the overview of AI automation.
• Prompts whose tested_on predates the model change: run one or two real inputs through them, then either update the date or retire the working copy.
• Prompts that still work: update tested_on and model. That is the whole job.

The review is not a rewrite session. Its purpose is to keep the header honest, so the library tells you what is proven and what is merely present.

What to do next

• Add a header block to your five most-used prompts today. tested_on, model, runner and status are enough to start.
• Create a good/ directory and snapshot one prompt before you next edit it. The snapshot.sh script above is the whole tool.
• Run the review listing once and mark anything stale as needs-review instead of leaving its status ambiguous.
• Give each template exactly one context field. If you want a second, split the prompt into two files instead.
• If you would rather start from working templates than build the discipline from scratch, the AI Prompt Library is a one-time $39 download of copy-paste prompts organised by job — writing, coding, research, ops — available at https://slashmaster6.gumroad.com/l/diwoc. It is a starting point; the habits above are what keep it useful.

Get AI Prompt Library

AI Prompt Library — $39, one-time payment, instant download. See the full breakdown on the review page.

Related reading

• The Ultimate Guide to AI Automation 2026
• How I Built a 10-Product Digital Business
• Building an AI Content Factory