Chapter 12 · Week 12

Building Your Prompt Library

What does it mean that the wise lay up knowledge — that good work should be stored and reused?

Chapter 12 — Building Your Prompt Library

“Don’t repeat yourself.” — The Pragmatic Programmer (the “DRY” principle)

“The wise lay up knowledge, but the mouth of a fool brings ruin near.” — Proverbs 10:14 (ESV)


Why This Matters

Eight weeks ago, in Chapter 4, I taught you to write a prompt the way you write a good instruction to a capable colleague — a clear objective, real context, a role, an example. You have been doing it ever since. By now you have written hundreds of prompts. And here is the uncomfortable truth about almost every one of them: you threw it away.

You wrote a genuinely good prompt on Tuesday to turn a messy meeting into action items. It worked. Then you closed the tab. On Thursday you had another messy meeting, opened a fresh chat, and wrote the whole thing again — a little differently, a little worse, because you were in a hurry and couldn’t remember exactly what made Tuesday’s version land. That is not a small waste. Over a career it is enormous. You are re-solving a problem you already solved, over and over, and getting a slightly different answer each time.

This week we fix that. We take the best prompts you have — the ones that reliably produce good work — and we turn them into assets: named, organized, reusable templates with blanks you fill in. This is the difference between a craftsperson who re-carves the same jig for every job and one who builds the jig once and keeps it on the wall. The secular software world has a three-word name for this discipline — Don’t Repeat Yourself — and it is one of the most durable ideas in the field. A prompt library is DRY applied to your own thinking.

Two things make this the right week for it. First, you now have enough good prompts to be worth organizing — you have raw material. Second, everything downstream gets easier once you have a library: the agents in Chapter 13 run on the prompts you feed them, and your whole AI-enhanced workflow in Chapter 15 is really a library of prompts plus the judgment about when to reach for each one. The library is the hinge between “I use AI” and “I have a system for using AI.”

And the spine rule of this whole course applies with full force here, because a library tempts you to relax it: You choose the tool. You own the verdict. A template makes the drafting fast and repeatable — but it does not make the output true. A prompt that produced a perfect summary yesterday can produce a subtly wrong one today on a different document. The library industrializes the asking. It does not industrialize the verifying. That part stays yours, every time the stakes are real.

Which brings us to this week’s question, the one we will earn rather than assert: Proverbs says the wise lay up knowledge. What does it mean that good work should be stored, organized, and reused — not scattered and re-invented and lost? Hold that. We will come back to it once your hands know what a library feels like.

Coach’s Note — If you have been in this course since Week 1, you already have a “prompt library” — it is just a bad one. It is scattered across your chat history, your sent folder, and your memory, none of which are searchable and all of which decay. This week is not about writing new prompts. It is about rescuing the good ones you already wrote from the places where they go to die.


12.1 — From One-Off to Asset: What a Prompt Library Actually Is

Let us be precise, because “prompt library” sounds fancier than it is. A prompt library is a place where you keep your best, reusable prompts, written as fill-in-the-blank templates, organized so you can find the right one in seconds and improve it over time. That is the whole idea. It is not software. It is not technical. For most professionals it is a single document.

Here is the shift in one sentence: a one-off prompt solves today’s problem; a template solves that kind of problem forever. The one-off is a fish. The template is teaching yourself to fish, then writing down exactly how so you never have to re-learn it.

Consider the difference concretely. A one-off prompt reads:

Can you help me write a reply to Mrs. Alvarez who is upset that her
order #4471 arrived broken and wants a refund? Be nice about it.

That worked once, for Mrs. Alvarez, for order 4471. It is welded to today’s specifics. You cannot reuse it tomorrow without rewriting it. Now the template version — the same good instinct, but with the specifics pulled out into blanks:

You are an experienced customer-support specialist for a small business.
A customer wrote the message below. Draft a reply in a {{tone}} tone.
Acknowledge their frustration first, do not promise more than
{{what_we_can_offer}}, keep it under 150 words, and end with a clear
next step.

