Release notes

Skill ramanbamba/10x-pm/skills/release-notes

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill release-notes

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write customer-facing release notes and changelog entries from commit logs, merged PRs, ticket lists, or internal change descriptions. Use when the user says "write release notes", "changelog for this release", "announce these changes", or shares a list of shipped changes needing customer-facing copy.

SKILL.md

2.9 KB, as published. Nobody here has run it

Release Notes

Translate engineering output into customer-facing value. The reader's only question is "what can I do now that I couldn't before, and does anything I rely on change?"

Before writing

Get the raw material: commits, merged PRs, tickets, or a verbal list. If given repo access, extract changes since the last tag/release programmatically.
Ask the audience and venue: in-app changelog, email, docs page, or app-store listing. App-store copy has length limits and no markdown; email needs a subject line.
Ask which changes are breaking, behavior-altering, or require user action. These lead the notes regardless of how exciting anything else is.

Workflow

Filter ruthlessly. Internal refactors, dependency bumps, and invisible fixes don't belong in customer notes. If a release is all internals, the honest note is short — don't inflate.
Translate feature → outcome. Not "Added CSV export endpoint" but "Export your reports as CSV — pull your data into Excel or your BI tool." Every entry passes the "so what" test: the sentence must contain what the user can now do.
Order by reader impact: ⚠ breaking/action-required → new capabilities → improvements → fixes. Never bury a breaking change under features.
Fixes get dignity. "Fixed an issue where exports over 10k rows failed" — specific enough that the affected user recognizes their bug. "Various bug fixes and improvements" is a non-statement; use it never.
Match the product's voice (ask for a sample or check existing notes): playful, neutral, or enterprise-formal. Jokes age badly in enterprise changelogs.
Link out where the feature needs explanation — one line + "Learn more" beats a paragraph.

Output format

# [Product] [version] — [date]
[One-sentence release theme, if the release has one. Skip if it doesn't.]

## ⚠ Action required / Breaking
- [Change · who's affected · what to do · deadline]

## New
- **[Capability name]** — [what you can now do, one sentence]. [Learn more](link)

## Improved
- [Outcome-framed improvement, with numbers where real: "Search results now load 2× faster"]

## Fixed
- [Specific, recognizable fix]

Quality bar — self-check

Every entry names a user-visible outcome. Entries that only make sense to the eng team get rewritten or cut.
Breaking changes are first and impossible to miss.
Numbers are real — "2× faster" only if measured; otherwise "faster".
No "various fixes and improvements".
Length fits the venue (app-store limits, email scannability).