A prompt is production behaviour
The prompt determines what your feature does, in the same way the code does. Storing it somewhere without version control, review, or history means a single text edit can change customer-facing behaviour with no record of who did it or why.
The failure it causes
Something changes, quality drops, and nobody can say what was different. Without history there is no diff to inspect and no version to revert to — the investigation becomes an argument about recollection.
If you can’t diff it, you can’t debug it.
What versioning gives you
Review before a change reaches customers, a history explaining why each instruction exists, the ability to roll back, and the ability to run your evaluation set against a proposed change before it ships rather than after.
Record which version produced which output
Log the prompt version alongside every interaction. When you need to explain what a system said to a customer months later, knowing the exact instructions in force at that moment is the difference between an answer and a guess.
Delete as well as add
Prompts accumulate corrections and nothing is ever removed, which is a main cause of features getting slower and more expensive after launch. Version control makes removal safe: you can take an instruction out, re-run the eval, and put it back if the numbers move.
Non-engineers still need to edit
The people who know what a good answer looks like are usually not the people comfortable with a pull request. Solve that with a review workflow rather than by moving the prompt out of version control — the constraint is auditability, not who is allowed to write.