Heidelberg AI Curriculum

21books at this level

Build the Smallest Thing Your Colleagues Can Run Without You

Choose between chat, a saved prompt, an automation, a small app and an agent for a job colleagues depend on. Pick the lowest rung that meets a named requirement, then give it a known-answer test, a README, a pinned version, a maintainer and a deputy, and prove a colleague can run it.

Outcome: A working build for one recurring job (a saved prompt, form, automation or app) with a one-page README, a known-answer test with expected results and a decision paragraph naming two rejected options and a trigger; it passes when your deputy runs the test and one real job from the README alone, without asking you.

Builder19 minLast edited: Sep 23, 2026

T02-L0302

Build a Shared Assistant Your Team Can Test and Take Over

Turn one recurring team question into a shared assistant: current sources only, pinned instructions and model, use and edit rights kept apart, and a test set that runs before every change goes live. It passes when your deputy updates a source, reruns the tests and publishes without you.

Outcome: A shared assistant for one recurring team job, with a usage note, a test set of at least ten known-answer questions and a change log; it passes when your deputy replaces one source, reruns the test set, publishes the new version and a colleague gets the updated answer, all without your help.

Builder18 minLast edited: Sep 23, 2026

T03-L0303

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

T04-L0304

Test and Fix the Document Assistant Your Group Relies On

When colleagues act on a shared document assistant, you need to know it finds the right passage. Write test questions with known answers, tell a search miss from a bad answer or a bad question, change one thing at a time, and leave a check and a README a colleague can rerun.

Outcome: A test folder for your group's document assistant (test questions with expected passages and answers, the settings record, a before-and-after result for one change, and a README), which passes when a colleague adds or changes one document, reruns the check from the README alone, and gets PASS or explains every failure.

Builder22 minLast edited: Sep 23, 2026

T05-L0305

Chain Checked Steps Into a Weekly Digest Your Team Can Rerun

Turn one checked model step into an n8n pipeline that writes the team's weekly digest: a gate for empty and oversized weeks, one checked record per item, counts done by code, a summary that may only cite checked records, a test set with expected results, and a README a colleague can rerun.

Outcome: A published n8n pipeline that produces a weekly digest draft for a named reviewer, with a test data table of six to eight cases and their expected end states, the model ID and workflow version in a README, and a note naming maintainer and deputy; it passes when the deputy runs the test set from the README alone and every case ends where the table says.

Builder21 minLast edited: Oct 18, 2026

T06-L0306

Turn Your Team App Into One Colleagues Can Depend On

Take the Base44 app from T06-L02 · Build a Small Shared Tool From a Prompt, and Test It With a Colleague to where colleagues can depend on it: two roles the data enforces, clear empty and error screens, a test copy with known answers, an operating note with a maintainer and deputy, and a line where IT takes over.

Outcome: A published Base44 app with two roles, a test copy with known-answer records, a one-page test sheet and an operating note; it passes when a colleague who didn't build it runs the whole test sheet through the testing link and every line matches, and the deputy publishes one small change without your help.

Builder20 minLast edited: Sep 23, 2026

T07-L0307

Build a Small Agent Your Colleagues Can Run, Test and Stop

Package a small agent that drafts, and never sends: instructions in a file, tool permissions the software enforces, a turn and spend limit, a test set of requests with known answers, a check script and a README. Decide first whether the job needs an agent at all, and stop where real credentials begin.

Outcome: An agent folder (instructions, permissions file, reference files, test cases with expected results, check script, README naming maintainer and deputy) that a colleague clones and runs; it passes when their check run prints PASS, nothing outside the output folder changed, and they produce one real draft from the README without asking you.

Builder20 minLast edited: Oct 18, 2026

T08-L0308

Write the Spec First, So an AI Assistant Can Change Code Your Team Depends On

Change a script several colleagues depend on without breaking it: write a one-page spec with numbered rules and known-answer tests before any code, let OpenCode plan and build against it, review the diff rule by rule, and have a colleague rerun every test before you release the new version.

