Course resource
Prompt Version Control Guide
Prompts running in production are code. Treat them accordingly, or you will have a workflow that used to work and nobody knows what changed.
Why this matters
A prompt buried inside an automation step has all the properties of untracked code: no history, no review, no way to roll back, and no way to tell whether last Tuesday's quality drop came from your edit or the provider's model update.
The minimum viable system
You do not need a repository and a CI pipeline. You need four things.
1. Prompts live in one place, not inside workflow steps.
Keep a single document or file per prompt. The workflow references it, or you paste it in and record which version you pasted.
2. Every prompt has a header.
PROMPT: support-ticket-classifier
VERSION: 4
UPDATED: 2026-09-01
OWNER: [NAME]
USED BY: [WHICH WORKFLOW, WHICH STEP]
MODEL: [WHICH MODEL AND TEMPERATURE]
CHANGELOG
v4 2026-09-01 Added "other" category — v3 forced everything into four
buckets and misclassified ~8% of tickets
v3 2026-07-14 Constrained output to a single word, no punctuation
v2 2026-06-02 Lowered temperature to 0.1, routing was non-deterministic
v1 2026-05-20 Initial
The changelog is the valuable part. Six months later, "why is there an 'other' category?" has an answer.
3. A test set per prompt.
Ten to twenty real inputs with the correct output. Run them before and after any change.
| # | Input | Expected | v3 | v4 |
|---|---|---|---|---|
| 1 | ✓ | ✓ | ||
| 2 | ✗ | ✓ |
Twenty minutes to build, and it converts "I think this is better" into "this fixed 3 and broke none".
4. Never edit a live prompt directly.
Copy, edit the copy, test the copy, then swap. Editing in place means no rollback when the change turns out to be worse.
What to record with each version
| Field | Why |
|---|---|
| Version number | So a workflow can say which it runs |
| Date | To correlate with quality changes |
| Model and temperature | A prompt tuned on one model may fail on another |
| What changed and why | The reason is what you need later, not the diff |
| Test results | Evidence it was an improvement |
Model changes
Providers update models under the same name. Your prompt did not change; its behaviour did.
- Pin a specific model version where the platform allows it
- Re-run your test set monthly, even with no changes
- Log the date of any observed quality change
- When a provider announces a deprecation, re-test before the forced migration, not after
When output quality drops with no change on your side, check the model version before rewriting the prompt.
Reviewing a prompt change
For anything customer-facing, a second person should look at it. The questions:
- What problem does this solve? Is there evidence of that problem?
- Does the test set improve, and does anything regress?
- Could this change make the output worse in a case not in the test set?
- Does it still constrain the output format the downstream step expects?
- Is the escape hatch still there — what it does when it does not know?
Rollback
Know how before you need it.
ROLLBACK: support-ticket-classifier
Previous good version: v3
Where it is stored: [LOCATION]
How to swap: [STEPS]
Time to roll back: [MINUTES]
Who can do it: [WHO]
Where to keep all this
| If you are | Use |
|---|---|
| One person | A single document per prompt, in your notes tool |
| A small team | A shared folder, one file per prompt, with the header above |
| Engineering-adjacent | Git — plain text files, real diffs, real review |
| Running many prompts at scale | A prompt-management platform |
Start with the simplest that fits. A well-maintained folder beats an abandoned platform.
Your prompt register
| Prompt | Version | Used by | Owner | Last tested |
|---|---|---|---|---|
The habit that matters most
When you change a prompt because something went wrong, write down what went wrong. Not what you changed — what broke. That one sentence is worth more than the diff, and it is the thing nobody records.