Glossary
The vocabulary of prompt locking
The terms that show up across the docs, in one place. If you know package lockfiles, most of this will feel familiar.
- .prompt file
- A single versioned prompt: YAML frontmatter (name, model.id, model.temperature, variables) followed by a Jinja-style template body. The reviewable unit that shows up in a diff.
- prompts.lock
- The lockfile. One entry per prompt, each recording a sha256 over the template content and the git commit it was generated from. Analogous to package-lock.json or Pipfile.lock.
- Content hash
- A sha256 computed over a .prompt file’s template content. blogus verify recomputes it on disk and compares against the lock to detect any change.
- Marker comment
- A comment of the form # @blogus:name sha256:a1b2c3d4 that blogus fix inserts above a load_prompt() call. It ties a specific call site to a specific prompt and hash.
- load_prompt()
- The runtime call blogus fix introduces in place of an inline string. It loads the prompt from its versioned .prompt file and interpolates variables.
- Prompt drift
- When the prompt actually running diverges from the one that was reviewed — via co-located edits, copy-paste forks, silent SDK upgrades, or evaluation drift. The problem blogus exists to close.
- Unversioned prompt
- An LLM prompt still living as an inline string in code, not yet promoted to a .prompt file. blogus scan flags these; blogus check finds ones that slipped through.
- verify gate
- blogus verify used as a required CI or pre-commit check. It exits non-zero when the code markers, .prompt files, and prompts.lock disagree — no model calls, no secrets.
- Build-time tool
- Software that runs during development and CI rather than in the production request path. blogus is build-time: it never sits between your app and the model.
- Variable
- A named placeholder in a .prompt template, declared in frontmatter. Variables can be marked required or given a default, and are supplied at load_prompt() time.