Customer message:
"""
{{customer_message}}
"""

Same skill. Radically different value. The template works for every upset customer, forever, and it works better than the one-off because you had time to think it through once — you added “acknowledge their frustration first” and “do not promise more than we can offer,” refinements you would never bother with at 4:55 on a Friday. The library is where your best, least-rushed thinking gets saved for your worst, most-rushed moments. That is its real gift.

We ship you a working starter library — code/prompt-library-starter.txt — with three of these templates already built (a customer reply, a meeting-notes transformer, an audience-targeted summarizer). Open it now and read it. It is a plain text file you can paste into any document. There is nothing to install and nothing to run. It is a worksheet, and it is the seed of your Week-12 project.


12.2 — Anatomy of a Template: The Fields That Make a Prompt Reusable

A prompt scribbled in a chat box is a prompt you will lose. A prompt that lives in your library has structure around it — a small set of fields that turn a lucky one-off into a dependable asset. Here is the field set I want you to use, the same one in the starter file:

FieldWhat it holdsWhy it earns its place
NameA short, searchable labelYou cannot reuse what you cannot find (see §12.5).
Role / TaskWho + what, e.g. “Support · draft a reply”This is how you organize and filter the library (§12.4).
When to useThe trigger situationFuture-you won’t remember why this exists; tell them.
Model hintWhich tier/tool suits itRight-sizing the tool, the Chapter 3 skill, lives here.
VariablesEvery {{placeholder}} and what goes in itThe contract: what you must supply each time.
TemplateThe reusable prompt itselfThe asset.
ExampleOne filled-in instanceProves it works; reminds you how.
QualityWhat to check in the output before you trust itWhere the spine rule lives — your verification checklist.
Versionv1, v2… + a dateA prompt is never finished (§12.8).

You do not need all nine fields for a throwaway. You need them for anything you intend to keep. The two that beginners skip — and that separate a real library from a pile of prompts — are Quality and When to use. Quality is your personal verification checklist baked right into the asset, so that “verify the output” is not a virtue you have to remember but a step that is written down next to the prompt. When to use is the label that lets you, three months from now, understand why this template exists at all.

Coach’s Note — Notice the Quality field is doing the spine rule’s job structurally. Anyone can say “always verify AI output.” A library that puts the verification checklist right beside the template makes verifying the path of least resistance instead of a good intention. Design your library so the right thing is the easy thing.


12.3 — Variables and Placeholders: The {{Double-Brace}} Habit

Here is the single most important mechanical skill of the week, and it takes about ninety seconds to learn. A variable — also called a placeholder — is a blank in your template that you fill in fresh each time you use it. We write it in {{double curly braces}} so it is impossible to miss.

Why double braces? Because the danger with a template is forgetting to fill in a blank — sending the AI a prompt that still literally says {{customer_message}} where the customer’s words were supposed to go. Double braces make an unfilled blank scream at you. They are a checklist you cannot overlook. The exact symbol does not matter — some people use [SQUARE BRACKETS] or <angle brackets> — but pick one convention and use it everywhere, because consistency is what makes a blank instantly recognizable.

The judgment in this section is knowing what should be a variable and what should be baked in. A good rule:

  • Bake in the parts that are the same every time — the role (“an experienced support specialist”), the format (“under 150 words, end with a next step”), the guardrails (“do not invent policies”). These are your hard-won refinements. They belong in the fixed skeleton.
  • Make a variable out of every part that changes from use to use — the customer’s message, the tone you want, the audience, the length, the specific document.

Get this balance wrong in one direction and your template is rigid — it only works for one exact situation. Get it wrong in the other and your template is so full of blanks it is just a blank form, and you are writing the whole prompt from scratch anyway. The art is: variables absorb the variation you actually meet in your real work, and nothing more. You discover the right variables by using the template a few times and noticing what you keep having to change.

