Skip to main content
// ple

// blog / template

A prompt changelog template you can copy

A diff shows what you changed. Three months later you also need to know why, and whether it worked. This template keeps those two answers.

The template

One entry per behavior-changing edit, newest first.

CHANGELOG.md
## <prompt name> v<N> — <YYYY-MM-DD>

- **Changed:** <one line: the edit, in words>
- **Why:** <what was going wrong, in the output you saw>
- **Model:** <model and settings it was run against>
- **Result:** <better / worse / same / not measured, plus how you checked>
- **Rollback to:** v<N-1>

A filled-in example (illustrative)

CHANGELOG.md
## code-review v3 — 2026-10-16

- **Changed:** Added "Say 'no findings' if clean."
- **Why:** On clean diffs the reviewer invented minor issues to have something to say.
- **Model:** the same model and settings as v2.
- **Result:** Not measured. Ran on 5 clean diffs: 4 now answer "no findings".
- **Rollback to:** v2

## code-review v2 — 2026-10-15

- **Changed:** "not style" became "bugs only", and each finding must quote its line.
- **Why:** Reviews said "consider error handling" with no location.
- **Model:** the same model and settings as v1.
- **Result:** Better on the 3 diffs I checked; findings now point at a line.
- **Rollback to:** v1

Note what the Result lines claim: how many inputs, and what was observed. "Better" with nothing behind it is the entry you will not trust later.

Where to keep it

  • In the repo, beside the prompts. The edit and its entry go in one commit. See how to version prompts in git.
  • With saved versions. A tool stores the text of every version, so the changelog only needs the reasons. With the ple CLI, ple log "code review" lists the versions and ple diff "code review" 2 3 shows each change, so an entry can point at a version number instead of pasting the text.

The wider idea is in prompt version control, and the "Result" line is where testing a variant with your own agent pays off.

FAQ

What should a prompt changelog contain?

The version, the date, what changed, why it changed, the model and settings it ran against, and what happened afterwards. The why and the result are the parts that are lost first.

Where should I keep it?

Next to the prompts, in the same repository, so a change to a prompt and its entry can be reviewed in one commit. If you use a prompt library with history, keep the entry in the commit message or in a file in the repository.

Is a changelog different from version history?

Yes. Version history stores the text of every revision, so it can tell you what changed. A changelog records why, and whether it worked, which a diff cannot.

How is this different from a git commit message?

A commit message is a good home for the same fields. A separate changelog file is easier to read in one place, and works if your prompts are not all in one repository.

Do I need an entry for every small edit?

No. Write an entry when the behavior should change: a new instruction, a removed constraint, a new variable, or a new model. Typo fixes can skip it.

Try it before you sign up

Keep the versions in one place and the reasons in your changelog. Try saving, diffing and rolling back a prompt in your browser, with no account.