A changelog that writes itself from git history

The problem. You shipped a bunch of small things this week and by Friday you can’t fully remember what, in what order, or which ones actually matter to a user reading a changelog.

The play. Point Claude Code at your actual git history and have it draft the changelog from what really happened, translated into user language instead of commit-message shorthand.

Setup (5 min). Open Claude Code in your repo. Know the date range you want covered — usually since the last changelog entry.

The prompt:

Read the git log since [date or last tag]. Read the actual diffs for
anything that looks user-facing, not just the commit messages — a commit
message can undersell or oversell what actually changed.

Draft a changelog entry:
1. Group changes into "New," "Improved," and "Fixed"
2. Translate each into what a user would notice, not engineering shorthand
   ("fixed race condition in auth" becomes "fixed an issue where..." from
   the user's actual experience)
3. Skip anything purely internal (refactors, test changes) unless it
   affects behavior
4. Flag anything you're not sure is actually user-facing, so I can decide

Keep entries short — one line each where possible.

What you get. An accurate, user-readable changelog built from what actually shipped, not a reconstruction from memory that misses the thing you fixed on Tuesday and forgot about by Friday.

What to watch for.

• Commit messages lie sometimes — a message that says “small fix” can hide a real behavior change. The instruction to read actual diffs, not just messages, is what catches this.
• Read the draft yourself before publishing — a changelog is one of the few places customers actually read your engineering work directly.

Make it repeatable. Run it on whatever cadence you actually ship — weekly is common — right after your git history has a natural stopping point, before the details fade.