On a Tuesday in March, a process consultant named Dana wrote the best prompt of her career. It took eleven stakeholder interview transcripts from a warehouse client, pulled out the recurring pain themes, tagged each theme with who raised it and how often, and flagged every claim that needed verification before it went anywhere near a slide. The output was so clean her project lead asked what tool she was using. Six weeks later, on a nearly identical engagement, Dana sat in front of a blank chat window trying to reconstruct that prompt from memory. She got about seventy percent of it. The output was about seventy percent as good, and she spent forty extra minutes patching the gap. The prompt that worked was gone, because she had treated it the way most people treat prompts: as a conversation, not an asset. This lesson closes the chapter by fixing that, permanently, with the one artifact that makes everything else in this chapter compound.

A Prompt That Worked Is a Process Asset

You already know what to do with a process asset, because handling process assets is your profession. When a team discovers a better way to run a procedure, you do not let the discovery evaporate at the end of the shift. You write it down as a standard operating procedure (SOP), an instruction set precise enough that a competent person who was not in the room can execute it. You give it a version number. You test it. You review it on a schedule. You retire it when it stops matching reality. That discipline is the entire difference between an organization that learns and an organization where the same lessons are purchased over and over at full price.

Now hold that discipline up against how most people treat prompts, and notice the absurdity. A prompt that produced excellent output on real work is a discovered better way of running a procedure. It encodes hard-won knowledge: the role framing that made the model behave, the exact task boundaries, the output format your downstream deliverable needs, the constraints that suppressed the failure modes you caught with the Output Skeptic's Checklist. And then, in most organizations, that asset is abandoned in a scrolling chat history, improvised again from memory next week, slightly differently, with slightly different results, forever.

This is not a small leak. MIT's autopsy of the 95 percent of enterprise GenAI pilots that produced no measurable return named the missing learning loop as one of the three core causes: tools and workflows that never retained what was learned, so every use started from zero. Most individual AI users have exactly the same defect at personal scale. They get better output on Tuesday, learn nothing structural from it, and start from zero on Thursday. A prompt library is the learning loop made physical. It is the place where a good Tuesday becomes a permanent capability instead of a pleasant memory.

There is also a career framing here worth saying plainly. "I am good with AI" is a compliment about you, and it walks out the door when you do. "My team is good with AI" is a statement about the organization, and it survives your vacation, your promotion, and your successor. The bridge between the first sentence and the second is not talent. It is documentation. The person who turns their private prompting craft into a tested, shareable library is doing for AI-assisted work exactly what the first person who wrote down the tribal knowledge of a production line did for manufacturing: converting individual skill into organizational property. That conversion is, historically, what process professionals get promoted for.

A prompt that worked once is luck. A prompt that is named, versioned, tested, and runnable by someone else is a capability.

Why Prompts Decay, and Why the Library Needs Dates

Before building the library, you need to respect the one way a prompt library goes bad: silently. A prompt is not a poem; it does not stay true forever. It is more like a calibration setting on a machine, correct for a specific machine in a specific condition, and three things about that condition keep moving.

First, the models change. The AI tool you use this quarter is not the tool you will use in four quarters, even if the logo on it never changes. Providers update models continuously, and an instruction that was load-bearing for one version can become unnecessary, or occasionally counterproductive, for the next. A prompt tuned in January is an untested prompt by June. Nothing announces this. The output just drifts.

Second, your organization changes. The prompt that extracted themes from interviews at your logistics client assumed interviews structured around a particular question guide. When the question guide changes, the prompt's assumptions quietly stop matching its inputs. Your scorecard prompt assumed five readiness dimensions; the steering committee just added a sixth. The prompt still runs. It just answers last quarter's question.

Third, your document formats change. You spent Chapter 1 learning that clean inputs are half the battle: the Source Pack you assemble before an AI conversation determines what the conversation can achieve. But Source Packs are built from your organization's SOPs, templates, and exports, and those formats get revised. A prompt that says "extract the exception steps from section 4" breaks the day the SOP template moves exceptions to an appendix. The prompt did not get worse. The world moved.

