Capstone: Your Prompt Playbook
Assemble everything into a living playbook: five task templates, a test set, a defense checklist, and a migration log.
Create the playbook as a versioned repo
Your playbook is an asset, so it lives in version control, not in your memory. Make a folder structure that separates templates, tests, and logs, and put it under git so every change is diffable and reversible.
prompt-playbook/ templates/ # reusable prompts, one file per task family, versioned tests/ # fixed input-to-expected sets per template redteam/ # attack cases + block-rate results defense-checklist.md migration-log.md README.md # how to use it, how to add a templateVerifyYou have a git repo with these directories ready to fill — prompts now have a home outside any single app.Build templates for five task families
Cover the recurring shapes from this course. Each template has a role, delimited input, an output contract, and slots for few-shot examples. Start with these five and add your own over time.
Create one versioned template each for: 1. Extraction / classification (strict JSON contract + null policy) 2. Summarization (length, audience, what to keep vs drop, grounding) 3. Reasoning / analysis (step-by-step, then a structured verdict) 4. Rewriting / style transfer (voice rules + a do-not-change list) 5. RAG answer (grounding, citations, scripted no-answer) Each file: role -> constraints -> <input> delimiters -> output contract -> 2-3 few-shot slots -> version header.VerifyFive reusable templates exist, each self-contained and copy-ready, all following the same skeleton.Assemble a fixed test set per template
Templates without tests are hope. For each, collect representative inputs with known-good outputs, including the hard edge cases you have already hit. This is what makes every future change safe to ship.
For each template, add a tests file with 8-15 cases: - typical inputs (the common path) - edge cases (empty, huge, ambiguous, non-English, multiple entities) - past failures (every real bug becomes a permanent case) Store each as input + expected_output (or a checkable assertion). This fixed set is what you A/B new prompt versions and model migrations against.VerifyEach template has a stored, rerunnable test set that includes your real-world edge cases and past failures.Write the defense checklist
Distill Module 6 into a checklist you run before shipping any prompt that touches untrusted input or tools. Keep it short enough that you will actually use it every time.
Defense checklist (run before shipping): [ ] Untrusted input is delimited and labeled as data (spotlighting) [ ] System rules assert precedence; sandwich reminder after the untrusted block [ ] Output is contract-constrained + screened; safe refusal shape defined [ ] Tools are least-privilege; irreversible actions need human confirmation (in code) [ ] No secrets or PII in the prompt — it's designed safe-to-leak [ ] Red-team suite passes; new attacks added as regression casesVerifyYou have a concise, checkable list that turns Module 6 into a repeatable pre-ship gate.Start the migration log
Record model and prompt changes so future-you knows what happened and why. Every version bump and model swap gets an entry tied to test-set results, newest first.
migration-log.md — newest first. One entry per change: ## 2026-08-02 — extraction v3 (claude-sonnet-5 -> next-gen) - Change: migrated model; re-tuned the date-parsing rule. - Reason: cost + better long-context recall. - Eval: test set 94% -> 97% accuracy; format validity 100%; cost -35%. - Rollback: revert to the v2 tag if regressions appear.VerifyYour log has at least one dated, results-linked entry a teammate could read to understand a change.Set a maintenance ritual
A playbook decays if it is write-once. Define exactly when you update it — every new failure, every model launch, every new task family — so it stays the living source of truth for your prompting.
Maintenance ritual: - New production failure -> add a test case + fix the template (same day). - New model released -> baseline all templates on it against their test sets; log results. - New recurring task -> add a template + tests. - Quarterly -> prune dead templates, review block-rate trends, update the defense checklist.VerifyYou can state the exact triggers that make you update the playbook — it's a living asset, not a one-time document.