changelog

name: changelog description: Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…". version: 1.0.0 license: MIT keywords: [changelog, release, git, keep-a-changelog, semver]

A changelog is for users deciding whether to upgrade, not a commit dump. Format: Keep a Changelog + semver sections.

Procedure

Find the range. Last release tag: git describe --tags --abbrev=0. Collect commits since: git log <tag>..HEAD --oneline --no-merges.
Bucket each commit:
- Added (feat) · Fixed (fix) · Changed (behavior changes, perf)
- Deprecated · Removed · Security
- Drop pure chore/ci/test/docs noise unless user-visible.
Rewrite each line user-first. Translate implementation into impact:
- commit: fix(ingest): treat mtime regressions as edits
- entry: Fixed duplicate chunks after restoring files from backup. One line each; link the PR/issue number when the repo uses them.
Squash threads. Five commits iterating on one feature = one entry.
Pick the version bump from the buckets: breaking → major, Added → minor, only Fixed → patch (pre-1.0: breaking → minor).

Write the section at the top of CHANGELOG.md:

## [0.2.0] - 2026-06-10
### Added
- Live re-indexing: `engram watch` picks up edits automatically.
### Fixed
- Duplicate chunks after restoring files from backup.

Keep an ## [Unreleased] section at the very top for changes landing between releases; releasing = renaming it and starting a fresh one.

Quality bar

Every entry answers: what can I do now / what stopped being broken? If an entry needs the source code to make sense, rewrite it.