Lesson 6.4: Capstone: build and test your own prompt library
Bring the course together in one project: choose your five highest-value tasks, build tested, safe prompts for each, document them and measure what they save.
By the end of this lesson you will have a working, tested and documented library of five prompts for your own job, with evidence that each one works, a safety and privacy review, a measure of the time it saves and a one-page case study you can show a manager or an interviewer. This is a project and not a topic: it asks you to use, in one place, what Modules 1 to 6 taught, from the anatomy of a prompt to testing, from grounding to injection. You should have read the whole course, or at least be ready to look back at the lessons named in each step. Set aside about ten to twelve hours, spread over two weeks if you can, since the best libraries are improved after a few days of real use.
A pile of good prompts is not yet a library. A library is a set of prompts that someone else could pick up and use, that has been tested on realistic cases, that states what it will not do and that gets maintained. The difference is the difference between a handful of clever tricks and a working tool, and it is exactly the difference that employers and clients care about. Nobody is impressed that you can get one good reply. They are impressed when you can show that a prompt works on 30 cases, what it costs, where it fails and how you fixed it.
What you will build
The finished project has seven parts.
Part · What it is · Where this course taught it1. Task audit · A ranked list of your tasks with time at stake · Lessons 1.1, 4.4
2. Five prompt templates · Prompts with blanks, examples and clear rules · Lessons 1.3, 1.4, 2.1 to 2.3, 3.3
3. Test sets and rubrics · Cases and scoring for each prompt · Lessons 5.1, 6.1
4. Evidence · Before and after scores with their uncertainty · Lessons 5.1, 5.2
5. Safety and privacy review · Checks for data, injection and fairness · Lessons 6.2, 6.3
6. Library document · Entries with owners, versions and change logs · Lesson 3.3
7. Case study · A one-page account of what you did and found · This lesson
Do not skip the testing and the review to get to the case study. They are the project.
Step 1: Audit your tasks and choose five
Start with what you actually do. Over a week, or from memory of a typical month, list every task where an assistant might help: replies, notes, summaries, reports, analysis, planning, research, formulas. For each, write how often you do it a week and how long it takes. Multiply to get the weekly minutes at stake. Then add a pain score from 1 to 5 for how much you dislike or struggle with it, and a risk score from 1 to 5 for how costly a mistake would be.
Here is an example list for a credit operations analyst.
Task · Times a week · Minutes each · Weekly minutes · Pain · RiskCustomer reply drafts · 40 · 6 · 240 · 3 · 3
Report commentary · 2 · 45 · 90 · 4 · 4
Meeting notes to actions · 5 · 15 · 75 · 4 · 2
Data cleaning formulas · 3 · 25 · 75 · 3 · 3
Weekly status note · 1 · 30 · 30 · 2 · 2
The weekly total is 510 minutes, 8.5 hours. Customer replies lead on volume, at 240 minutes.
Predict first: from this list, which five would you build prompts for, and is the biggest-minutes task always the best place to start? Decide before reading on.
Volume points to customer replies. But two other things matter. A prompt for a high-volume task needs a high standard of safety, since errors repeat 40 times a week, and the risk score for replies is 3. Report commentary has fewer minutes but a risk of 4 and a pain of 4, so it needs careful grounding and verification. A sensible library mixes a high-volume, moderate-risk task, where gains are large, with a few that teach you the harder skills. Choose five, covering at least three different kinds of work: writing, extraction or summarising, analysis and planning, say. Do not choose five variations on one prompt, because you will learn less.
Step 2: Define each task before writing the prompt
For each of the five, write a short brief in your own words, in the spirit of the definition of done from Lesson 1.4.
Goal: what a good output achieves, in one sentence.
Reader and use: who reads it, what they do with it, and what happens if it is wrong.
Inputs: what you will give the prompt each time, such as facts, a message or a table.
Output: the format, length and tone, with an example of a good one.
Definition of success: the rubric you will score against, in four or five criteria with anchors.
Limits: what the prompt must never do, such as promise a refund or state a number not provided.
Writing the rubric now, before the prompt, is the single most useful discipline in the project. It stops you from judging by mood, and it tells you what the prompt must contain.
Step 3: Write the prompts
Use the course as a checklist. Each prompt should have:
1. A clear task and the role and audience, as in Lesson 1.3.
2. Fenced material and a rule that the fenced text is data, as in Lessons 1.3 and 6.2.
3. Context and any defined terms, as in Lessons 1.4 and 2.2.
4. A fixed format and tone, with a short style sheet if you write for an organisation, as in Lessons 2.3 and 3.3.
5. One to three examples where a judgement or a format is hard to describe, as in Lesson 2.1.
6. A fallback for missing information, such as "not stated" or a request for the missing fact.
7. A reasoning or checking step for tasks that involve numbers or judgement, as in Lessons 3.1 and 3.4.
8. Blanks marked in capitals in square brackets, so the prompt becomes a template.
Keep each one short enough to read at a glance. If a prompt has grown past about 400 words, ask which rules change the output and cut the rest, because every added rule is another one that can be missed, as Lesson 1.4 showed. For tasks that need several steps, write a short chain, as in Lesson 3.2, and note where a person checks.
Step 4: Build the test sets
For each prompt, assemble a test set of 15 to 20 cases, using the structure from Lesson 5.1.
About half typical cases from real work, with sensitive details removed.
About a quarter edge cases: very short, very long, two issues at once, missing information, a mix of languages.
A few adversarial cases from Lesson 6.2: text that tries to give the prompt orders, or asks for something outside its scope.
Where it matters, matched pairs for fairness, as in Lesson 6.3.
Keep these apart from any examples in the prompt. Where there is a correct answer, record it. Where there is not, rely on the rubric. Fifteen to twenty cases is small, and you should say so in your case study, but it will catch most large problems, and it is a respectable start for personal work.
Step 5: Run, score and improve
This is the core of the project, and it follows the routine of Lesson 5.1.
1. Run the first version on every case. Record the outputs and score each against your rubric. This is your baseline.
2. Read the failures, not just the average. Group them: ambiguity, missing information, tone, invented facts, format, a rule ignored.
3. Change one thing, targeted at the commonest failure. Add a rule, an example, a fallback or a check.
4. Rerun the whole set and compare case by case. Note the flips in both directions, as Lesson 6.1 explained.
5. Repeat until the gains fade, which, as Lesson 3.4 showed, usually happens within three or four rounds.
6. Check consistency. Run each case three times and note where results differ. Tighten the closed choices if needed.
7. Keep a log: the date, the change, the scores and the decision.
Report your results with their uncertainty. With 20 cases, a gain from 14 correct to 18 is a convincing lean, and not a proof, and you should write it that way. Where a task has numbers or facts, check every figure against the source on every run. Where it is a classification, count the right answers. Where it is writing, score against the rubric, ideally with a colleague scoring a sample blind.
Step 6: Review safety and privacy
Before any prompt goes in the library, put it through a short review. The questions come from the previous lessons.
Check · Question · LessonData · Does the prompt need personal or confidential data, and is the tool approved for it? Can I use placeholders? · 6.3
Untrusted text · Does it read text from outside, and is that fenced and marked as data? · 6.2
Power · Can it do anything beyond writing, and does a person approve that? · 5.4, 6.2
Invention · Is there a "not stated" fallback, and is every fact traceable to a supplied source? · 2.2, 5.3
Fairness · Does it assess or recommend about people, and have I run a paired test? · 6.3
Verification · What must a person check before the output is used, and is it written in the entry? · 2.4
Disclosure · Do the rules require telling the reader that AI was involved? · 6.3
Record the answers in the library entry. A prompt that fails a check is not finished: fix it, or write down plainly what it must not be used for.
Step 7: Write the library document
Each prompt gets an entry in a single document that anyone could pick up. Use the template from Lesson 3.3, with a few additions.
text
NAME: Customer reply, billing complaint
VERSION: 3, 12 November 2026 OWNER: [YOUR NAME]
PURPOSE: First reply to a customer reporting a wrong or double charge.
NOT FOR: Fraud reports, legal threats, anything involving a refund decision.
INPUTS: customer message; facts from our records; agent name.
PROMPT:
[THE FULL TEMPLATE, WITH BLANKS]
EXAMPLE INPUT AND OUTPUT:
[ONE FILLED-IN CASE]
HOW TO CHECK BEFORE SENDING: confirm the amount and date against the record;
confirm no promise of a refund is made; read it aloud.
TEST RESULTS: 18 of 20 cases at 4 or more on every rubric criterion
(version 3); 12 of 20 for version 1. Consistent on 17 of 20 over three runs.
Known weaknesses: messages with two issues; replies in mixed Hindi and English.
SAFETY NOTES: no personal data beyond first name and amount; customer text is
fenced and treated as data; a person sends every reply.
CHANGE LOG:
v3: added rule for two issues, one example. v2: added "no refund promises".
A short front page lists all five prompts, what each is for and who owns them. Store it somewhere your colleagues can reach, keep one source of truth and set a review date.
Step 8: Measure the value and write the case study
Time saved is the simplest measure of value. Take a week of real use, count how many times you used each prompt, estimate the time it took before, and record the time with the prompt including checking. Use the value simulator above to turn the figures into hours saved and a payback period. Add the quality evidence from your tests, and anything colleagues said.
Then write a one-page case study. It is the piece you will actually show people, so make it honest and concrete. A good structure has six short parts.
1. The problem: the task, how often, how long, and what went wrong with the usual approach.
2. What I built: five prompts, and the idea behind each in a sentence.
3. How I tested them: the test sets, the rubric and the scoring.
4. What I found: before and after scores, with the numbers and the uncertainty, and one surprising failure.
5. What I did about risk: the safety and privacy review, and anything I decided not to automate.
6. Result and limits: hours saved, what I would do next, and what the evidence does not show.
A reader should be able to trust it because it states its limits. "The reply prompt rose from 12 to 18 of 20 cases at the target standard, on a small test set that I plan to enlarge" is far more credible than "the prompt is excellent".
How you will be judged: a self-assessment
Score your own project against a rubric that weights what matters. If you are working with a mentor or a manager, ask them to score it too, and compare.
A worked example
A credit operations analyst runs the capstone over two weeks. Her audit gives the five tasks above. She builds a template for each: customer replies, report commentary, meeting notes to actions, a formula helper and the weekly status note. The reply template has a style sheet and two examples, the commentary prompt is grounded in the supplied table with a "figure needed" fallback, and the notes prompt uses a schema with "not stated".
She builds test sets of 20 cases each. The first version of the reply prompt scores at the target standard on 12 of 20 cases, failing mostly on two-issue messages and on tone. After adding a rule, an example and a fixed sign-off, it reaches 18 of 20. Run three times on each case, it gives the same category and the same promised action on 17 of 20. Her adversarial cases show one failure: a message with an embedded line asking the assistant to offer compensation produces a draft that does so. She adds a fenced-data rule and a "no compensation" line, and a human approval step, and the case passes.
Her paired test on the commentary prompt, which mentions branches by name, finds no difference in tone across branch names on 30 pairs, and she notes that 30 is too few to be sure. The time measure after a week: replies fell from six minutes to three including checking, saving about two hours a week; commentary from 45 to 25 minutes; notes from 15 to 7. She writes the case study, shares the library with her team and sets a review for the end of the quarter.
Common mistakes
Five prompts for one kind of task. Cover different skills and risks.
Writing the prompt before the rubric. Decide what good looks like first.
Testing on the examples. Keep test cases apart from prompt examples.
Reporting an average and ignoring the flips. Read the cases that changed.
Skipping the safety review. A prompt with a hidden risk is not finished.
A library no one else can use. Entries need owners, examples, limits and a check.
Claiming more than the evidence shows. State the sample size and the limits.
Never maintaining it. Set a review date and re-test when tools change.
Key takeaways
A prompt library is a set of tested, documented, owned prompts with stated limits, not a list of good prompts.
Start with an audit of weekly minutes, pain and risk, and choose five tasks that cover different kinds of work.
Define the goal, inputs, output and rubric before writing each prompt, and build each as a template with fenced material, a fallback and a check.
Test on 15 to 20 cases, including typical, edge and adversarial ones, change one thing at a time, read the flips and check consistency.
Review every prompt for data, untrusted text, power, invention, fairness, verification and disclosure, and record the answers.
Measure value after checking, document each entry, and tell the story honestly, with numbers, uncertainty and limits.
Check yourself
1. Why write the rubric before the prompt?
It fixes what good looks like, stops you judging by mood and shows what the prompt must contain.
2. Which kinds of case belong in each test set?
Typical, edge, adversarial and, where people are affected, matched pairs for fairness, plus any past failures.
3. A task takes 8 minutes, you do it 30 times a week, and the prompt cuts the time by 50 per cent after checking. How many hours does that save a week?
30 × 8 × 0.5 ÷ 60 = 2 hours.
4. A prompt scores 14 of 20 before a change and 17 after, but 4 cases flipped. What should you do?
Read the four flips. Some may have gone from right to wrong, so the net gain of three may hide new failures.
5. What belongs in a library entry besides the prompt?
The name, version and owner, purpose and limits, an example, a check to make before using it, test results and known weaknesses, safety notes and a change log.
Try this
This is the project. Plan about ten to twelve hours, in sessions of an hour or two.
1. Audit (1 hour). List your tasks for a typical week with times, minutes, pain and risk. Compute weekly minutes. Choose five that cover at least three kinds of work. Draw your own version of the minutes chart.
2. Briefs (1 hour). For each task, write the goal, reader, inputs, output, rubric and limits.
3. Prompts (2 hours). Write the five templates using the checklist in Step 3. Add examples, fallbacks and a checking step.
4. Test sets (2 hours). Build 15 to 20 cases for each prompt, with edge and adversarial cases. Remove sensitive details. Keep a separate set of examples.
5. Run and improve (3 hours). Baseline, read failures, change one thing, rerun, compare case by case, check consistency and keep a log. Stop when gains fade.
6. Review (1 hour). Complete the safety table for each prompt. Fix failures or record the limits.
7. Document and measure (1 hour). Write the library entries and front page. Over a week of use, record times and compute value with the simulator.
8. Case study and self-assessment (1 hour). Write the one-page case study. Score yourself with the self-assessment tool, and ask someone else to score it too.
Deliverable · Done? · NotesTask audit with ranking · ·
Five briefs and rubrics · ·
Five prompt templates · ·
Five test sets of 15 to 20 cases · ·
Before and after scores with uncertainty · ·
Safety and privacy review for each · ·
Library document with entries · ·
Measured time saved · ·
One-page case study · ·
A good result is a library you would be happy for a colleague to use tomorrow, evidence that you can defend, and a case study that is honest about its limits.
Where to go next
You have now covered how models read prompts, the core techniques, reasoning and templates, prompts for professional work, testing and grounding, and safe, reliable practice. Three directions follow naturally. If you want to build products on models, the AI Engineering track covers retrieval, evaluation at scale, agents and deployment. If you want to deepen the statistics behind testing and comparing prompts, the Data Science track covers sampling, confidence intervals, experiments and validation. And if you simply want to keep improving, the best next step is the one this project began: keep a log, keep testing and keep your library alive. Models will change, and the habits in this course, which are to say what you mean, supply the facts, check the output, measure before you trust and protect other people's information, will not.
Tags: Prompt Engineering Capstone Prompt library Portfolio Project