Use release-notes

Write release notes from a git log, a list of merged PRs or rough notes about what changed

Write release notes from a git log, a list of merged PRs or rough notes about what changed — for the audience and in the format the user names (a customer changelog page, an email, an in-app "what's new", store text, a CHANGELOG.md entry). Says nothing the input doesn't, writes a vague change only as far as it was described, puts breaking changes and anything the reader must do first, and keeps internal noise and working notes out of the text.

Reach for it when the user wants release notes, a changelog entry, "what's in this release", a deploy announcement, or to summarise changes since the last tag.

Install it

npx skilldrop-cli install release-notes                 # Claude Code, your user folder
npx skilldrop-cli install release-notes --project       # Claude Code, this repo
npx skilldrop-cli install release-notes --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Write release notes for everything since the last tag"
• "Update CHANGELOG.md for v3.1 from the git history"
• "What's in this release? Turn v1.8.0..v1.9.0 into customer-facing notes"
• "Draft a deploy announcement for internal stakeholders from these merged PRs"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Review the changes in this release for risk before we ship"
• "Write a one-page summary for the board on why this release matters strategically"
• "Run a Sonar quality review on the code merged this sprint"

If another skill answers instead, ask for this one by name: "use release-notes".

Check what you get

A good result:

• Nothing in the notes goes beyond the input. No invented feature, behaviour, symptom, figure, date, version, PR number or count.
• Reverted and superseded changes don't appear; the final state does.
• Breaking changes and required actions come first, found from the text as well as the markers, with an action that fits how the audience gets the release.
• Internal noise is absent from customer text.
• The format, length and tone are the ones the user asked for, and the notes carry no working notes.
• Vague items are left out or kept vague, and named once to the user.

Use something else when

• A single PR description — that's one change; use pr-description-writer
• Reviewing the changes for quality or risk — that's devils-advocate / sonar-review
• A narrative about why the release matters strategically — feed the notes to exec-summary
• Writing commit messages going forward — this skill reads history, it doesn't write it

Where a loop runs it

• Stage announce of the release loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: devils-advocate, exec-summary, pr-description-writer, sonar-review

Edit this page on GitHub · View source