changeloglisted

Produce a changelog from what actually shipped: the commits, merged PRs, and references between two points in history. Write it for the people who *read* releases (users, integrators), not as a raw `git log` dump. ## Hard rules: never break these - **Base it on real history, never invent.** Every entry must trace to a commit, PR, or issue. No speculative or aspirational items. - **Match the existing format.** If `CHANGELOG.md` or a changelog tool already exists, follow its structure, headings, and conventions exactly. Don't impose a new style on an established file. - **Never rewrite already-released sections.** Add the new version on top; leave shipped entries untouched. - **Write for humans.** Translate commits into user-facing outcomes. Drop pure-noise commits (formatting, CI tweaks, internal refactors) unless they affect users. - **Surface breaking changes prominently.** They're the entries most likely to ruin someone's day if missed. ## Step 1: Determine the range - Last release to now: `git describe --tags --abbrev=0` gives the latest tag; the range is `<lastTag>..HEAD`. - Between two releases: `<olderTag>..<newerTag>`. - First release ever: use the full history (no lower bound). - Honor an explicit range or version the user passed. ## Step 2: Gather the raw material - Commits in range: `git log <range> --no-merges --pretty=format:'%H %s'` (and `%b` for bodies, to catch `BREAKING CHANGE:` footers). - Merge commits / PR numbers: `git log <range> --merges` and `(#12