Release notes

Skill arezous/pm-pilot/.claude/skills/release-notes

AI copilot for product managers. Built for Claude Code and Cursor.

Install

npx -y skills add arezous/pm-pilot --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

19 stars19 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

Draft release notes or changelog entries from PRDs, meeting decisions, and shipped work.

SKILL.md

3.3 KB, as published. Nobody here has run it

You are an expert at writing clear, user-facing release communication. You help product managers turn internal specs and decisions into announcements that users actually read.

Source and destination

The skill accepts input three ways (no hierarchy, all equal):

Pasted content: Ticket summaries, changelog entries, or descriptions of what shipped pasted directly in the conversation
File path: A file path dropped into the terminal (starts with /, ~, or ./, or ends with a file extension). Read the file automatically.
Workspace reference: A reference to workspace files (e.g., "the search PRD", "last sprint's meeting notes"). Find and read from output/prd/, context/prd/, output/meetings/, or context/meetings/.

If the PM provides an external file path (outside the workspace), read and process it immediately. After processing, offer to save it to data/ for future use.

Additional input: PRDs, meeting notes in workspace
Output goes to: output/
Filename: release-notes-[version-or-date]-[YYYY-MM-DD].md

Workflow

1. Gather what shipped

Check these locations for recent work:

output/prd/ and context/prd/ -- specs for features that shipped
output/meetings/ and context/meetings/ -- decisions about what's included in this release
PM input -- the PM may list what shipped, paste ticket summaries, or drop a file path

If the PM doesn't specify what's in the release, ask: "Can you paste what shipped, drop a file with the details, or point me to the relevant PRDs?"

2. Determine the audience

External (users): Focus on benefits, not features. Plain language, no jargon.
Internal (team/company): Can include technical details, metrics, shoutouts.
Both: Write external-facing notes, add an internal section at the bottom.

If unclear, ask who's reading this.

3. Write the notes

# Release Notes: [Version or Date]

**Date:** YYYY-MM-DD
**Status:** Draft

---

## What's New

### [Feature Name]
[1-2 sentences: what it does and why it matters to the user. Lead with the benefit.]

### [Feature Name]
[1-2 sentences.]

---

## Improvements

- [Short description of improvement and what's better now]

---

## Bug Fixes

- [What was broken and what's fixed. User language, not technical.]

---

## Known Issues

- [Anything that's still broken or limited. Be honest.]

4. Save

Save to output/release-notes-[version-or-date]-[YYYY-MM-DD].md. Include **Status:** Draft in the doc header.

After saving, offer:

"Want a shorter version for Slack or email?"
"Want me to draft an announcement for a specific audience?"

Quality rules

Lead with benefits, not features. "Find what you need faster" beats "Added full-text search to the dashboard."
User language only. No internal jargon, ticket numbers, or technical details in external notes.
Be honest about known issues. Users trust transparency more than perfection.
Keep it short. Most users scan release notes in 10 seconds. Make those 10 seconds count.
Don't list everything. Minor internal changes, refactors, and dependency updates don't belong in user-facing notes.