blogus

Overview

blogus starts from a mundane observation with expensive consequences: the prompt that ships is frequently not the prompt that was reviewed. Prompts live inline at call sites, get adjusted during debugging, and reach production without a diff anyone looked at. Every discipline that version control was invented to impose on source code is absent from an artefact that directly determines what the system says.

The mechanism is deliberately boring. blogus extracts prompts out of a codebase into standalone .prompt files, computes a sha256 over each, and records the hashes in a prompts.lock file — the same arrangement package lockfiles use, applied to a different kind of dependency. A continuous integration job can then assert that the lockfile matches the working tree, which turns an unreviewed prompt edit from an invisible event into a failed build.

It is a build-time tool and that boundary is deliberate. blogus does not sit in the request path, does not proxy model calls, and does not collect production traces. Those are useful things and they are somebody else's job; a tool that did all four would have to run as a service, and a service is a much larger thing to ask a team to adopt in order to get a hash comparison.

Where it loses: if what you want is a hosted prompt registry with a web editor, an approval workflow and non-engineer access, blogus is the wrong shape entirely — it assumes the prompt lives in the repository and the repository is the source of truth. It also does nothing to tell you whether a prompt is good. A locked prompt is a reviewed prompt, not a correct one.

The open question is granularity. A prompt assembled at runtime from several fragments has no single stable hash, and the choice between pinning the fragments and pinning the rendered result changes what the lockfile actually guarantees. We currently pin fragments, which is the conservative answer and not obviously the right one.

Adoption is usually incremental and that is by design. Extraction can run over one module rather than a whole repository, the lockfile can be advisory before it is enforcing, and a team can stop at extraction without ever turning on the continuous-integration gate. A governance tool that demands a big-bang migration does not get adopted, and prompt governance is not urgent enough to survive one.

The adjacent project in the portfolio is promptel, which concerns how a prompt is written rather than how it is tracked. Between them they cover specification and lifecycle, which are the two halves of treating a prompt as an engineering artefact. Neither addresses optimisation — improving the wording against a metric — and that boundary is stated on each project rather than quietly implied.