GOOD variable set for a summarizer:
  {{audience}}   — because who it's for changes constantly
  {{length}}     — because sometimes you need 5 bullets, sometimes a page
  {{document}}   — because the source changes every time

OVER-variabled (turns your template back into a blank page):
  {{verb}} the {{thing}} for {{person}} in {{format}} about {{topic}}...

Name your variables in plain words — {{audience}}, not {{var1}}. Future-you, filling this in during a stressful Tuesday, should understand every blank at a glance.


12.4 — Organizing the Library: By Role, By Task

Three templates need no organization. Thirty do. And thirty is where a real professional’s library lands within a couple of months — which means the difference between a library that saves you time and one that wastes it is how you organize it. The wrong organization is worse than none, because it gives you the false confidence of a system while hiding the template you need.

The organizing scheme that works for almost everyone is two-level: by role, then by task. A role is a hat you wear — “Manager,” “Support,” “Marketing,” “Personal,” “Board volunteer.” A task is a job you do while wearing that hat — “draft a reply,” “summarize a report,” “brainstorm names,” “turn notes into action items.” So your library becomes a small outline:

MANAGER
  - 1:1 agenda from last week's notes
  - Performance-review first draft (I edit heavily)
  - Turn a rambling update into a 3-bullet status
SUPPORT
  - Reply — unhappy customer
  - Reply — refund request
  - Escalation summary for my boss
PERSONAL
  - Rewrite this email so it's warmer
  - Explain this dense document to me like I'm new to it

Why role-then-task and not, say, by tool or by date? Because role and task are how your brain actually reaches for a prompt. You do not think “I need my Gemini prompt from June.” You think “I’m wearing my support hat and I need to draft a reply.” Organize the way you retrieve, not the way the files happened to arrive. This is the same principle a good kitchen uses: tools are grouped by the job you do with them, not by when you bought them.

Keep the tree shallow. Two levels — role, then task — is almost always enough. The moment you find yourself making sub-sub-categories, stop: a deep hierarchy is a library you have to navigate instead of scan, and scanning is faster. If a role collects more than a dozen templates, that is a signal to split the role, not to nest deeper.


12.5 — Naming and Finding: The Card-Catalog Problem

A template you cannot find in five seconds is a template you will rewrite from scratch — and then you own two versions of the same prompt, drifting apart. So naming is not decoration; it is the retrieval system. An old librarian’s problem: the book is useless on the shelf if the catalog card is wrong.

Good template names share three properties. They are specific (“Reply — unhappy customer,” not “Email helper”). They lead with the task so an alphabetical or scanned list clusters usefully (“Summarize — for my manager,” “Summarize — for a new hire”). And they use words you would actually search for at the moment of need — the word that will be in your head when you are stressed, not the clever word.

Weak nameWhy it failsStronger name
”Email prompt”Which email? You have nine.”Reply — unhappy customer"
"The good one”Meaningless in a month.”Summarize — 5 bullets for my boss"
"Meeting”Noun with no verb; unsearchable.”Meeting notes → action items"
"v2 final FINAL”Version noise in the name.”Board update — monthly” (version goes in its own field)

Two practical finding aids, both free and low-tech. First, put a one-line index at the top of your library document — just the names, so you can eyeball the whole collection at once without scrolling. Second, learn your tool’s search shortcut (Ctrl/Cmd-F in any doc, notes app, or sheet). If your names are the words you would search for, Cmd-F "refund" lands you on the right template instantly. A library is only as good as your ability to find the one prompt you need under mild pressure — design the names for the stressed version of you.

Coach’s Note — The test of a name is not whether it reads well today, when the prompt is fresh in your mind. It is whether stressed-you-in-three-months, who has forgotten this template exists, would type that word into the search box. Name for the future stranger who is also you.


12.6 — Where to Keep It: A Doc, a Notes App, or a Shared Sheet

Professionals lose more time to “where did I save that?” than to any hard part of this week. So let us settle it plainly. You have three good, no-cost, no-install homes for a prompt library, and each suits a different person:

