# Release Notes

> Use when cutting a release or asked what changed between two versions. Converts raw git history into release notes organized by user impact, not by commit order.

- Skill: `dkenge123-oss/release-notes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dkenge123-oss/release-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dkenge123-oss/release-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dkenge123-oss (https://skillmd.com/u/dkenge123-oss)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dkenge123-oss/release-notes

---


# Release Notes

Release notes are for users, not for the people who wrote the commits. Translate.

## Protocol

1. **Establish the range.** Find the last release tag (`git describe --tags --abbrev=0`) and collect everything since: `git log <tag>..HEAD --oneline`. Include merged PR titles when available.
2. **Classify every change by user impact:**
   - **Breaking**: anything requiring user action to upgrade
   - **New**: capabilities that did not exist before
   - **Improved**: existing behavior that got better or faster
   - **Fixed**: bugs users could have hit
   - **Internal**: refactors, CI, dependencies (usually collapsed to one line or omitted)
3. **Rewrite each entry in user language.** "fix(parser): handle CRLF in chunked reads" becomes "Fixed a crash when uploading files created on Windows." Name the symptom the user saw, not the mechanism.
4. **Lead with breaking changes** and include a short migration note for each: what breaks, what to change, one example.
5. **Order within sections by impact**, biggest first. Nobody reads to the bottom.
6. **Credit external contributors** by handle when the history shows them.

## Style

- Present tense headlines, past tense fix descriptions.
- Every entry should be understandable without opening the diff.
- Version and date at the top. Follow semver: breaking changes force a major bump.

## Never

- Never list raw commit subjects as release notes.
- Never hide a breaking change in the middle of a fix list.
- Never invent changes that are not in the range.