Recap and final exam

Ten modules to go from "extract information from this email" to a versioned, evaluated, injection-hardened prompt in a shared library. Here is the course condensed, then the threads that run through it.

The course at a glance

Module	What to retain
1. Anatomy	Task, context, constraints, format; the naive prompt fails differently every time
2. System prompt	System holds what is stable; instruction priority is higher, not absolute
3. Zero / one / few-shot	One example locks format; several contrasting examples teach distinctions; recency bias matters
4. Chain of thought	Scaffolded reasoning beats "think step by step"; A/B-test, CoT is not always better
5. Structured JSON	Schema-constrained generation beats JSON mode; make the model tell you what it does not know
6. Style and tone	Replace vague adjectives with checkable constraints; length in sentences beats length in words
7. Language pitfalls	Prompt in the language of the answer; supply today's date; sarcasm needs an explicit rule
8. Injection defence	Delimiters raise the bar, least-privilege tools close the door; the prompt is not a security boundary
9. Evaluation	Fifty labelled examples, per-field scores, A/B with the same matcher, treat noise as noise
10. Prompt library	Templates and variables, semantic versioning, review with eval attached, cost report monthly

The threads running through the course

Everything the model uses to answer must be inside the prompt. The model has no memory of your project, no calendar, no idea what "the usual format" means. Every module treats a specific consequence of this. Module 1 lists what is missing when the model invents. Module 2 hoists the stable part into system. Module 7 puts today's date into the prompt because the model has none. Module 8 warns that even the parts you thought were framing can be overridden by input that looks like framing. The theme is one and the same: no telepathy with the model.

Measurable beats plausible, and there is no shortcut. Modules 3, 4, 6 and 9 all end with the same instruction: A/B-test on a test set, read per-field scores, prefer the shorter and cheaper of two ties. Prompt engineering read from social media looks like magic incantations; prompt engineering that ships to production is an evaluation loop with taste for the details of the failures.

Structure at the edges, freedom in the middle. The prompt lives between two hard interfaces: the input schema on one side, the output schema on the other. Modules 5 and 10 nail down those edges — typed output, versioned template, documented context — precisely so the middle can evolve. A well-scoped prompt is one you can change without breaking anything downstream, and that requires the scaffolding to carry the change.

Defence lives outside the prompt. Module 8 is the module people try to solve with more instructions and end up solving with better tools. The pattern is broader: "the model refused to comply" is not a guarantee, "the code refused to comply" is. Every consequential constraint — spending limits, PII redaction, human approval — belongs in the surrounding code, not in the prompt text.

The final exam

The exam has 40 questions covering all ten modules: what a naive prompt is missing and how to diagnose it, when and how to separate system framing from user input, choosing between zero-shot, one-shot and few-shot and the recency-bias trap, deciding when chain of thought actually helps, moving from parseable JSON to schema-constrained JSON and handling unknown values, replacing vague adjectives with measurable constraints, avoiding literal translation and the specific English traps, defending against direct and indirect injection with delimiters and least-privilege tools, building a fifty-example test set with per-field metrics and A/B comparison, and turning working prompts into a versioned reviewed library.

Several questions present situations to diagnose: a prompt that works on the demo email and fails on the twentieth, a schema that parses but returns fabricated product names, a chain-of-thought change that lifts one field and drops another, a system message that a user message still overrides, a nightly job that suddenly issues large refunds after a customer includes a URL in a support ticket. Judgement is what gets assessed, not memorised template syntax.

On success, your certificate of completion is issued immediately; its number can be verified by any third party on the platform.

Checklist before shipping a prompt to production

• The prompt has all four compartments filled: task, context, constraints, format.
• Stable framing lives in system, per-call input in user.
• Examples are drawn from a held-out pool, not from the eval set.
• Chain of thought is present only if it beat the direct variant on the eval set.
• Output is schema-constrained, with Optional and "unknown" wherever absence is meaningful.
• Style constraints are checkable in a unit test.
• The prompt is written in the language of the answer, with today's date and a dialect explicitly chosen.
• Inputs are wrapped in delimiters that the input cannot forge.
• Tools called by the model have server-side limits and logs.
• A test set of at least fifty examples, per-field scored, is part of continuous integration.
• The prompt has a semantic version, a change log with numbers, and a documented owner.

Before you start

Take the table above and, row by row, ask yourself "what would I see in production if I got this wrong?". If you can name a symptom for each — silent JSON parse errors, drifted urgency, higher refund count on new content, per-field regression after a model upgrade — you are ready. Good luck!

Final exam

Ready to validate this course?

40 questions drawn at random from the course bank · passing score 70% · verifiable PDF certificate issued immediately on success.

Start the exam

You need to be signed in to your InSkillML account with an active subscription. You can also start the exam from My courses.