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 shippedoutput/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.
1---2name: release-notes3description: Draft release notes or changelog entries from PRDs, meeting decisions, and shipped work.4---56You 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.78## Source and destination910The skill accepts input three ways (no hierarchy, all equal):11- **Pasted content**: Ticket summaries, changelog entries, or descriptions of what shipped pasted directly in the conversation12- **File path**: A file path dropped into the terminal (starts with `/`, `~`, or `./`, or ends with a file extension). Read the file automatically.13- **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/`.1415If 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.1617- Additional input: PRDs, meeting notes in workspace18- Output goes to: `output/`19- Filename: `release-notes-[version-or-date]-[YYYY-MM-DD].md`2021## Workflow2223### 1. Gather what shipped2425Check these locations for recent work:2627- `output/prd/` and `context/prd/` -- specs for features that shipped28- `output/meetings/` and `context/meetings/` -- decisions about what's included in this release29- PM input -- the PM may list what shipped, paste ticket summaries, or drop a file path3031If 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?"3233### 2. Determine the audience3435- **External (users):** Focus on benefits, not features. Plain language, no jargon.36- **Internal (team/company):** Can include technical details, metrics, shoutouts.37- **Both:** Write external-facing notes, add an internal section at the bottom.3839If unclear, ask who's reading this.4041### 3. Write the notes4243```markdown44# Release Notes: [Version or Date]4546**Date:** YYYY-MM-DD47**Status:** Draft4849---5051## What's New5253### [Feature Name]54[1-2 sentences: what it does and why it matters to the user. Lead with the benefit.]5556### [Feature Name]57[1-2 sentences.]5859---6061## Improvements6263- [Short description of improvement and what's better now]6465---6667## Bug Fixes6869- [What was broken and what's fixed. User language, not technical.]7071---7273## Known Issues7475- [Anything that's still broken or limited. Be honest.]76```7778### 4. Save7980Save to `output/release-notes-[version-or-date]-[YYYY-MM-DD].md`. Include `**Status:** Draft` in the doc header.8182After saving, offer:83- "Want a shorter version for Slack or email?"84- "Want me to draft an announcement for a specific audience?"8586## Quality rules8788- **Lead with benefits, not features.** "Find what you need faster" beats "Added full-text search to the dashboard."89- **User language only.** No internal jargon, ticket numbers, or technical details in external notes.90- **Be honest about known issues.** Users trust transparency more than perfection.91- **Keep it short.** Most users scan release notes in 10 seconds. Make those 10 seconds count.92- **Don't list everything.** Minor internal changes, refactors, and dependency updates don't belong in user-facing notes.
arezous