Heidelberg AI Curriculum

5books in this track

L01 · User

Who is affectedOnly you

Write a Prompt You Can Reuse

Write a prompt with a role, a task, constraints and an example, test it on five real inputs, improve it one change at a time, and tell an unclear instruction from missing information, so a weekly task gives the same clean result every time.

Outcome: One saved prompt improved across three revisions on the same five inputs, with a one-line note per revision, which passes when a colleague can see what each change did and every missing field reads "not stated" instead of a guess.

User13 minLast edited: Sep 23, 2026

L02 · Power user

Who is affectedYour team sees a bad document or a wrong figure

T03-L02

Build a Context Packet Your Team Can Rerun

Most bad answers come from missing or wrong sources, not from weak wording. Keep the prompt fixed, change only the sources, and see which document the answer really needed. Then package the question, the labelled sources and their exact wording so a colleague gets the same answer without your chat history.

Outcome: A context packet for one real team question: the fixed prompt, the question, the labelled sources with versions and the exact quotes the answer rests on, plus a before and after run showing which source made the difference. It passes when a colleague reruns the packet in a fresh chat and gets the same answer with the same quotes.

Power user15 minLast edited: Sep 23, 2026

L03 · Builder

Who is affectedColleagues depend on something you built

T03-L03

Put a Test Set Under the Prompt Your Team Depends On

A prompt colleagues rely on needs tests before anyone changes it, or swaps the model under it. Write down what the output must be, collect 15 cases with known answers, run them in Promptfoo, change one thing at a time, and leave a folder a colleague can rerun with one command.

Outcome: A test folder for one shared prompt: the contract, at least 15 cases with known answers, the Promptfoo configuration with pinned versions, the before-and-after results and a README; it passes when a colleague reruns it from the README alone and gets the same pass or fail on every case.

Builder18 minLast edited: Sep 23, 2026

L04 · Integrator

Who is affectedCompany or lab systems and real data are in the loop

T03-L04

Release Prompt Changes Through Review, Tests and a Way Back

When a prompt feeds a real database or a real inbox, every change is a release. Put the prompt and its tests in a repository on your code server, let every change pass an automatic test run and a named reviewer, release by tag, and roll back in minutes.

Outcome: A prompt repository with one released change: the pull request with its automatic test run and approval, the release tag recorded in production outputs, and a rehearsed rollback. It passes when a colleague rolls production back to the previous tag from the README alone in under ten minutes, and IT has confirmed the access list in writing.

Integrator22 minLast edited: Sep 23, 2026

L05 · Operator

Who is affectedWork stops when it breaks, and it must survive you leaving

T03-L05

Keep a Production Prompt Healthy for Months, and Hand It Over

A prompt many people depend on drifts: new kinds of input, a model swap, a failure nobody saw. Grow a regression set from real failures, gate every change on a rule written in advance, watch three signals, handle incidents, and hand it all to a substitute who has run it.

Outcome: An operations folder for one production prompt: the regression set with its critical group and pass rule, the gate results for one change, a monitoring page with three signals and named responders, and one incident or drill note. It passes when the substitute reproduces the gate decision and a rollback from the runbook alone, and a colleague answers three auditor questions from the folder.

Operator21 minLast edited: Sep 23, 2026