Should I use conventional commits?

Yes, for auto-categorisation. But translate them into user voice before publishing; "feat: add OAuth" is not a customer-facing line.

How often should I publish a changelog?

Match your release cadence. Weekly suits SaaS; per-release suits OSS.

Should I list every bug fix?

Only ones users noticed. Internal bugs go in the collapsed "Internal" section.

What about security fixes?

List them briefly, with a CVE link if applicable. No exploit details until the patch is widely deployed.

Do I need a changelog if I have GitHub release notes?

A `CHANGELOG.md` in the repo is still useful: searchable, reviewable in PRs, and not tied to one host.

Can AI handle the SemVer bump?

Treat it as a suggestion only. A human makes the final call, because a model can miss a subtle behaviour break that warrants a MAJOR.

Prompt Library

Changelog Generation Prompts: 12 Templates for Useful Release Notes

Stop dumping git log into release notes. 12 prompt templates to turn commits / PRs into a user-facing changelog that's honest, brief, and useful. Updated June 2026.

Published: May 19, 2026 Updated: Jun 05, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

Auto-generated changelogs that read like chore: bump deps, chore: bump deps, fix: typo help no one. A good changelog prompt groups by user impact (New / Improved / Fixed), drops internals, and keeps every line to roughly 15 words or fewer. The 12 templates below are written to do exactly that, and they work in any chat assistant: paste your git log or PR list, get back release notes a non-engineer can read.

TL;DR

GitHub’s built-in “Generate release notes” lists merged PRs by label but never rewrites a bad PR title. AI changelog prompts close that gap by translating commits into user-facing language.
Pick a model by job size: a long release with hundreds of commits needs a 1M-token context window (Claude Sonnet 4.6, Gemini 3.1 Pro, or ChatGPT’s $200 Pro tier). A 30-commit weekly release runs fine on any free tier.
Group by impact, not commit type. Always surface breaking changes. Keep it to about 7 bullets per release.
Treat AI output as a first draft. A human edits the user-visible line and confirms the SemVer bump before publishing.

Who this is for

Solo founders shipping weekly, OSS maintainers cutting releases, product engineers writing notes for the help center, and dev rel teams syndicating to changelog.com.

GitHub auto-notes vs. an AI prompt

GitHub’s automatically generated release notes populate a release with a list of merged PRs grouped by label, contributor credits, and a full-changelog link. It is free and one click. What it will not do is rewrite anything: if a PR title was WIP: fix thing, that exact string lands in your release notes. An AI prompt reads the diff and metadata, decides whether a change is a feature, fix, or chore, and rewrites it in the voice your readers expect. Use GitHub auto-notes for the raw PR ledger, then run an AI prompt to produce the human-facing summary on top.

When not to use these prompts

Don’t use these for major-version announcements that need real marketing copy; they’re for incremental changelogs. Don’t auto-publish without a human pass on the user-visible line.

Prompt anatomy / structure formula

Every changelog prompt should carry six elements:

Role: who the model plays (release author / changelog editor / staff engineer cutting the release).
Context: commit range / PR list / labels / target audience (end users vs. support team).
Goal: one concrete deliverable, a grouped user-facing changelog (New / Improved / Fixed).
Constraints: what the model must not do (don’t include ticket numbers, don’t invent changes, don’t auto-publish).
Output format: grouped bullets, keep-a-changelog sections, markdown table, JSON, or RSS entry.
Examples / signal: 1-2 good changelog lines, or counter-examples of raw git log spam.

Best for

Weekly / per-release public changelog
Internal release notes for the support team
Marketplace listing “what’s new” copy
In-app changelog modal text
Migration guide for breaking releases

12 copy-ready prompt templates

Each template uses bracket placeholders like [commits]. Swap in your real data before sending.

1. Commits → user-facing changelog

Turn these commits into a user-facing changelog grouped by: New, Improved, Fixed, Internal (collapsed). Drop conventional-commit prefixes. Each bullet 15 words or fewer, in active voice, present tense. Skip merge commits and chore: bump deps unless major.

[commits]

Variables to swap: [commits] is the output of git log --oneline v1.0..HEAD.

2. PRs → changelog

Read these merged PRs and produce a changelog. Group by user impact. Skip PRs labelled internal / chore / tests. For each entry: title rewritten to user perspective + (optional) one-line context. Don't list PR numbers in the user version.

[prList]

Variables to swap: [prList], e.g. the JSON from gh pr list --state merged --json title,labels,body.

3. Honest “breaking change” callout

For this release, list ONLY breaking changes. For each: (1) what changed, (2) who is affected (users / API consumers / integrators), (3) action required, (4) deadline if soft-deprecation. Skip non-breaking. If none, output "No breaking changes." and stop.

4. Marketing changelog (sparing)

