Versioning Prompts — Git, Not Strings

~14 min · production, versioning

Level 0Apprentice

0 XP0/100 lessons0/14 achievements

0/120 XP to next level120 XP to go0% complete

Prompts are software; treat them like it

If a prompt is a string in a database row, a Notion page, or an inline literal in code, you've given up the basic engineering tools: diff, review, rollback. The 2026 baseline is prompts in source control with semantic versioning, frontmatter metadata, and a version key that production reads.

Versioning shape

One file per prompt, named <name>/v<n>.md or <name>@<n>.prompt.
Frontmatter: id, version, model, owner, last-eval-pass-date, input/output schemas.
Production reads by versioned key, not by filename glob.
A bumped version = a new file; old versions stay reachable for rollback.

What this enables

Diff in PRs.
Reviewers see the change in context.
Rollback is instant — flip the version key.
A/B testing is just "this user gets v_new, that user gets v_old."

Code

Prompt with frontmatter·markdown

---
id: support.draft_reply
version: 8
model: claude-opus-4-7
owner: customer-experience
input_schema: schemas/support_input.json
output_schema: schemas/support_output.json
last_eval_pass: 2026-04-30
changelog: tightened refusal language for out-of-scope pricing
---

You are a support agent for ACME...

{{user_message}}

External links

Exercise

Move one production prompt out of an inline string literal into a versioned file with frontmatter. Production reads it by version key. Verify rollback works.

Progress

Progress is local-only — sign in to sync across devices.

← 🔀 Across Providers Without Losing IntentQuiz · 4 questions Next →Caching Strategies — What's Worth Caching

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.