HomeBest whenWatch out for
A single document (Google Docs, Word, one big Notion/OneNote page)You want the simplest possible thing that works. This is my default recommendation for most people.It can get long — lean on a top-of-page index and search.
A notes app (Notion, OneNote, Apple/Google Notes, Obsidian)You like tags, sub-pages, and searching across everything you keep.Don’t over-engineer the structure; a fancy database you must maintain is a library you will abandon.
A shared sheet (Google Sheets / Excel)You think in rows and columns, or you’re building for a team (§12.7) — one row per template, columns for the fields.A spreadsheet cell is a cramped place to write a long prompt; use it when your prompts are short and tabular.

Notice what is not on this list: your chat history, your sent folder, your memory, and a dozen sticky notes. Those are where prompts go to be lost. The whole point of a home is that it is one place, searchable, and durable — it survives you closing the tab.

My honest recommendation for someone starting today: one document. Paste in code/prompt-library-starter.txt, keep the field structure, and grow it. You can always graduate to a notes app or a shared sheet later, once you know from experience what you actually need. Do not let the choice of tool become an excuse to delay the work. The best library is the one you actually keep, in the tool you already open every day.

In BoodleBox — A document is where your library lives; BoodleBox is where your best templates can run. Because Concordia licenses BoodleBox for campus (sign in at box.boodle.ai with your Concordia account), you have one more home — and it is the one this week is really about. Keep your master library in the document; then, for the handful of templates you reach for constantly, open the bots area and choose Build Bot (labels move, so look for the “build your own bot” action, as of 2026): give the bot a name, pick the AI model that powers it, paste your best template in as its instructions, and optionally attach Knowledge — reference files it should always draw on. Now that template is not text you paste and fill; it is a bot you @-mention and talk to, and — if you like — one you publish or share with your team. The customer-reply template becomes a “Donor Reply” bot; the summarizer becomes a “Summarize-for-my-director” bot. That is a prompt library in its living, executable form. Fallback: off-campus or on any free tool, your document library does the same job by hand — you paste the template and fill the blanks yourself.


12.7 — Sharing Across a Team: From Personal Notebook to Shared Asset

A personal library saves you time. A shared library saves your whole team time and — this is the part people miss — makes the whole team’s AI output more consistent and higher quality, because everyone is drafting from the same well-tested prompts instead of each person improvising their own worse version. This is where a prompt library stops being a personal productivity trick and becomes an organizational asset.

The move from personal to shared changes what “good” requires, in three ways:

  1. Names and descriptions must make sense to someone who is not you. Your private shorthand (“the good one,” “Dana’s trick”) is illegible to a colleague. A shared library needs the When to use field filled in for real, so a teammate knows whether a template fits their situation.
  2. Guardrails and policy must be explicit. In a shared library, a template might be used by someone who does not know your organization’s rules. So the safety norms — never paste client PII, never bake in confidential figures — have to be written into the library itself, not assumed. This is where Chapter 14 and Appendix C become load-bearing.
  3. Someone has to own it. A shared document that everyone edits and no one curates rots — duplicates pile up, versions conflict, quality drifts. Name an owner (or a small group) responsible for approving additions and pruning the dead ones, exactly the way a shared kitchen needs someone who owns “is this still good?”

The mechanics are humble: a shared Google Doc or shared Sheet with edit or comment permissions is enough for most teams. You do not need special “prompt management” software to start — and I would caution you against buying any until a plain shared document has clearly hit its limits. Start with the shared doc. Let the pain teach you what you actually need before you spend money on a solution to a problem you might not have.

Coach’s Note — A shared prompt library is one of the highest-return, lowest-effort things a small team can build this year. It is a half-day of collecting everyone’s best prompts into one organized doc, and it lifts the floor of everyone’s AI work permanently. If you take one organizational idea out of this course, let it be this one.


12.8 — Versioning and Iterating: A Prompt Is Never Finished

