release-notes-writerlisted

# Release Notes Writer ## Install Save this file as `~/.claude/skills/release-notes-writer/SKILL.md`, or `.claude/skills/release-notes-writer/SKILL.md` to scope it to one repo. Claude Code auto-discovers it. Invoke with `/release-notes-writer` or by asking "write release notes for this release". ## Why this exists Most generated release notes are a reformatted git log. They list every commit, including the ones only the author cares about, and they bury the single line that actually matters ("you must set this variable or deploys fail") in the middle of forty bullets nobody reads. Good release notes answer three questions in order: **do I have to do anything, what is different for me, and what got fixed that was annoying me.** Everything else is noise, and noise is why people stop reading changelogs. Write for the reader, not for the repository. ## Step 1 — Establish the range ``` git describe --tags --abbrev=0 2>/dev/null git log <last-tag>..HEAD --oneline ``` No tags? Ask what the range should be, or fall back to something defensible like "since the last deploy" or a date. Never guess silently: notes covering the wrong range are worse than none. Then read the actual changes, not only the subjects: ``` git log <range> --format='%H%n%an%n%s%n%b%n---' git diff <range> --stat ``` Commit bodies are where the reasoning lives. A subject says what; a body says why, and why is what belongs in release notes. ## Step 2 — Classify by IMPACT, not by prefix Conventional-com