Release Notes Writer
Turns a version's merged PRs and commits into human-facing release notes — highlights, breaking changes and upgrade steps, honest about what changed.
What this skill does
Key features
- Reads merged PRs and commits for a version and writes reader-facing notes
- Leads with highlights users actually care about, not raw commit text
- Calls out breaking changes and the upgrade steps they require
- Stays honest — no benefits or metrics that aren't in the changes
- Links each note back to its PR for anyone who wants detail
Use cases
- Publishing GitHub release notes for a tagged version
- Writing a customer-facing summary of what shipped
- Documenting breaking changes and migration steps for an upgrade
SKILL.md
The skill definition — its metadata and the exact instructions an agent follows. Copy it into a SKILL.md file in your agent's skills folder.
| name | release-notes |
|---|---|
| description | Write human-facing release notes for a version from its merged PRs and commits. |
| allowed-tools | Read, Bash(git log:*), Bash(git tag:*), Bash(git diff:*) |
| output | release notes |
| audience | end users |
Musts
- Read the merged PRs and commits for the version range before drafting anything.
- Lead with highlights that matter to users, written in plain language, not raw commit subjects.
- Call out every breaking change under its own heading with the required upgrade steps.
- Never claim a benefit, speed-up, or metric that the changes do not actually demonstrate.
- Ask the user to tag or publish the release; do not create tags or releases yourself.
Guidelines
- Group notes as Highlights, Fixes, Breaking Changes, and Upgrade Notes; drop empty sections.
- Prefer user-visible features over internal refactors, chores, and CI tweaks.
- Link each note to its PR number so readers can dig into detail.
Output format
# v1.4.0
## Highlights
- Login is now rate-limited to protect against brute-force attempts (#412)
## Fixes
- Retrying a signup no longer sends duplicate emails (#418)
## Breaking Changes
- The `/auth/login` endpoint now returns 429 after 5 failed attempts (#412)
## Upgrade Notes
- Clients must handle a 429 response and back off before retrying.FAQ
Does it publish or tag the release?
No. It drafts the notes text only. You review it and create the tag or GitHub release yourself, so a human always signs off on what goes public.
How does it decide what's a highlight?
It favors user-visible features and fixes over internal refactors and chores, and it never claims an improvement — like a speed-up — unless the change actually shows it. Unclear items are listed plainly rather than dressed up.
Before running any skill, read its instructions and the tools it's allowed to use, and test it on a safe target first. See LLM security best practices.