changeloglisted
Install: claude install-skill 0xmortuex/claude-code-skills
# changelog
A changelog is written for the reader who wants to know *"what does this release mean for me — what's new, what's fixed, what might break?"* — not for the author reviewing their own commits. The raw git log is the input, not the output. Your job is to translate developer-facing commit messages into user-facing notes: grouped, deduplicated, and phrased around impact.
## Gather the material
1. **Find the last release boundary.** The most recent tag is usually it: `git describe --tags --abbrev=0`, then `git log <lasttag>..HEAD`. If there are no tags, ask the user for the range (a date, a commit, "since v1.2") rather than dumping the entire history.
2. **Read the commits with their diffs when the message is thin.** A commit that says "fix stuff" needs you to look at what it changed. The message is a hint; the diff is the truth.
3. **Check for an existing `CHANGELOG.md`** and match its format, headings, and voice exactly. Consistency across releases matters more than any format you'd prefer.
## Group by what it means to a user
Organize under [Keep a Changelog](https://keepachangelog.com) categories — they map to the reader's actual questions:
- **Added** — new features and capabilities
- **Changed** — changes to existing behavior
- **Deprecated** — soon-to-be-removed features
- **Removed** — features taken out this release
- **Fixed** — bug fixes
- **Security** — vulnerability fixes (call these out; users need them to make patching decisions)
Omit empty categori