A system prompt is the standing instruction your application sends with every request — the model's job description. Teams that would never push code to production without a pull request routinely edit prompts in a dashboard textbox and hit save. Then, weeks later, nobody can explain why the assistant started phrasing refund policies differently on the 14th. The fix is cultural more than technical: prompts are code, and they go through the code path.
Store prompts in version control
Keep system prompts as files in the same repository as the application that uses them (or a dedicated prompts repo if several services share them). This gives you, for free, everything an auditor or incident responder will eventually ask for: who changed what, when, and why — with the commit message as the "why." Avoid prompts that live only in an environment variable, a database row, or someone's notebook. If the prompt is assembled at runtime from fragments, version the fragments and the assembly logic together, and log the assembled result's version identifier with each request.
Version the prompt and the model together
Production behavior is a function of the pair (prompt version, model version) — reviewing one without the other explains nothing. Helpfully, every Claude model ID is a pinned snapshot: even the dateless IDs used from the 4.6 generation onward (such as claude-opus-4-8) name a fixed snapshot, not an evergreen pointer that changes underneath you. Pre-4.6 aliases like claude-haiku-4-5 are convenience pointers that resolve to dated IDs (claude-haiku-4-5-20251001), so for older models record the resolved dated form. Your deployment record for any given day should let you state: "requests ran prompt v14 against claude-opus-4-8."
Require change review
Prompt diffs should go through the same pull-request review as code, but reviewers look for different things:
- Behavioral intent: what user-visible change is this edit supposed to make, and is that stated in the PR?
- Scope creep: does the edit quietly relax a restriction added earlier for a reason (tone rules, disclaimers, topics to refuse)?
- Evidence: has the new version been run against your evaluation set, with results linked? See documenting your AI evaluation results.
- Injection surface: does the change interpolate any new untrusted content into the prompt? See prompt injection 101.
For consequential applications, require a second reviewer from outside the authoring team — the same logic as approval gates elsewhere in your governance program.
Deployment mechanics worth knowing
Two operational details affect how you roll prompts out on Claude platforms. First, prompt caching: a changed prompt prefix means the first requests after deploy write a fresh cache at the cache-write rate (1.25x base input price for the 5-minute duration, 2x for 1-hour) before cheap cache reads resume — a brief, expected cost bump, not a bug. Changing the model string likewise invalidates the existing cache. Second, isolation: prompt caches are isolated per workspace on the Claude API, Claude Platform on AWS, and Microsoft Foundry (per organization on Bedrock and Google Cloud), and workspaces are a clean way to separate dev, staging, and production prompt configurations under one org — see the workspace docs below.
Maintain real rollback
Rollback means the previous version is one deploy away, not one archaeology session away. Practical checklist: the prompt version identifier appears in your request logs and decision audit trail; old versions remain in the repo history and are re-deployable without edits; and you rehearse a rollback at least once before you need one. When an incident review asks "what was the model instructed to do at 09:12 on Tuesday," the answer should be a git tag, not a guess.
Where to go next
Version control tells you what changed; evaluation documentation tells you whether the change was safe. Together they feed prompt log management and the broader production checklist.