Here is a mindset shift that separates amateurs from professionals: a prompt in your library is not a monument; it is a living draft. You will use a template, notice the output was slightly off, tweak the prompt, and the new version will be better. That is not failure — that is the point. A library is a place where your prompts get better over time because you keep improving the ones you use most.

To iterate without creating chaos, you need the lightest possible versioning discipline. You are not a software engineer and you do not need Git. You need three habits:

  1. Stamp a version and a date. v1 — 2026-06-01, v2 — 2026-07-01. When you improve a template, bump the number and the date. Now you can see at a glance which prompts are battle-tested and which are fresh.
  2. Write down why you changed it. One line: “v3 — added ‘do not invent owners’ because it kept assigning action items to people who weren’t named.” This is the single most valuable habit in the whole chapter, because it stops you from un-fixing a prompt later — from removing the very guardrail you added for a reason you have since forgotten.
  3. Keep the old version until the new one has proven itself. Paste the previous version below the new one, greyed out or marked “OLD.” If v2 turns out worse in some situation v1 handled, you can roll back. Delete the old one only once the new one has earned its place over several real uses.

Look at Example 2 in the starter file: its version line reads “v3 — 2026-06-28 (added the ‘do not invent owners’ guardrail).” That parenthetical is doing real work. It records a lesson the hard way — the prompt used to fabricate meeting-action owners — so nobody, including future-you, ever reintroduces the bug. Your version notes are the memory of your mistakes. A library without them repeats them.


12.9 — Evaluating Prompt Quality: Does It Produce Good Output, Every Time?

Now the hardest and most important section, the one that most people skip and shouldn’t. How do you know a prompt is actually good — good enough to trust in your library, to hand to a teammate, to reach for under pressure? Not because it worked once. A prompt that worked once might have gotten lucky. A prompt that belongs in your library produces consistent, correct, usable output across several runs and several sets of inputs. Evaluating that is a skill, and we ship you a tool for it: code/prompt-quality-rubric.txt.

The rubric scores a template on eight criteria — clear objective, context supplied, role/audience set, output format specified, anti-fabrication guardrails, whether the variables cover real variation, consistency across runs, and safety/policy-cleanliness. But the mechanical heart of it is a testing protocol you should internalize:

  • Run it three times on the same inputs. If the three outputs swing wildly in shape or quality, the prompt is under-specified — it is leaving too much to chance. Tighten the objective and pin the output format. A good template produces reliably-shaped output run after run.
  • Then run it once on different inputs. This tests whether your variables actually absorb the variation you meet in real work, or whether you have to rewrite the template every time the situation shifts a little. If you had to rewrite it, your variable design (§12.3) needs another pass.
  • Read the output like an editor, not a fan. Did it invent a fact, an owner, a citation, a policy? A template that reliably fabricates is worse than no template — it fails fast and confidently. The single most valuable line you can add to almost any template is an instruction not to make things up and to flag what it could not confirm.

And now the clause the rubric prints in bold, because it is the spine rule wearing work clothes: a high rubric score does not mean “send without reading.” The rubric measures the prompt. You still verify the output — every single time the stakes are real. A flawless template can still produce a wrong answer on a given run, because the model underneath is a confident next-word predictor, not an oracle. You choose the tool; you own the verdict. The library makes your asking excellent and repeatable. It never makes your verifying optional. That is the professional’s whole posture toward AI in one sentence: industrialize the draft, personally own the truth.

Coach’s Note — Watch the failure mode this week specifically. A polished library feels like authority. You reach for a template you have used fifty times, the output looks like it always looks, and you send it without reading — because the template is trusted, so surely the output is too. That is exactly the moment the fifty-first run quietly fabricated a number. Trust the template. Verify the output. They are different objects.


12.x — Interactive Lab: Template Filler

Below this chapter, on the website, you will find an interactive panel called the Template Filler. Go use it now — it is not decoration; it is where the {{double-brace}} habit gets into your fingers.

