Build a prompt library that earns its place

You saved 40 prompts last month, but today you cannot tell which one preserves policy exceptions. A library is useful only if it helps you choose a tested starting point and understand when that starting point fails.

Before you begin: Complete the prompting lessons. A text editor or notes application is enough.

Build three entries, not a prompt dump

Create entries for a source-grounded summary, a message classifier, and a meeting-action extractor. These tasks exercise different failure modes: omission, ambiguous labels, and invented fields. You can keep the library in three text files, a document, or a table. No app or API is required.

For each entry, record its purpose, required inputs, prompt text, output expectations, test cases, known limitations, version, and last review date. The purpose should name a real task. “Universal expert assistant” is too broad to test meaningfully.

Write the first entry completely

Start with a policy summary. Its required input is a policy passage. Its output is a short explanation for a first-time reader that preserves material limits and exceptions. A draft prompt is:

Summarize the supplied policy for a first-time reader.
Preserve all limits, exceptions, and restrictions.
Use only the passage. Do not fill missing facts.
Use up to three short sentences unless preserving a material rule needs more.

Policy:
[Insert the passage here]

The bracketed line is an instruction to the person preparing the prompt. Replace it with actual source text before running the task. If your program fills templates automatically, validate that every required input is present before sending the request.

Give the entry a small test set

Use three invented policies: an ordinary lending rule, a lending rule with an exception, and an incomplete rule with no duration. Write the expected facts and acceptable handling of missing information before testing the prompt.

For the exception case, use: “Items may be borrowed for seven days, except reference items, which remain on site.” A passing summary must preserve both the seven-day limit and the reference-item restriction. “Borrow any item for a week” fails even though it is concise.

For the incomplete case, do not require the model to guess a duration. A useful summary may state the known rule and note that the borrowing period is not specified. Your scoring should reflect the intended task, not insist on exact wording.

Add the other two entries

For classification, define the allowed labels and what happens when more than one applies. Include a question that reports a current problem. For action extraction, require evidence from the notes and an explicit representation for missing owners and deadlines.

Each entry needs its own rubric. A source summary cannot be graded solely by valid labels, and a classification result does not need polished prose. Reusing one generic “quality” score across unrelated tasks hides what the library is supposed to do.

Keep a change history that explains decisions

When you revise a prompt, save the previous version and the failing example that motivated the change. Run the old test cases again. If a new instruction fixes missing exceptions but causes overly long summaries everywhere, decide whether that tradeoff is acceptable or whether the instruction needs another revision.

Record the product or model and relevant settings used during testing. A prompt may behave differently after a model update. A date without a test result is only an editing timestamp; it is not evidence that the entry still works.

Make the library easy to use on a phone

Keep the reusable prompt short enough to inspect without scrolling through a large program. Put test cases and notes below it. Use clear input labels rather than decorative symbols. Keep source passages separate from the template so copying one does not accidentally copy yesterday's facts into a new task.

If you later build a UI, its first responsibility is to preserve those boundaries and show missing inputs. A random prompt generator or fake “quality score” is not a substitute for test results.

Complete a release check

Give someone else one entry and a new source passage. Can they identify the required input, run the task, and judge the output using only the entry? Record what confused them and revise the documentation.

The next lesson moves from user-written prompts to application instructions and explains why message roles are not the same thing as access control.

Further reading

A Prompt Pattern Catalog is a source of task structures to evaluate. The library design and fictional test cases here are an original project exercise.

Continue to the next lesson.