Pick the 1-2 changes worth a marketing line. Criteria: visible to users, valuable to many, demoable. Write each as: 6-10 word hook + 1-sentence "why you care". No "now you can..." filler. Skip if no change meets criteria.

5. Support-team release notes

Internal notes for support: (1) New features they might get asked about, (2) Behaviour changes that look like regressions, (3) Known issues we haven't fixed, (4) Workarounds. Tone: practical, no jargon. 200 words or fewer.

Write 3 bullets for an in-app changelog modal. Each: 7-10 words, verb-first phrasing ("Save searches to revisit"). Skip technical jargon. Add a single "See full changelog" link line.

7. Migration guide from a diff

For breaking changes in this diff, write a migration guide: (1) Each break, (2) Find: old usage / Replace: new usage with code snippets, (3) Estimated effort per consumer, (4) Deadline. No prose intro.

8. Keep-a-changelog conformant

Format the changelog per keepachangelog.com 1.1.0: sections [Added, Changed, Deprecated, Removed, Fixed, Security]. Each entry is past tense. Omit empty sections. Header includes version + YYYY-MM-DD. No emojis.

9. Bilingual changelog

Produce a changelog in EN and ZH. Keep both lists structurally identical (same order, same count). Don't translate technical terms (API, OAuth, SDK). Keep date and version line identical.

10. SemVer impact analysis

Given these commits, recommend the SemVer bump: MAJOR / MINOR / PATCH. Justify with a one-line list of breaking / additive / fix changes. Don't recommend MINOR just to feel impactful; accuracy wins.

11. RSS / Atom-ready entry

Produce a single changelog entry suitable for RSS: (1) Title (70 chars or fewer), (2) Date in RFC 822, (3) Body in HTML with ul/li bullets, (4) Single canonical URL. No styling, no inline scripts.

12. Changelog hygiene audit

Audit the last 5 changelog entries: (1) Any conventional-commit jargon leaking through? (2) Any bullets over 20 words? (3) Any entry that should've been merged into another? (4) Any release missing a date? Output a cleanup list.

Which AI model for changelogs (June 2026)

For a weekly release of 20-50 commits, any free tier is enough; the job is short and the formatting is the hard part, not reasoning. The model choice matters when a release is large enough that the entire git log plus diffs has to fit in one prompt.

Model	Context window	Good fit	Notes (June 2026)
Claude Sonnet 4.6	1M tokens	Large monorepo releases	Free tier limited; Claude Pro $20/mo bundles Claude Code, which runs these prompts at the terminal
Gemini 3.1 Pro	1M tokens	Big diffs, cheapest API	Google AI Pro $19.99/mo (formerly Gemini Advanced); API $2/$12 per 1M tokens in/out
GPT-5.5	~320 pages on Plus	Tone polish, marketing lines	Full 1M in-app context only on the $200 Pro tier; Plus is $20/mo

Tooling note: most teams pair a deterministic generator with an AI rewrite. Tools like release-please and the Changesets CLI (the dominant monorepo release tool in 2026) parse Conventional Commits to bump SemVer and draft a raw CHANGELOG; you then run template 1 or 8 above to humanize it. Let the deterministic tool own version numbers and dates; let the model own wording.

Common mistakes

Pasting raw git log, so chore: bump deps spam ends up everywhere.
Including ticket numbers in user-facing copy; they’re meaningless to users.
Marketing language (“Introducing…”) in patch releases.
Skipping breaking changes because they’re embarrassing, which guarantees a worse support load.
No date / no version header, which makes the entry search-unfriendly.
Letting a single release grow past 7 bullets; readers skim and nothing lands.
Auto-publishing without a human pass, so typos and awkward phrasing slip through.

How to push results further

Group by user impact, not commit type.
Keep each entry to roughly 15 words. Trim ruthlessly.
Always include breaking changes; surprise breakage costs more than blunt honesty.
Use present tense, active voice (“Adds search to settings”, not “Search was added”).
For bilingual notes, keep both structures identical so translation doesn’t introduce drift.
Make the changelog discoverable: link it from the app, README, and docs.
Tag the actual release commit so the changelog is reproducible from git diff.

FAQ

Should I use conventional commits? Yes, for auto-categorisation. But translate them into user voice before publishing; “feat: add OAuth” is not a customer-facing line.
How often should I publish a changelog? Match your release cadence. Weekly suits SaaS; per-release suits OSS.
Should I list every bug fix? Only ones users noticed. Internal bugs go in the collapsed “Internal” section.
What about security fixes? List them briefly, with a CVE link if applicable. No exploit details until the patch is widely deployed.
Do I need a changelog if I have GitHub release notes? A CHANGELOG.md in the repo is still useful: searchable, reviewable in PRs, and not tied to one host.
Can AI handle the SemVer bump? Treat it as a suggestion only. A human makes the final call, because a model can miss a subtle behaviour break that warrants a MAJOR.

Tags: #Prompt #Coding #Changelog #Release