This is why every entry in your library carries a last-tested date, and why the library has a re-test ritual rather than a warranty. Process professionals will recognize the pattern instantly, because it is the same reason SOPs carry review dates and quality systems mandate periodic revalidation. You do not trust a fire extinguisher because it worked at installation; you trust it because someone checked the gauge recently. The rule for the library is the same: a card whose last-tested date is more than a quarter old is not a trusted asset, it is a candidate for re-testing. The re-test takes minutes, because each card carries its own small test case, which we will get to. The point for now is philosophical and important: the library is not a museum of prompts that once worked. It is a maintained set of instruments with current calibration stickers.

The Artifact: Your Assessment Prompt Library

Here is the chapter's closing artifact, the one that gathers everything the previous four lessons built. The Assessment Prompt Library is a single living document (a shared doc, a wiki page, a folder of files; the container does not matter, the structure does) organized around the four jobs an AI-assisted readiness assessor actually does, which happen to be the four jobs the rest of Level 2 will drill one by one:

• Discovery. Prompts that help you inventory processes, mine tribal knowledge, prepare interview guides, and map what the organization actually does. Chapter 2.2 lives here.
• Data audit. Prompts that interrogate data readiness: what data a process produces, where it lives, what shape it is in, what the gaps mean for any AI use case built on top of it.
• People synthesis. Prompts that digest interviews, surveys, and workshop notes into themes, sentiment, resistance signals, and capability gaps, with sources attached.
• Scorecard and reporting. Prompts that apply fixed rubrics, draft findings sections, and convert evidence into the standard outputs a readiness engagement must produce.

Four folders. Not forty. The taxonomy matters because a library nobody can navigate is a library nobody uses, and because filing a prompt forces you to answer the most clarifying question in prompt design: what job is this actually for?

Inside each folder, every entry is stored in a fixed format called a Prompt Card. A Prompt Card is, quite literally, a micro-SOP for a conversation, and it has the same anatomy every time:

• Name and version. A functional name (what it does, not a joke) plus a version number that increments when the prompt text changes. "Interview Theme Extractor v1.3" tells you there were a v1.1 and v1.2, and that somebody learned something between them.
• Job-to-be-done. One sentence: the situation this card is for and the output it produces. This is the line a colleague reads to decide whether this is the right card.
• The prompt text. The full four-part prompt (role, task, context, format) with {placeholders} in curly braces for everything that changes per use: {client_name}, {number_of_transcripts}, {rubric_version}. Placeholders are what turn a one-off prompt into a template.
• Required inputs. Which Source Pack this card expects, stated concretely: "the interview Source Pack: cleaned transcripts with speaker roles tagged, plus the question guide." A card without stated inputs is an invitation to feed it garbage.
• Known failure modes. What this specific prompt gets wrong, learned from your Output Skeptic's Checklist runs. Every prompt has an error profile; a mature card states it so the verifier knows where to aim.
• Verification tier. The level of checking this output requires before use, pulled straight from your Verification Log practice in the previous lesson. The card tells its user how much to trust it, in advance.
• Last-tested date. The calibration sticker.
• Test case. A small, safe input (a short sanitized transcript, a two-row sample table) plus a one-line description of what good output looks like. Re-testing a card means running its test case and checking the output still matches. Five minutes, quarterly, per card.

Here is one complete card, in full, so you can copy the skeleton on Monday. This is a people-synthesis card; imagine it sitting in that folder between a survey summarizer and a resistance-signal scanner.

CARD: Interview Theme Extractor
VERSION: 1.3 (v1.2 added the verification flags; v1.3 fixed
  the over-merging failure mode below)
FOLDER: People synthesis
JOB-TO-BE-DONE: Turns a batch of stakeholder interview
  transcripts into a sourced theme table for the findings
  workshop. Not for surveys (use Survey Synthesizer v1.1).

PROMPT:
You are an operations analyst supporting an AI readiness
assessment at {client_name}. You are rigorous about sourcing
and you never present an inference as a quote.

Task: Analyze the {number_of_transcripts} interview
transcripts below. Identify the recurring themes about how
work actually gets done, where processes break down, and how
people currently use or avoid AI tools.

Context: These are {interview_length}-minute interviews with
{role_mix}. Interviews followed the attached question guide.
Treat every factual claim (volumes, times, system names) as
unverified until checked against records.

