Mastery: build your prompt library

• [ ] I have prompts for at least three families: explain, transform, extract, classify, compare, plan, or critique.
• [ ] Each prompt states audience, authoritative input, task, and success criteria.
• [ ] Each prompt says what to do when information is missing.
• [ ] I can explain when not to use each prompt.
• [ ] I prefer the lightest pattern that works for the job.

Mastery prompt: List your five prompts and label each with its family and primary risk (invention, format drift, overreach, stale context).

• [ ] Few-shot examples are short, consistent, and include at least one messy case when classification or extraction matters.
• [ ] Examples do not teach invention or overconfidence.
• [ ] Structured prompts define fields and empty-value rules.
• [ ] I validate structured outputs before they enter another system.
• [ ] Gold policy facts are separated from style samples.

Mastery prompt: Take one extract or classify prompt and add or revise one edge-case example that forces a null, TBD, or escalate outcome.

• [ ] Multi-step jobs use decompose-and-clarify rather than one mega-prompt.
• [ ] Human checkpoints sit before irreversible actions.
• [ ] Standing rules are short enough to keep across stages.
• [ ] I can stop a run to gather facts instead of demanding more eloquence.
• [ ] I know which tasks need tools beyond chat.

Mastery prompt: Rewrite one overloaded request into a three-stage pattern with a review gate.

• [ ] Shared prompts have an owner and last-tested note.
• [ ] I keep a small held-out set of real cases for prompts I reuse weekly.
• [ ] After editing a prompt, I re-test old failures and one new case.
• [ ] I retire prompts I cannot explain.
• [ ] I debug by changing one dial at a time.

Mastery prompt: Create a one-page index for your library: name, job, inputs, outputs, known limits, link or location, last test date.

Treat an important prompt change like a small product release. Start with the reason for the change: a known failure, a new output requirement, a policy update, or a change in the model or connected tool. Write the expected improvement before editing. That note prevents a vague rewrite from being declared successful simply because the new output looks different.

Run the revised prompt against three groups of cases. First, use ordinary examples that represent most real work. Second, replay cases the previous version failed. Third, include boundary cases with missing, contradictory, long, or sensitive input. Score both versions with the same criteria. Accuracy and evidence rules should be hard gates; tone or brevity cannot compensate for invented facts.

Record regressions as well as improvements. A new example may improve classification while making the response imitate details that do not belong. A stricter schema may improve parsing while causing the model to force uncertain information into required fields. If the result regresses on a critical case, do not release it merely because its average score increased.

For a shared library, keep the previous version available, state who approved the change, and communicate any new input or review requirement. Recheck the prompt after a model update or a change in the source material. The library is dependable only when users know which version they are using and what evidence supports it.