Update Changelog
Propose [Unreleased] lines for CHANGELOG.md based on the current branch's diff. Edit the file inline; user reviews and stages.
When to run
- Before every commit that touches
src/(see.claude/rules/changelog-discipline.md). - Before opening a PR — make sure
[Unreleased]reflects everything on the branch. - On release — when collapsing
[Unreleased]into a versioned section.
Procedure
Identify the base:
git merge-base HEAD main(ormaster). Fall back toorigin/mainif localmaindoesn't exist.Diff:
git diff --name-status <base>..HEAD— file-level changes.git log <base>..HEAD --pretty=format:"%h %s"— commits since base.
Classify each change into Keep-a-Changelog sections:
Pattern Section New file under src/, new public function/classAdded Modified function/class behavior, new dependency, refactor Changed Removed file, removed function/class Removed Bug fix (look for "fix", "bug" in commit msgs, or fixed test) Fixed Feature flag for removal, scheduled deletion Deprecated CVE patch, auth/crypto fix Security Draft one bullet per change. Style:
- Imperative mood (
Add ...,Fix ...,Switch ...). - One sentence, under ~80 chars.
- Reference PR/issue numbers in parens at the end if known.
- Imperative mood (
Edit
CHANGELOG.mdinline:- Locate the
## [Unreleased]block. - Insert each line under its matching subsection.
- Create subsections in order: Added, Changed, Deprecated, Removed, Fixed, Security.
- Don't overwrite existing entries — append.
- Locate the
Show the diff to the user:
git diff CHANGELOG.mdHand off: tell the user to review the proposed lines and stage them:
git add CHANGELOG.mdDo not run
git addautomatically.
Releasing a version
When the user says "cut version X.Y.Z":
- Replace
## [Unreleased]heading with## [X.Y.Z] - YYYY-MM-DD(today's date). - Insert a fresh empty
## [Unreleased]block at the top of the version history. - Bump
versioninpyproject.tomland__version__insrc/<module>/__init__.py. - Show the diff. User commits and tags (
git tag vX.Y.Z).
Anti-patterns
- Auto-staging the file — user must review wording.
- Vague lines like "Updated code" or "Various improvements." Be specific.
- Dropping lines for "minor" changes that touched
src/. If it changed behavior, it goes in the log. - Re-classifying user-authored entries — leave them alone unless asked.