Format: Produce a table with columns: Theme | Who raised it
(role, interview #) | Frequency (n of {number_of_transcripts})
| Representative quote (verbatim only) | Verify-before-use
flag (YES if the theme rests on a factual claim we have not
checked). Maximum 12 themes. After the table, list anything
important said by only one person under "Single-source
signals". Do not merge distinct complaints into one theme.

REQUIRED INPUTS: Interview Source Pack: cleaned transcripts,
  speaker roles tagged, names removed per the anonymization
  step; plus the question guide used.
KNOWN FAILURE MODES: (1) Merges "no process documentation"
  and "documentation is outdated" into one theme unless told
  not to; (2) occasionally paraphrases inside the quote
  column, so spot-check 3 quotes against transcripts every
  run; (3) undercounts frequency when a speaker raises a
  theme twice in one interview.
VERIFICATION TIER: Tier 2 (spot-check quotes and counts)
  before internal use; Tier 3 (full trace) before anything
  client-facing.
LAST TESTED: 2026-07-21, current model version.
TEST CASE: /library/test-cases/theme-extractor-sample.txt
  (two short sanitized transcripts). Good output = 4 themes,
  both "handoff delay" mentions counted, all quotes verbatim.
OWNER: D. Okafor

Read that card slowly and notice what it actually is. The prompt text is the four-part pattern from the start of this chapter. The required inputs line is the Source Pack lesson. The known failure modes are the Output Skeptic's Checklist, compressed into institutional memory. The verification tier is last lesson's Verification Log, promoted from a habit into a specification. The card is the chapter, laminated. Anyone on your team who picks it up inherits, in ninety seconds of reading, judgment that took you weeks to earn.

What Earns a Card, and the Three Ways Libraries Die

Not every prompt deserves a card, and the fastest way to kill a library is to waive the entry criteria. A prompt earns a place in the Assessment Prompt Library when it clears three bars:

1. It ran at least twice on real work. Once is an anecdote. A prompt that performed on two different real inputs has demonstrated it is a pattern, not a fluke of one lucky transcript. Demos and toy examples do not count; the library holds instruments, not party tricks.
2. It survived verification with a known error profile. You do not need a perfect prompt; there is no such thing. You need a prompt whose mistakes you have caught, characterized, and written down. "This one paraphrases quotes about one time in ten, check three per run" is a professional-grade asset. "This one seems great" is not.
3. Someone other than its author can run it. Call this the grandmother test of documentation, the same standard you already apply to SOPs: if the instructions only work with the author standing behind the reader's chair supplying unstated context, they are not instructions, they are a performance. Hand the card to a colleague, say nothing, and watch. If they produce comparable output unaided, the card is real.

Hold those bars firmly, because there are three well-documented ways prompt libraries die, and you will feel the pull of all three.

The hoard. Somebody creates a shared doc, everyone pastes in everything, and within a quarter there are 400 prompts, unnamed, unversioned, untested, sorted by nothing. Nobody can find anything, so nobody looks, so the hoard grows in the dark like an unmanaged shared drive. A library's value is not its size; it is the trust that everything in it works. Fifteen tested cards beat 400 pasted ones by an order of magnitude, for the same reason a controlled document system beats a network folder named "FINAL_v2_new".

The clever one-liner. Every team has one member whose prompts are terse, brilliant, and completely non-transferable, because ninety percent of what makes them work is context that lives in the author's head: which files they always attach, which follow-up they always send, which outputs they silently discard. When that prompt is pasted into the library without its invisible scaffolding, colleagues run it, get mediocre results, and quietly conclude the library is overrated. The Prompt Card format exists precisely to force the invisible scaffolding onto the page: required inputs, failure modes, test case. If the author cannot fill in those fields, the prompt is not library-ready, however clever it is.

The imported pack. The internet is full of "500 ChatGPT prompts for consultants" bundles, and importing one into your library feels like progress. It is the opposite. Those prompts were never run on your work, your SOP formats, your clients, or your verification standards, which means every one of them fails the first entry bar on arrival. Worse, they dilute the library's core promise: that everything in it has been tested here. Treat internet prompt packs the way you would treat another company's SOPs: occasionally interesting reference material, never controlled documents. Your library grows one earned card at a time, from your own verified work, or its trust is gone.

The Arithmetic of a Tested Card: A Worked Example and a Failure Story

Let us put illustrative numbers on this, because the library's cost is visible (an hour of writing cards feels like overhead) while its return is spread thin across months, which is exactly the kind of return organizations undervalue. All figures below are hypothetical, offered as a template for the math you should run on your own work.

Take one recurring task from a readiness engagement: every week, an assessor synthesizes the week's new stakeholder interviews into a theme summary for the project team. Done with improvised prompting, the task runs about 50 minutes: five minutes reconstructing roughly the right prompt from memory, a first output that is formatted differently than last week's, two or three corrective follow-ups, then a nervous extra verification pass because the assessor is not sure which errors this week's improvisation produced. And the quality wobbles: some weeks the summary is sharp, some weeks a theme gets over-merged and nobody catches it until the workshop.

Now run the same task with Interview Theme Extractor v1.3. Fill three placeholders, attach the specified Source Pack, run, then execute exactly the verification the card prescribes: spot-check three quotes, scan the counts. About 15 minutes, and, crucially, a known error profile instead of a weekly mystery. The saving is roughly 35 minutes per run. Across a 12-week engagement, that single card returns about seven hours, or nearly a full working day, on one recurring task. Quality stops wobbling, because the prompt is identical every week and the verification is targeted at the failure modes that actually occur.

Then let it compound. A working Assessment Prompt Library for a readiness practice stabilizes at something like 15 cards across the four folders. If even half of them touch weekly-cadence work with savings in the same range, a single engagement returns 30 to 50 hours against the few hours the cards took to write. And unlike almost any other efficiency you will find this year, the asset survives the engagement. The next client, the next assessor, the next quarter: the cards are still there, still tested, still compounding. This is BCG's 10-20-70 rule operating in your favor for once: the 70 percent that is people and process includes your own process, and a library is the cheapest process investment available to you.

The failure story: the rubric that drifted

Here is the other side, a composite of a pattern you should expect to see in the wild. A consultant, genuinely skilled with AI, runs readiness scorecards for two clients in the same industry, three weeks apart. No library; he improvises the scorecard prompt each time from memory, and his memory is good. But not identical. For client A, his improvised prompt asks the model to score data readiness "considering quality, accessibility, and governance." For client B, three weeks later, the phrasing comes out as "considering quality, completeness, and ownership." Both produce confident, polished scorecards. Both clients accept them. Nobody can see the seam, because each document is internally consistent.

Four months later, both clients turn up in the same industry benchmarking conversation, hosted by the consultant's own firm, and someone puts the two scorecards side by side on one slide. Client A scored 3.2 on data readiness; client B scored 2.4; and a sharp analyst in the room asks the question that cannot be unasked: were these scored on the same rubric? They were not, quite. The difference is not fraud, and it is not even a large error. It is drift, the natural product of re-improvising a measurement instrument from memory. But in that room it reads as sloppiness, the benchmark is quietly withdrawn, and the firm spends a genuinely awkward month re-scoring both clients on a now-frozen rubric. A Scorecard Applier card with the rubric text pinned inside it, version-controlled, would have cost twenty minutes to write and would have made the inconsistency structurally impossible. Measurement instruments, of all things, must not be improvised twice. Your profession has known this since the first calibration standard; the lesson transfers to prompts without modification.

From My Library to Our Library

Everything so far builds your personal library, and for the first month that is exactly the right scope: test cards on your own work before offering them to anyone. But the destination is shared, and here the library connects back to two of the biggest ideas in Level 1.

Recall shadow AI: the finding that in most organizations, far more AI use is happening than leadership can see, improvised individually, with no shared standards and no visibility. The standard response is policing, and it fails, because people do not stop using tools that help them; they hide them better. The constructive response is to make the sanctioned path better than the secret one. A shared, tested prompt library is precisely that: the visible, quality-controlled alternative to everyone secretly improvising. Nobody hides their AI use when the fastest way to do the task is the tested card in the team library, and every card carries its verification tier like a safety rating. You do not defeat shadow AI with a memo. You defeat it with a better library than anyone can build alone in the shadows.

And recall MIT's learning loop one more time, because the team library is where the loop actually closes. An individual library makes one person compound. A team library makes the team compound: when one assessor discovers that the theme extractor undercounts repeated mentions, and that discovery lands in the card's failure-mode field as v1.4, every future user inherits the fix. That is the difference between eight people each learning eight lessons and eight people collectively holding sixty-four. McKinsey's high performers, the roughly six percent getting real impact, are about three times more likely to fundamentally redesign workflows; a team whose default workflow is "start from the card, improve the card" has redesigned the most fundamental workflow of all, which is how it learns.

The mechanics of a team library are deliberately modest, and you should resist any urge to make them grander:

• Name an owner. One person owns the library, the way one person owns a controlled document register. Not a committee. The owner does not write all the cards; the owner guards the entry bars and keeps the calendar.
• Hold a monthly 30-minute review. One recurring meeting with a three-verb agenda: promote (personal cards that cleared the three bars enter the team library), revise (cards with newly discovered failure modes or stale last-tested dates get updated and re-versioned), retire (cards nobody has used in a quarter, or whose job disappeared, are archived, not deleted; archives answer future questions). Thirty minutes is enough. If the meeting needs an hour, the library has grown past its trust.
• Track one number. Cards used this month by someone other than their author. That single figure tells you whether you have a library or a hoard, because it measures the only thing that matters: transfer.

One closing note for the chapter as a whole, because this lesson is its last. Look at what you are now carrying that you were not carrying five lessons ago: the four-part prompt pattern that makes requests precise; the Source Pack discipline that feeds AI clean inputs; the Output Skeptic's Checklist that catches the confident wrong answer; the Verification Log that makes trust proportional and auditable; and now the Assessment Prompt Library that makes all of it permanent, repeatable, and transferable. That is a complete working toolkit, and it is about to be put under load. Chapter 2.2 takes these instruments into the field for the first real assessment job: process discovery, turning an organization's tribal knowledge into an honest inventory of what it actually does. The prompts you write there will be the first new cards in your library. Bring the empty folders.

What to Do Monday Morning

The library exists the moment it holds one tested card. Here is the sequence.

1. Create the library file with the four folders: discovery, data audit, people synthesis, scorecard and reporting. One shared doc or wiki page is enough. Resist adding a fifth folder; the constraint is the feature.
2. Write your first three Prompt Cards from prompts that already worked for you this week. Use the Interview Theme Extractor card as your skeleton and fill every field, especially required inputs and known failure modes. If you cannot state a prompt's failure modes, it has not earned a card yet; run it through the Output Skeptic's Checklist first.
3. Add a test case and a last-tested date to each card. Build each test case from a small, sanitized sample of real work, and write one line describing what good output looks like. Date the cards today.
4. Schedule the monthly 30-minute review as a recurring calendar entry, even if you are the only attendee for now. Agenda: promote, revise, retire. The ritual matters more than the attendance.
5. Share one card with one colleague and watch. Give them the card and the required inputs, then say nothing. If they produce comparable output unaided, you have your first transferable asset and your first proof that the card, not the author, is doing the work. If they stumble, every stumble is a missing sentence on the card; add it, bump the version, and you have just performed your first revision cycle.

Key Takeaways

• Treat every prompt that worked on real work as a process asset, and apply the discipline you already use on SOPs: standardize it, version it, test it, and review it on a schedule.
• Build the Assessment Prompt Library around the four assessment jobs (discovery, data audit, people synthesis, scorecard and reporting), and store every entry as a Prompt Card: name and version, job-to-be-done, four-part prompt with {placeholders}, required inputs, known failure modes, verification tier, last-tested date, and a small test case.
• Expect prompts to decay because models change, your organization changes, and your document formats change; enforce last-tested dates and a quarterly re-test ritual using each card's test case.
• Admit a prompt to the library only when it has run at least twice on real work, survived verification with a known error profile, and passed the grandmother test: someone other than its author can run it unaided.
• Refuse the three library killers: the 400-prompt hoard nobody trusts, the clever one-liner that only works with its author's unstated context, and imported internet prompt packs that were never tested on your work.
• Run the arithmetic on your own recurring tasks: in the illustrative example, one tested card cut a weekly synthesis from about 50 to about 15 minutes, roughly seven hours saved across a 12-week engagement, and a 15-card library compounds across every future engagement.
• Pin measurement instruments especially: the drifted-rubric failure story shows that improvising a scorecard prompt twice produces two subtly different rubrics, and the inconsistency surfaces at the worst possible moment.
• Scale from personal to team library with modest mechanics: one named owner, a monthly 30-minute promote-revise-retire review, and one metric (cards used by non-authors), turning shadow AI improvisation into a shared learning loop the whole team compounds on.