Prompt Engineering Mastery/Prompt Hacking & Defense
Lesson 6 / 6 · 16 min
Course contents
Walkthrough

Capstone: Your Prompt Playbook

Assemble everything into a living playbook: five task templates, a test set, a defense checklist, and a migration log.

Steps · 0 / 6 done

  1. 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
    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 template
    VerifyYou have a git repo with these directories ready to fill — prompts now have a home outside any single app.

  2. 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.

    prompt
    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.

  3. 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.

    prompt
    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.

  4. 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.

    prompt
    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 cases
    VerifyYou have a concise, checkable list that turns Module 6 into a repeatable pre-ship gate.

  5. 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.

    prompt
    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.

  6. 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.

    prompt
    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.
Check your understanding
Q1. What makes a prompt template library trustworthy to reuse across projects?
Q2. Your playbook's defense checklist exists to:
· Tick off the 6 step(s) above.
· Score 100% on the quiz.
Vocabulary in this lesson
ModelThe trained network itself: billions of parameters that turn a context into the next token, and nothing more.

Plain-English definitions from the AI Coding Dictionary.