Gera Tools

Changelog Writing Prompt Builder

Build prompts that turn git commits into clear changelogs for users

Paste git commit messages or PR titles and instantly generate an AI prompt that groups changes by type, translates technical language into user benefits, and formats the result by semantic version. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What commit formats does it understand?

It works best with conventional commits (feat, fix, perf, refactor, chore, docs). The prompt tells the model how to map each prefix to a changelog heading, but plain messages work too.

Turn commit noise into a changelog people actually read

A raw git log is written for machines and the engineer who wrote it — not for the people reading your release notes. This builder takes your commit messages or PR titles and produces a carefully structured prompt that an LLM can turn into a clean, grouped, benefit-focused changelog. Paste, configure, copy.

How it works

The tool parses each line you paste and embeds it in a prompt template with explicit instructions for the model: map conventional-commit prefixes to changelog headings (feat → Added, fix → Fixed, perf → Performance), drop non-user-facing noise like chore and ci, and rewrite every kept entry as a single benefit-led sentence. The prompt also pins the output to semantic versioning: breaking changes are pulled to the top, and the version heading and ISO date are formatted for you.

Choosing end-user vs technical audience swaps one instruction block. For users, the model translates jargon into outcomes (“faster load on slow connections”); for developers, it keeps the precise technical detail intact.

How conventional commit prefixes map to changelog sections

The prompt instructs the model to apply this mapping automatically, so you do not have to sort commits yourself:

Commit prefixChangelog headingKept or dropped?
feat:AddedKept — new capability
fix:FixedKept — user-visible bug fix
perf:PerformanceKept — measurable speed improvement
refactor:(dropped)Usually dropped — internal only
docs:DocumentationKept if user-facing docs changed
chore:(dropped)Dropped — maintenance, not user impact
ci:(dropped)Dropped — build pipeline, not user impact
BREAKING CHANGEBreaking ChangesPulled to the top of the section

The BREAKING CHANGE footer token (or ! in the commit type) is treated specially — those entries always appear in a bold section at the top of the release block, before the additions and fixes, because they are the most important thing users need to know.

A before-and-after example

Input commit:

fix(auth): prevent token refresh from failing when user has multiple active sessions

End-user changelog output (for example):

Fixed an issue where signing in on multiple devices could occasionally cause unexpected sign-outs.

Technical changelog output (for example):

Fixed token refresh race condition when multiple sessions are active for the same user (auth module).

The underlying prompt instruction is what drives this translation — it tells the model to reframe fix entries as user impact, not implementation detail.

Tips for better changelogs

  • Write conventional commits in the first place — feat:, fix:, perf: give the model unambiguous grouping signals.
  • Squash trivial commits before pasting; one line per meaningful change keeps the changelog tight.
  • Keep a ## Unreleased section in your repo and run this builder each release to clear it.
  • If the model invents a feature, tighten the source commit message — the prompt already forbids inventing anything not implied by a commit.