Outcome: A repository with SPEC.md, known-answer tests, the changed script, CHANGES.md and a version tag; it passes when a colleague, on their own computer and using only the README, runs the tests and all pass, and can point to the rule in SPEC.md behind every changed block of code.

Builder29 minLast edited: Oct 18, 2026

T09-L0309

Build a Caption Pipeline Your Team Can Rerun Every Week

Turn weekly recordings into reviewed captions without one person clicking through them: a small script that drafts captions with a pinned model and your glossary, a test set with known transcripts, a named reviewer for every item, and a README a deputy can follow. It passes when the deputy runs a week without you.

Outcome: A pipeline folder (script, settings, glossary, manifest, test recordings with known transcripts, check script, README) plus one week of reviewed captions; it passes when the deputy runs the check and one week's recordings on their own computer from the README alone, the check passes, and every published caption file has a named reviewer.

Builder20 minLast edited: Oct 12, 2026

T10-L0310

Build an Analysis Your Colleague Can Rerun and Get the Same Numbers

Turn a monthly analysis into a pipeline anyone in the group can rerun: a script, settings per run, a pinned Python environment, a fingerprint for every input, recorded analyst decisions, a sample with hand-checked answers and a README. Done when a colleague reruns it on a fresh copy and gets your numbers.

Outcome: A Git repository with the analysis script, settings per month, a lockfile, a sample with a hand-checked expected summary, a check script and a README; it passes when a colleague clones it on their own computer, the check prints PASS, and their rerun of one real month gives a summary identical to yours.

Builder20 minLast edited: Sep 23, 2026

T11-L0311

Local AI Apps Your Colleagues Can Rely On

Run local AI apps with Heidelberg AI Desk so colleagues can depend on the result: install Desk and let it set up Podman, read what an app needs before it changes anything, find where its data lives, back it up, restore it on a second computer, update it safely, and know when a laptop is no longer enough.

Outcome: A one-page run note for one app (what it produces, who reads it, how to start, stop, back up and restore it, and what happens when it fails), plus a restore of your latest backup on a second computer; it passes when a colleague follows the note without your help and the restored app shows your real data.

Builder24 minLast edited: Oct 12, 2026

T12-L0312

Give an Unattended Workflow Limits and a Stop a Colleague Can Use

Before an n8n workflow runs without you, write its one-page operating rule and make the build obey it: a credential that can't do what the rule forbids, hard limits on items, time and model spend, a test set with known answers, and a deputy who can stop it without you.

Outcome: A published n8n workflow with its one-page operating rule and a filled-in test sheet for the five tests. It passes when all five tests pass, the credential can't perform any action the rule forbids, and the deputy stops the workflow from the rule alone while you watch without helping.

Builder22 minLast edited: Sep 23, 2026

T13-L0313

Write a One-Page AI Rule Your Team Can Use Without Asking You

Write your team's AI working rule on one page: the approved route, green, yellow and red examples from your own work, the output check, who decides edge cases and what to do after a mistake. Test it with eight cards that have known answers, and hand it to a colleague who can keep it running.

Outcome: A one-page AI working rule, approved by the person accountable for the team, with its eight test cards and the results of three colleagues who didn't write it. It passes when every red card is stopped, each tester gets at least seven of eight right, the edge-case question gets an answer from the named person or deputy, and the deputy runs the card test with someone new without you.

Builder18 minLast edited: Sep 23, 2026

T14-L0314

Turn a Connector Brief Into a Routine Colleagues Can Rerun

Make a connector-based brief repeatable: saved instructions with a fixed scope and changing inputs, read-only tools, a test week with known answers, a check that each colleague's run reads the same files, a README and a fallback. The routine reads as whoever runs it, so you test it with each of them.

Outcome: A saved routine (instructions, scope, inputs, output format), a test sheet with a fixed test week and four more cases with expected results, each colleague's run of the test week, and a README with maintainer, deputy and manual fallback; it passes when a colleague runs the routine from the README under their own account, their test-week file list matches yours or every difference is explained, and they produce the week's brief without asking you.

Builder18 minLast edited: Sep 23, 2026

