# 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.

- Skill: `shyamw-cloud/release-notes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shyamw-cloud/release-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shyamw-cloud/release-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: shyamw-cloud (https://skillmd.com/u/shyamw-cloud)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shyamw-cloud/release-notes

---


# 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

1. 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.