Release Notes Generator
Act as the release manager for the current repository. Produce a GitHub Release description in Markdown, ready to copy-paste, covering everything merged since the last release tag.
1. Determine the range
git fetch --tags
git describe --tags --abbrev=0 # last tag
git log <last-tag>..HEAD --no-merges --pretty=format:"%h %an %s"
- If the user names a tag / version / date range, use that instead.
- If no tags exist, fall back to the first commit (
git log --no-merges) and say so.
- For a release of a single package in a multi-package repo, filter by path:
git log <last-tag>..HEAD -- <path>.
2. Learn the repository's release style
Before writing, sample the existing releases so the output matches the established tone, heading structure, bullet format, and link conventions:
gh release list --limit 5
gh release view <tag>
If gh is unavailable, fall back to CHANGELOG.md / release notes files in the repo. Mirror whatever conventions you find (heading text such as ## What's Changed, component/module prefixes, links to docs, emoji usage). The rules below are defaults — repository conventions win.
3. Enrich the entries
- Extract PR and issue numbers from commit messages / merge commits (
#1234) and keep them in the bullets.
- Identify external contributions (authors who are not maintainers of the repo). Use
gh pr view <number> --json author,authorAssociation or gh api repos/{owner}/{repo}/collaborators when available; otherwise infer from the commit author list and ask the user if uncertain.
- Detect breaking changes:
! in conventional-commit type, BREAKING CHANGE: footers, removed/renamed public API, changed defaults.
4. Write the notes
Rules:
- Output the result in a fenced code block so it can be copy-pasted into the GitHub Release description.
- Use user-facing wording — describe the benefit or behavior change, not the internal implementation.
- One concise bullet per change; merge duplicates and follow-up fix commits into a single item.
- Group by component / module / package when the repo has more than one, using the repo's existing prefix style.
- Omit noise unless it affects users: merge commits, formatting-only changes, CI/build tweaks, dependency and version bumps without functional impact, test-only changes.
- Prefix breaking changes with ‼ (the repository may use a different marker — follow its precedent).
- Suffix external contributions with
by @author 💕 (again, follow repo precedent).
- Keep any "Full Changelog" / compare link the repository normally appends.
Output shape (default)
## What's Changed
* `ComponentA` - new `SomeParameter` for X #1234
* ‼ `ComponentB` - `OldParameter` removed, use `NewParameter` instead #1240
* `ComponentC` - fixed: incorrect rendering when Y #1236 by @contributor 💕
* **SubPackage** (`v1.8.0`) - short description of the change
* minor accessibility fixes
Notes
- If commit messages are too terse to describe user impact, open the referenced PRs (
gh pr view <number>) rather than guessing.
- State briefly (outside the code block) which tag range was used, so the user can verify the scope.
1---2name: release-notes3description: Generate a GitHub Release description (Markdown) from commits since the last tag, matching the tone and structure of the repository's existing releases. Use when the user asks for release notes, a release description, a changelog since the last tag, or "what's changed" for the next version.4---56# Release Notes Generator78Act as the release manager for the current repository. Produce a **GitHub Release description in Markdown**, ready to copy-paste, covering everything merged since the last release tag.910## 1. Determine the range1112```bash13git fetch --tags14git describe --tags --abbrev=0 # last tag15git log <last-tag>..HEAD --no-merges --pretty=format:"%h %an %s"16```1718- If the user names a tag / version / date range, use that instead.19- If no tags exist, fall back to the first commit (`git log --no-merges`) and say so.20- For a release of a single package in a multi-package repo, filter by path: `git log <last-tag>..HEAD -- <path>`.2122## 2. Learn the repository's release style2324Before writing, sample the existing releases so the output matches the established tone, heading structure, bullet format, and link conventions:2526```bash27gh release list --limit 528gh release view <tag>29```3031If `gh` is unavailable, fall back to `CHANGELOG.md` / release notes files in the repo. Mirror whatever conventions you find (heading text such as `## What's Changed`, component/module prefixes, links to docs, emoji usage). The rules below are defaults — repository conventions win.3233## 3. Enrich the entries3435- Extract PR and issue numbers from commit messages / merge commits (`#1234`) and keep them in the bullets.36- Identify **external contributions** (authors who are not maintainers of the repo). Use `gh pr view <number> --json author,authorAssociation` or `gh api repos/{owner}/{repo}/collaborators` when available; otherwise infer from the commit author list and ask the user if uncertain.37- Detect **breaking changes**: `!` in conventional-commit type, `BREAKING CHANGE:` footers, removed/renamed public API, changed defaults.3839## 4. Write the notes4041Rules:4243- Output the result in a **fenced code block** so it can be copy-pasted into the GitHub Release description.44- Use **user-facing wording** — describe the benefit or behavior change, not the internal implementation.45- One concise bullet per change; merge duplicates and follow-up fix commits into a single item.46- Group by component / module / package when the repo has more than one, using the repo's existing prefix style.47- Omit noise unless it affects users: merge commits, formatting-only changes, CI/build tweaks, dependency and version bumps without functional impact, test-only changes.48- Prefix breaking changes with ‼ (the repository may use a different marker — follow its precedent).49- Suffix external contributions with `by @author 💕` (again, follow repo precedent).50- Keep any "Full Changelog" / compare link the repository normally appends.5152## Output shape (default)5354````markdown55## What's Changed56* `ComponentA` - new `SomeParameter` for X #123457* ‼ `ComponentB` - `OldParameter` removed, use `NewParameter` instead #124058* `ComponentC` - fixed: incorrect rendering when Y #1236 by @contributor 💕59* **SubPackage** (`v1.8.0`) - short description of the change60* minor accessibility fixes61````6263## Notes6465- If commit messages are too terse to describe user impact, open the referenced PRs (`gh pr view <number>`) rather than guessing.66- State briefly (outside the code block) which tag range was used, so the user can verify the scope.
havit