← Use cases · Review

Prompt-engineering teams landing changes via PR

Prompt engineers want their changes to go through the same review flow as code — legible diffs, approvals, and an audit trail.

The problem

Prompt-engineering work often happens in a separate tool or a scratch file, then gets pasted into the codebase. The change that ships is disconnected from any review, and there is no record of who approved what or why.

With blogus

With prompts as .prompt files, a prompt change is an ordinary diff: frontmatter and template body, reviewable line by line. The lock records the commit each prompt was cut from, giving every change a git-native audit trail.

How it flows

01
version
Each prompt is a .prompt file with typed variables and a pinned model.
02
PR
Prompt edits show up as normal diffs a reviewer can approve.
03
lock
blogus lock updates the hash and records the commit for the audit trail.
04
analyze / test
Optional spot-checks (blogus analyze, blogus test) before the change lands.

What you get

✓Prompt changes get real review, not rubber-stamping
✓Pinned model id and temperature prevent silent behaviour shifts
✓Every change is traceable to a commit and an approver

Try it on your repo

Run uvx blogus scan today, or follow the quickstart.