Prompts spread through an organization the way spreadsheets do: someone writes a good one, a colleague copies it, edits it slightly, and six months later the company runs on a folklore of pasted text with no owner, no test evidence, and no way to retire the bad variants. A prompt library is the antidote — a single, versioned, searchable home for the prompts your organization actually relies on — and a governance process is what keeps the library trustworthy instead of becoming one more place where stale prompts accumulate.
What goes in the library
Not every prompt. Exploratory one-offs and personal drafts don't belong; a library earns trust by curating. The entry bar: any prompt embedded in a production system, any prompt a team repeatedly reuses for business output, and any prompt in a regulated or customer-facing workflow. Each entry is more than text — a useful record carries:
| Field | Why it matters |
|---|---|
| Prompt text + variables | The artifact itself, with placeholders documented |
| Owner | Someone accountable for maintenance and questions |
| Intended task and scope | Prevents "it worked for summaries, so we used it for contracts" |
| Model ID(s) validated against | Prompts are tuned per model; an untested pairing is a guess |
| Eval results + test set link | The evidence that it works — and the means to re-verify |
| Version + change log | See prompt versioning; the library is where versions live |
| Status: draft / approved / deprecated | The lifecycle flag that lets bad prompts actually retire |
Where should it live? For engineering-owned prompts, a git repository is the natural home — review, history, and deployment integration come free. For mixed technical/non-technical organizations, a git-backed catalog with a friendlier front end (even a generated internal page) serves both audiences. Resist a tool that separates the library from version control; the library must be the source production reads from, not a wiki that drifts away from reality. Teams on AWS often deploy approved prompts to S3 or Parameter Store keyed by library version — the pattern in system prompt management across workspaces — and the equivalent works on any cloud.
Governance: lightweight, but real
Governance means three gates, each proportionate to risk. Entry review: before a prompt gets "approved" status, a second person reviews it against a short checklist — clear and direct instructions, structure per Anthropic's documented best practices (roles, XML-tagged sections, 3–5 diverse examples where examples help), boundaries with reasons and exits, and evaluation evidence attached. Anthropic's guidance that prompt engineering starts with success criteria and empirical tests is effectively your review standard: no evals, no approval. Change review: edits to approved prompts follow the same pull-request discipline as code, with eval results in the description. High-risk prompts (customer-facing, regulated domains) can require a domain reviewer in addition to a prompt-literate one. Periodic re-validation: prompts rot when models upgrade — so every entry gets re-run against its eval set on each model migration (see regression testing), and entries whose owners have left or whose eval sets have gone stale get flagged, not silently trusted.
Making good prompts spread
Governance controls quality; adoption is what pays for it. Three habits help. Make the library the easiest path: if importing an approved prompt takes one function call and writing your own takes an afternoon, engineers choose the library. Build shared components, not just whole prompts — a common boundary section, a standard citation instruction, a house-style tone block — so teams compose from reviewed parts. And harvest from the field: when a team's local variant outperforms the library version in evals, the process should pull that improvement upstream rather than letting the fork live forever. Anthropic's Console tooling (prompt generator, templates and variables, prompt improver) is useful at the drafting stage of this loop; the library is where drafts graduate after review.
There's a cost bonus to convergence, too: shared prompts mean shared prefixes, and Claude's prompt caching bills cache reads at a tenth of base input price — an organization standardizing on one reviewed system prompt per workload caches better than one running forty near-duplicates.
Where to go next
The library presumes two practices covered elsewhere: treating prompts like code and a prompt evaluation framework to generate the evidence reviews rely on. For the compliance-side view, see system prompt version control, and for parameterizing library entries, reusable prompt templates.