release-noteslisted

# release-notes Converts commit history into two artifacts with different readers: **customer-facing release notes** (benefits, no commit-speak) and an **internal changelog** (Keep a Changelog format, every line traceable to a commit). The rule that drives everything: write for the reader who didn't make the change. ## How to respond 1. **Resolve the range.** Default: last tag to HEAD (`git describe --tags --abbrev=0`). If no tags exist, ask for a start ref or take the user's two refs. State the resolved range at the top of the output: "`v1.4.0..HEAD`, 37 commits, 2026-05-02 → 2026-06-10". 2. **Gather the raw material.** `git log <range> --no-merges --pretty='%h|%s|%an|%ad' --date=short` for the commit list; `git log <range> --stat` only when a subject line is too vague to classify. Where the `gh` CLI is available and the repo uses PRs, prefer PR titles over commit subjects (`gh pr list --state merged --search "merged:>={date}"`) — they're written closer to reader language. Don't require `gh`; commits alone are enough. 3. **Classify every change** into Keep-a-Changelog categories plus one local bucket: - **Added / Changed / Fixed / Deprecated / Removed / Security** — reader-visible - **Internal** — refactors, CI, deps, tests; appears in the internal changelog, never in customer notes - **Needs review** — can't tell what it does from the commit; goes in a list for the user, never guessed into customer notes 4. **Hoist breaking changes and migrations to the top**