The panel shows you a real prompt template full of {{placeholders}}. You type into the blanks — an audience, a tone, a message, a length — and watch the final, ready-to-paste prompt assemble itself in real time as each variable drops into place. Fill them all and you get a prompt you could paste straight into BoodleBox — the AI platform Concordia licenses for campus (sign in at box.boodle.ai with your Concordia account) — or into any assistant you have open. Leave one blank and you will see the raw {{placeholder}} sitting there unfilled — which is exactly the mistake the double braces exist to catch, felt in your own hands instead of read about.

What it teaches is not “how to fill in a form.” It teaches the mental model of a template: a fixed skeleton plus a set of blanks, where the skeleton carries your best thinking and the blanks carry today’s specifics. Once you have watched a good prompt assemble itself from parts, you will start seeing every prompt you write that way — asking, automatically, “what here is the reusable skeleton, and what is just today’s detail?” That question is the whole skill of this chapter, and the Template Filler drills it faster than any amount of reading. Run it twice: once with the sample template, then once with a template of your own pasted in, and watch your own good prompt turn into a reusable asset. And when a template earns a permanent spot, do the move from §12.6 — turn it into a BoodleBox custom bot with Build Bot so you @-mention it instead of ever re-pasting.


12.10 — The Wise Lay Up Knowledge

Now the week’s question, given its due. What does it mean that the wise lay up knowledge — that good work should be stored, organized, and reused rather than scattered and lost?

“The wise lay up knowledge, but the mouth of a fool brings ruin near” (Proverbs 10:14, ESV). Read the verb: lay up. It is the language of a storehouse, a granary, a treasury — the deliberate, unglamorous work of saving what is good against the day you will need it. The proverb draws a contrast that maps almost eerily onto this chapter. The wise person accumulates — gathers knowledge, stores it, holds it ready. The fool’s mouth spends — pours out whatever comes to it in the moment, unstored and unconsidered, and brings ruin near. Wisdom hoards the good for later; folly improvises and squanders. A prompt library is, quite literally, laying up knowledge instead of pouring it out and losing it.

This is not a decorative parallel. The Proverbs treat wisdom as something built up over time — gathered, kept, handed on — never as a one-time flash of cleverness. “An inheritance,” the same book says elsewhere, is left “to his children’s children” (Proverbs 13:22). Knowledge, rightly held, is not consumed in the using; it is deposited, and it compounds, and it outlives the one who gathered it. The professional who saves and organizes their best prompts is doing in miniature what wisdom does at scale: refusing to let hard-won understanding evaporate the moment it is used. The version note that records why you added a guardrail is a small act of laying up knowledge — so that the lesson, once learned, is never un-learned.

But sit with the second half of the verse, because it guards against the specific temptation of a good library. “The mouth of a fool brings ruin near.” A library makes your mouth — your output — fast and fluent and constant. That fluency is exactly what folly counterfeits: much said, quickly, confidently, without weight behind it. A polished template can let you pour out words at a rate no wisdom is keeping pace with — send, send, send, each one looking authoritative, none of them read. The proverb’s warning is that fluency is not wisdom, and speed is not truth. This is the spine rule in the language of Scripture: you may lay up the knowledge and store the good prompts, but the wisdom is in what you send, and that judgment cannot be templated. The tool fills the storehouse. The steward decides what goes out the door.

In the confessional Lutheran frame, this is your vocation speaking. The work you do — the reply to the anxious customer, the summary your overloaded manager will trust, the notes the volunteer board depends on — is service to a real neighbor who is affected by whether you were faithful or careless. Laying up knowledge is not self-optimization; it is preparing to serve that neighbor well and consistently, on your worst day as on your best, because you did the wise thing of storing your best work where you could reach it. And refusing to send unverified output, however fluent, is loving that same neighbor enough not to bring ruin near with a confident, wrong word. The wise lay up knowledge. Then they weigh what they say. Both halves are the calling.


