AugmentClaude

Release Notes

Draft user-facing release notes from a verified release range.

Installation

  1. Make sure Claude is on your device and in your terminal.

    Skills load from ~/.claude/skills/ when Claude Code starts up — so you need it on your machine first. If you don't have it yet, install it once with the command below, then run claude in any terminal to verify.

    One-time setup
    npm i -g @anthropic-ai/claude-code

    Already have it? Skip ahead.

  2. Paste into Claude Code or into your terminal.

    This copies the whole skill folder into ~/.claude/skills/release-notes-ccch1mneyyy/ — the SKILL.md plus any scripts, reference docs, or templates the skill ships with. Safe default: works for every skill.

    Faster alternative (instruction-only skills)

    Skips the clone and grabs only the SKILL.md file. Don't use this if the skill ships Python scripts, reference markdowns, or asset templates — they won't be downloaded and the skill will fail when it tries to load them.

    Quick install (SKILL.md only)
    Sign up to copy
  3. Restart Claude Code.

    Quit and reopen Claude Code (or any other agent that loads from ~/.claude/skills/). New skills are picked up on startup.

  4. Just ask Claude.

    Skills auto-activate when your request matches the skill's description — no slash command needed. Trigger phrases live in the skill's own frontmatter; you can read them in the “What this skill does” section above.

Prefer to read the source first? Open on GitHub.

When Claude uses it

Draft user-facing release notes from a verified release range. Use for release-note or changelog requests and /release-notes; writing notes alone does not imply publishing a release.

What this skill does

Explain what changes for users in the requested release, in their language.

  1. Use the user's specified range. Otherwise identify the target version and the previous published release on the relevant stable or prerelease line; do not assume the newest Git tag is the right baseline. State any uncertainty before describing changes as released.
  2. Inspect the net diff and associated commits or PRs. Account for reverts and fixes folded into the same release; do not turn every commit into a separate feature.
  3. Lead with breaking changes, if any, and concrete migration steps. Group the remaining user-visible changes only where that helps scanning. Omit empty sections and internal churn with no user impact.
  4. Use verified PR links and contributor credits, following the repository's release-note format. Keep benefits, limitations, and availability tied to the actual change; do not invent release status or migration instructions.

Deliver the notes as a draft unless publishing is part of the user's request. If it is, continue the authorized release workflow using the repository's version and tag rules.

Related skills