Capstone: your professional prompt library

Time for the great assembly

Nine chapters have filled Sofia's pockets: templates (chapter 5), a Plume assistant (chapter 6), a newsletter chain (chapter 7), an extraction pipeline (chapter 8), test sets and a version log (chapter 9). The problem has changed in nature: it's no longer "how to write a good prompt", it's "how to find, maintain and share forty good prompts". Her "prompts that work" note from chapter 5 is bursting at the seams: duplicates, stale versions, and the intern asking three times a day "which one is the right prompt for reviews?".

This capstone chapter builds the answer: a professional prompt library — organized, versioned, governed. The word may sound pompous for a collection of texts; it isn't. Your prompts now encode weeks of measured iterations: they're a company asset, just like a knowledge base or source code. And an asset without organization depreciates — that's even its natural slope.

The prompt card: the basic unit

A library isn't a pile of prompts: it's a set of cards. The card wraps the prompt with everything needed to use it, judge it and evolve it without its author. Its content brings together the whole course: the template with {{ }} fields (chapter 5), its test cases (chapter 9), its usage context, its owner and its history.

[CARD — negative-review-reply — v4]

What: generates a draft reply to a negative customer review, in the Planiresto tone.
When to use it: any review ≤ 3 stars. NOT for legal threats (→ forward to management).
Owner: Sofia. Last updated: Mar 21.

TEMPLATE:
You are a customer relations officer at Planiresto [...see full prompt...]
Review to handle: {{review}}
Optional context: {{customer history, or "none"}}

VALIDATION: score 80/90 on test set review-tests.md (15 entries). Judge calibrated Mar 13.
EXAMPLE OF A SUCCESSFUL OUTPUT: [paste a representative example]

CHANGELOG:
v4 (Mar 21) — shortened few-shot examples + word-limit reminder. 80/90.
v3 (Mar 18) — REJECTED: length regression.
v2 (Mar 14) — rule "don't dispute the customer's word". 75/90.
v1 (Mar 12) — initial version. 68/90.

Each section answers a question someone will ask one day. "When to use it" prevents out-of-scope uses — the number one cause of "your prompt doesn't work". "Validation" provides the legitimacy: this prompt isn't an opinion, it's 80/90 on a known test set. The changelog tells why v4 is built the way it is — and spares your successor from retesting the rejected v3. A complete card makes the prompt orphan-proof: usable and improvable even if its author leaves tomorrow.

Organizing: by task, not by technique

How do you shelve forty cards? By business task, never by technique. The user searching thinks "I need to reply to a review", not "I need a few-shot with an LLM judge". Sofia's shelves: Social media, Emails & newsletter, Reviews & support, Data & analysis, Internal. Each card carries an action-oriented name ("negative-review-reply", "trade-show-lead-extraction") — the chapter 5 rule, now a team convention.

On the tooling side, the hierarchy of needs is simple. Alone: a folder of well-named notes is enough. As a team: a shared space (Notion, wiki, drive) with the card template as the mandatory model. As a technical team: a Git repository, where every prompt modification goes through review — the prompt/code parallel then becomes literal. Sofia picks the shared space: that's where the team already lives. The best library tool is the one you open without thinking.

The life cycle: from idea to archive

A living library needs explicit states, otherwise yesterday's draft passes itself off as today's reference. Four states are enough: draft (being written, use at your own risk), tested (run on a test set, documented score), published (the reference version, the one the team uses), archived (replaced or obsolete — kept for the record, never deleted: an archived prompt documents a dead end or an era).

flowchart LR
  B["Draft: being written"] --> T["Tested: score on test set"]
  T --> P["Published: reference version"]
  P --> A["Improvement proposed"]
  A -->|"Reruns the test set"| T
  P --> X["Archived: replaced, never deleted"]

The most important arrow in the diagram is the return "improvement proposed → tested": any modification of a published prompt reruns the test set before becoming the new reference. That's the dike against slow degradation — the well-meaning colleague who "improves" a phrasing one Tuesday and silently breaks the trap cases. With the cycle, their improvement is welcome: it will be measured, and adopted if it wins. Chapter 9's evaluation wasn't an exercise: it's the library's immune system.