12.11 — Common Pitfalls

Pitfall: Hoarding prompts you never actually reuse. Example: You save 60 templates, most used exactly once, and now finding the 8 you use weekly means scrolling past 52 you don’t. Fix: A library is for the prompts you repeat. Save a template the second or third time you find yourself writing the same kind of prompt — not the first. Prune quarterly: if you haven’t used it in three months, archive it.


Pitfall: Over-variabling until the template is just a blank form. Example: {{verb}} the {{thing}} for {{audience}} in {{format}} about {{topic}} — you’re writing the entire prompt from scratch every time, so the “template” saves you nothing. Fix: Bake in everything that stays the same (role, format, guardrails). Make variables only for what genuinely changes use to use. Discover the right variables by using the template a few times and noticing what you keep editing (§12.3).


Pitfall: Baking real, confidential data into the saved template. Example: You save the customer-reply template with an actual customer’s name, order number, and account details still inside it — now your library is a confidentiality leak waiting to be shared. Fix: The template is a public shape; private details live only in the {{blanks}} at the moment of use, within your org’s policy. Never store PII, PHI, passwords, or confidential figures in the library itself. See Appendix C.


Pitfall: Trusting the output because you trust the template. Example: You’ve used your summarizer fifty times; on the fifty-first it invents a statistic, and you send it because “that template always works.” Fix: The template is trusted; each output is not. Keep a Quality checklist in every entry and actually run it. You choose the tool; you own the verdict — every time the stakes are real (§12.9).


Pitfall: No versioning, so you keep un-fixing your own prompts. Example: Months ago you added “do not invent owners” to your meeting template for a good reason; last week you “cleaned it up” and deleted that line; now it fabricates owners again and you’ve forgotten why it ever mattered. Fix: Stamp a version and date on every change, and write one line saying why. Your version notes are the memory of your mistakes — they stop you from repeating them (§12.8).


Pitfall: Choosing the storage tool becomes the whole project. Example: You spend three evenings comparing Notion vs Obsidian vs a fancy prompt-manager app and never actually save a single prompt. Fix: Start with one plain document in a tool you already open daily. The best library is the one you actually keep. Graduate later, once real use has shown you what you need (§12.6).


Pitfall: A shared team library with no owner. Example: Ten people can edit the shared doc; duplicates pile up, two templates for the same task quietly contradict each other, and quality drifts down until people stop trusting it. Fix: Name a curator (or small group) who approves additions and prunes the dead ones. A shared library without an owner rots (§12.7).


12.12 — Reps

The work is in the exercises. Reading about templates is not building a library — your hands have to do the filling, naming, and testing before any of this is real. A preview of what’s waiting:

  • Rescue three good prompts from your chat history and turn each into a proper template with variables.
  • Design the variables for a real prompt — decide what to bake in and what to make a {{blank}} — and defend the split.
  • Name and index a small library so you can find any template with one Cmd-F.
  • Version a template through an improvement, writing the why note that stops you un-fixing it later.
  • Score a template on the rubric — run it three times, then on fresh inputs, and decide if it’s library-ready.

This week’s AI policy for reps: You may (and should) use an AI assistant to help draft and improve your templates — ask it to critique a prompt, to suggest variables, to stress-test a template. But the judgment — what to keep, what to bake in, whether the output is trustworthy — is yours. Every rep that uses AI ends with an honest one-line AI usage note: what you asked, what it got wrong or missed, and what you decided. You choose the tool; you own the verdict.

A short Check Your Reps quiz is embedded on this page, right under the chapter. Take it before you move on — five questions, grounded in exactly what you just read.


12.13 — This Week’s Project

Your project is P12 — “Your Prompt Library,” specified in Project 12. You will build a real, reusable prompt library of 10–15 role-based templates for your actual work — organized by role and task, named so you can find them, versioned, and tested against the quality rubric so you know they produce consistent, good output. This is not a toy. It is a professional asset you will use long after this course ends.

