PromptOps

WHAT IT IS PromptOps is the practice of managing prompts the way any other production artifact is managed: stored in version control or a registry rather than pasted into code, changed through review, evaluated against a fixed regression set before release, rolled out in a way that can be reversed, and attributable to whoever changed them. **Not this:** PromptOps is not LLMOps: it is the narrower practice of managing prompts as reviewed, evaluated, reversible artifacts, not the operation of the surrounding application and its providers. WHY IT EXISTS A prompt is code with none of code's safety net. Editing one word changes system behaviour for every user, no compiler objects, no type checks, and the effect is often visible only in aggregate across many outputs. Teams routinely ship prompt changes through a path that would never be accepted for a database migration — directly, unreviewed, untested, and untracked. PromptOps exists to close that gap without pretending a prompt is a deterministic function. WHEN TO USE IT Adopt it as soon as a prompt is in a production path and more than one person can edit it. The trigger is shared ownership: the first time someone asks "why did the output change?" and nobody can say what was altered, the practice has already become overdue. WHO OWNS IT The engineering team shipping the feature owns the prompt registry and the release path. Whoever owns the feature's quality — often a product manager or domain expert — owns the evaluation set, because deciding what a good output looks like is a domain judgment, not an engineering one. Subject-matter reviewers own approval for prompts in regulated or high-consequence contexts. WHAT GOOD LOOKS LIKE Every production prompt has a version, an owner and a change history you can read. Changes go through review by someone other than the author. A fixed regression set of representative inputs runs against a candidate prompt and the result is compared with the incumbent before release, so a change that improves one case and breaks five is caught. Rollout is staged or flagged, and reverting is fast and routine. Which prompt version produced a given output is recorded, so a complaint can be traced to a change. HOW TO IMPLEMENT Get prompts out of inline string literals and into a registry with versions — this single step makes every later practice possible. Add authorship and review to the change path, reusing your existing code-review mechanics rather than inventing a parallel process; the versioning discipline in /gitops applies unchanged. Build the regression set from real inputs, including the cases that have already caused complaints, and keep it small enough to actually run. Compare candidate against incumbent rather than against an absolute score, because absolute quality scores drift and relative comparisons stay meaningful. Add version stamping to outputs last, and you gain traceability for support. HOW TO ASSESS YOURSELF Ask who changed the production prompt most recently and what it did to output quality. Ask whether a prompt change could reach users without a second person seeing it. Ask how long a rollback takes. Take the scored self-assessment at /assess, then sequence the findings with /roadmaps; the review checklists at /checklists cover the recurring evaluation pass.