Governance: light but real

Three roles, no more. The card owner (its creator, by default): they arbitrate modifications to their card and keep the changelog. The librarian — Sofia —: they keep the overall coherence, merge duplicates, keep the card template alive and run the routine. The contributors — everyone: they use, report failures (a comment on the card is enough) and propose improvements. No meetings, no committee: traffic rules, not an administration.

The routine that holds it all together extends the chapter 5 one to the team: fifteen minutes on Friday. Everyone carries over their good prompts of the week as drafts; the librarian reviews the reports; at most one card moves from tested to published. Fifteen minutes — but every Friday. Sofia learned it the hard way: the library nearly died in April, when two skipped Fridays were enough for three prompts to go back to living in private conversations. Governance is first of all a kept appointment.

And when a disagreement arises — two contributors convinced their version of the newsletter prompt is the best — the library already has its courtroom: the test set. No opinion debate in a meeting: each version runs the fifteen entries, the scores decide, the changelog records. It's perhaps the most underrated benefit of chapter 9's evaluation: it doesn't just improve prompts, it pacifies their governance.

Putting the model to work on the library itself

Your library is text; and you now know how to have a model analyze text. An elegant loop: prompts can maintain prompts. Consistency audit, duplicate detection, card-template compliance — all of it can be delegated, under your supervision:

You are the auditor of a company prompt library. Here are our cards between delimiters:
--- CARDS ---
{{content of the cards, or the list name + What + When to use it}}
--- END ---

Analyze and report, in this order:
1. DUPLICATES: cards covering the same task — cite the names and the difference, if any.
2. CONTRADICTIONS: tone or format rules that are incompatible between cards that should be aligned.
3. INCOMPLETE CARDS: sections missing compared to the card template — card name + missing section.
4. BLIND SPOTS: recurring tasks of the communications team with no card, based on what the existing cards suggest.

Format: 4 sections, concise bullets, verifiable observations only — no rewriting recommendations.

Note the last line: the auditor observes, the human decides — the division of roles of the whole course, right down to maintenance. Sofia runs this audit at the end of every month; the first one found two duplicates and a tone contradiction between the newsletter card and the LinkedIn card that no human had noticed.

The virtual librarian: the library that answers

Last brick, and the most satisfying one: turning the library into a conversational partner. Sofia configures a dedicated assistant — same mechanisms as chapter 6: system prompt, knowledge files — whose attached knowledge is the export of the published cards (never the drafts), and whose mission is to direct, not to create:

You are the prompt librarian for the communications team at Planiresto. Your knowledge: the library's published cards, attached as files.

Mission: when someone describes a task to you, you point to THE right card (its name, its "When to use it") and provide its ready-to-fill template, {{ }} fields included.

Rules:
- You only recommend existing published cards. You never invent a prompt.
- If no card covers the task, say so and offer to report the gap to Sofia — it's precious information, not a failure.
- If two cards could fit, ask ONE question to decide instead of choosing at random.
- Always restate the card's exclusion scope if it has one, like legal threats for negative-review-reply.

The intern stopped asking "which one is the right prompt for reviews?": the library started answering by itself. And note the second rule, which elegantly closes the loop of the system: every "no card covers this task" reported by the virtual librarian is a blind spot detected in real conditions — exactly section 4 of the monthly audit, but fed continuously by usage. The library no longer just gets consulted: it signals by itself where it needs to grow.

The final word: ten chapters, one skill

Look at the road traveled since the failed LinkedIn post of chapter 1. Sofia learned to structure a request (context, task, format), to show by example, to demand verifiable reasoning, to frame roles and machine outputs, to capitalize in templates. Then she changed scale: assistants that carry the rules, chains that produce entire deliverables, pipelines that turn text into data, an evaluation that turns opinion into measurement, and a library that turns it all into a team asset.

The progression fits in three words: from prompt to system. A successful prompt is worth once; a template is worth every week; a tested, governed library is worth for a whole team, durably. Models will keep changing — your cards will mention other names, your test sets will give other scores. But the skill you've just built — phrasing precisely, verifying honestly, capitalizing methodically — is exactly the one that will gain value as these tools become more powerful. The library is open. It's your turn to write the next cards.