At a high level: Normal tier builds and organizes the tested library. Medium tier turns your personal library into a shared, team-ready one with guardrails and an owner. Hard tier is the judgment no AI can make for you — a one-page memo recommending which of your recurring tasks should be templated and reused versus which must stay a fresh, thought-through, human-written response every time (some work should never be on autopilot, and knowing which is the whole skill). That memo is where the thesis of the course gets graded.


12.14 — Coach’s Final Word

Here is what I want you to carry out of Week 12. You have spent eleven weeks getting good at asking AI for things. This week you learned to stop throwing that skill away. Every good prompt you write from now on is a candidate for your library — a jig to hang on the wall, not a fish to eat once and forget. The professional who thrives with AI is not the one who writes a brilliant prompt on Tuesday. It is the one who still has it on Thursday, and hands it to a teammate on Friday, and improves it the following month.

That is a quiet, compounding advantage, and it is exactly the kind that lasts. Models will turn over — half the tool names in this course carry a higher version number every quarter. But a well-built library rides on top of whatever model you point it at. Your templates are yours. They encode your judgment about how your work should be done, and that judgment is the thing no update makes obsolete.

And underneath it all runs the proverb. The wise lay up knowledge. You are learning to store the good, organize it, and reach for it when it matters — and to guard your mouth even when the tool makes fluency free, because a fast wrong word still brings ruin near. Fill the storehouse. Then weigh what you send. The library makes you fast; your judgment makes you trustworthy; and it is the trustworthy professional, not merely the fast one, who is worth becoming.

Now go build it. The starter file is in code/, the Template Filler is waiting right below this page, and Project 12 is where your scattered prompts finally become a library.

See you on Monday.


Up next: Read the exercises and do all of Week 12’s reps, then build Project 12 — Project P12: Your Prompt Library. For where to keep your library and set up your tools, see Appendix A; for the tools referenced this week, Appendix B; for the never-paste-this rules your shared library must respect, Appendix C; and for any term that was new, Appendix D. Then Chapter 13 — AI Agents and the Future of Work, where your library becomes the fuel that agents run on.

Interactive Lab — Week 12
Template Filler

A template is a fixed skeleton plus a set of blanks. The skeleton carries your best, least-rushed thinking; the {{blanks}} carry today's specifics. Pick a template, fill the blanks, and watch the ready-to-paste prompt assemble itself. Leave one empty and you'll see the raw placeholder sitting there — the mistake the double braces exist to catch.

Fill the blanks
Ready-to-paste prompt
 
Try: Fill every blank in the customer-reply template, then delete one — watch the raw {{placeholder}} flash back in orange. Then switch to Paste your own… and turn one of your real prompts into a reusable asset.
Check Your Reps

Check Your Reps — Building Your Prompt Library

Question 1 of 5
What is the essential difference between a one-off prompt and a template?
Why: A template extracts the changing specifics into {{blanks}}, so the same skeleton works for every instance of that kind of problem, not just today's.
Question 2 of 5
Why does the chapter recommend writing variables in {{double braces}}?
Why: Double braces are a checklist you can't overlook; the exact symbol doesn't matter, but a loud, consistent marker catches the 'forgot to fill a blank' mistake.
Question 3 of 5
In a summarizer template, which of these is the best thing to turn into a {{variable}} rather than bake in?
Why: Bake in what stays the same (role, format, guardrails) and make variables only for what genuinely changes use to use — like who the summary is for.
Question 4 of 5
The chapter says the two-level organizing scheme that works for most people groups templates by what?
Why: Role-then-task mirrors how your brain actually reaches for a prompt ('I'm wearing my support hat and need to draft a reply'), so you organize the way you retrieve.
Question 5 of 5
You've used a template fifty times and it always works. What does the chapter say to do on the fifty-first use?
Why: The library industrializes the asking, not the verifying; a trusted template can still fabricate on a given run, so you choose the tool but own the verdict every time.
YOU FINISHED. NICE WORK.