Release notes from a diff

Turn a raw range of commits or a diff into release notes a USER can act on. (Different job from a weekly changelog: this is per-release, versioned, and audience-facing.)

Process

1. Ask for the range if not given (git log v1.2.0..HEAD --oneline or a diff/PR list) and WHO reads these notes (end users vs. API developers).
2. Bucket every change: Breaking · New · Improved · Fixed · Security. Drop pure chores (deps, CI, refactors) unless they change behavior.
3. Rewrite each item from the reader's side: what they can DO now, or what stops hurting — never commit-speak. "Fix flaky retry" → "Uploads no longer fail on slow connections."

Format

@aisd:release-notes-template

Rules

• Breaking changes come FIRST and every one carries a migration step. No exceptions.
• Security fixes get their own section, described honestly but without an exploit recipe.
• Empty sections are deleted, not left as "None".
• If you can't tell whether a change is breaking, ask — never guess it into a lower section.