T15-L0315

Get an AI Step on Participant Data Reviewed, Then Build It Inside the Approval

Before an AI step touches participant data, map where the data goes, compare it with what was approved, and ask the people who decide. Then build the step to fit the answer: minimised input, a local model, a test on hand-coded items, a README, and a colleague who can rerun it and knows when to stop.

Outcome: One review request with its data-flow map and the reviewers' answer, plus the working AI step: README, run record, the hand-coded test set and a colleague's rerun. It passes when no real data went anywhere before the answer, the test result meets the threshold you wrote down in advance, and the colleague reruns the step from the README and gets the same labels.

Builder18 minLast edited: Oct 12, 2026

T16-L0316

Test a Tool on Your Own Work Before Your Team Depends on It

Before colleagues rely on an AI tool's output, test it on 15 to 20 past cases whose right answers you already know. Write the scoring rule first, count first-pass results, repairs and critical failures, and leave a decision with a routing rule, a fallback and a case pack a colleague can rerun.

Outcome: An evaluation pack for one tool and one recurring job: the workload card, a case pack of at least 15 cases with known answers, the scoring rule, the results, and a one-page decision with a routing rule, a fallback and re-test triggers; it passes when a colleague reruns two cases and the fallback from the pack alone and reaches the same scores.

Builder17 minLast edited: Sep 23, 2026

T17-L0317

Explore What Already Exists Before You Build

Before you build something colleagues will depend on, scan how the job is done today, what products, papers and examples exist, and what you can reuse. Use an AI research mode for the scan, check its claims against real sources, run one small experiment and rewrite the problem.

Outcome: A two-page exploration note with how it's done today, what exists, a checked source for every claim, one experiment and a revised problem statement, which passes when a colleague can open every source and find the claim it supports, and the two people who signed the original statement accept the revision.

Builder18 minLast edited: Sep 23, 2026

T18-L0318

Build a Cell-Counting Pipeline Your Group Can Rerun and Check

Turn a manual Cellpose count into a small pipeline your group can rerun: a script written with an AI coding assistant, settings in one file, a pinned software version and model file, a sample dataset with known-good counts, a one-command check and a README. It passes when a colleague reruns it and gets your counts.

Outcome: A pipeline folder (script, settings file, pinned requirements, sample images, expected counts, check script, README) that a colleague sets up and runs on their own computer from the README alone; it passes when their check prints PASS, or any difference is explained and written into the README.

Builder17 minLast edited: Sep 23, 2026

T19-L0319

Propose, Review and Merge Changes With Pull Requests

Protect main so nothing reaches it unread, record a problem as an issue, propose the fix as a pull request, review it line by line, and merge it so the issue closes by itself.

Outcome: A protected main, an issue and a merged pull request that fixes it, with at least one line comment, one Request changes, a new commit answering it and an Approve; the merge closed the issue, and a direct push to main is refused.

Builder15 minLast edited: Sep 25, 2026

T20-L0320

Run a Harness on a Model You Control: Local Server or Team Gateway

Connect OpenCode and DeepSeek Harness to a local model server or a team gateway, set the four values that must match, and test whether a model can act as an agent before colleagues rely on it.

Outcome: A half-page set-up guide: approved model and where it runs, the four values per harness, the practice task result (2.000) per harness, and one provoked failure with how each harness reported it.

Builder14 minLast edited: Oct 18, 2026

T21-L0321

Share Skills and Connections With Your Team, and Decide Who Gets What

Move a tested skill from copied folders into one shared library in OpenWork Cloud. Set up an organisation with teams and roles, publish the skill to a team, add a connector where each person signs in as themselves, change the skill safely, and prove that removing someone takes their access away.

Outcome: A one-page library sheet: each shared skill and connector with who can use it, who can change it, how people sign in and what the agent can do through it; where the service runs and who agreed to that; one change made by copy, test and replace, with its date; and the result of removing one colleague's access. It passes when a second colleague ran the shared skill without help, and the skill was gone from the removed colleague's Library after a refresh.

Builder19 minLast edited: Oct 12, 2026