How do I install the Release Notes skill?

Run npx skillmds@latest add shyamw-cloud/release-notes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release Notes safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release Notes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release Notes free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release Notes?

shyamw-cloud (@shyamw-cloud) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release Notes by shyamw-cloud — Agent Skill

Name: Release Notes
Rating: 4.5 (4 reviews)
Author: shyamw-cloud

Release Notes

Use to turn a list of merged PRs (or a git log range) into customer-facing release notes. Groups by theme, leads with what changed for the user (not what was refactored), and produces both a long form and a 3-bullet TL;DR.

shyamw-cloud Updated Sep 22, 2026

File contents

release-notes

Engineering changelogs and customer release notes are different things. This skill produces the customer version: focused on what is now possible, not what files were touched.

Inputs to gather

Range — git tag, PR list, or date range.
Audience — end users, admins, developers integrating the API?
Tone — punchy product-update or formal enterprise note?

Method

Pull the PR list / commits.
Drop everything that doesn't change observable behavior (refactors, deps bumps, internal docs).
Cluster the rest into 3-5 themes (e.g. "Faster onboarding", "Better search", "More reliable webhooks").
For each item: write one line on what's new, and one line on why the user should care.
Lead with the biggest user-visible win.

Output format

## TL;DR (3 bullets)
- <biggest win>
- <second biggest>
- <one notable fix or quality-of-life change>

## What's new

### <Theme 1>
- **<feature>** — <what's new>. <why you should care>
- **<feature>** — <what's new>. <why you should care>

### <Theme 2>
- ...

## Fixes & quality
- <fix> — <user-visible impact>
- <fix> — <user-visible impact>

## For developers (only if API/SDK changed)
- <breaking change>: <migration steps>
- <new endpoint>: <one-line description>

## Coming next (optional)
- <one teaser; only include if marketing approved>

Hard rules

Never include "refactored X" or "improved code quality" in customer notes.
Never list a fix that wasn't a customer-visible bug.
Never use version numbers as headers ("v2.4.1") without a name or theme alongside.
Always include a "Fixes & quality" section, even if short — it builds trust.

---name: release-notesdescription: Use to turn a list of merged PRs (or a git log range) into customer-facing release notes. Groups by theme, leads with what changed for the user (not what was refactored), and produces both a long form and a 3-bullet TL;DR.---# release-notesEngineering changelogs and customer release notes are different things. This skill produces the customer version: focused on **what is now possible**, not **what files were touched**.## Inputs to gather- **Range** — git tag, PR list, or date range.- **Audience** — end users, admins, developers integrating the API?- **Tone** — punchy product-update or formal enterprise note?## Method1. Pull the PR list / commits.2. Drop everything that doesn't change observable behavior (refactors, deps bumps, internal docs).3. Cluster the rest into 3-5 themes (e.g. "Faster onboarding", "Better search", "More reliable webhooks").4. For each item: write one line on what's new, and one line on why the user should care.5. Lead with the biggest user-visible win.## Output format```## TL;DR (3 bullets)- <biggest win>- <second biggest>- <one notable fix or quality-of-life change>## What's new### <Theme 1>- **<feature>** — <what's new>. <why you should care>- **<feature>** — <what's new>. <why you should care>### <Theme 2>- ...## Fixes & quality- <fix> — <user-visible impact>- <fix> — <user-visible impact>## For developers (only if API/SDK changed)- <breaking change>: <migration steps>- <new endpoint>: <one-line description>## Coming next (optional)- <one teaser; only include if marketing approved>```## Hard rules- Never include "refactored X" or "improved code quality" in customer notes.- Never list a fix that wasn't a customer-visible bug.- Never use version numbers as headers ("v2.4.1") without a name or theme alongside.- Always include a "Fixes & quality" section, even if short — it builds trust.

Frequently asked questions