Release Notes
Turn tickets, PRDs, or internal changelogs into polished, user-facing release notes and update announcements.
Overview
Release Notes is an agent skill most often used in Launch (also Ship launch prep) that generates user-facing release notes from tickets, PRDs, or changelogs.
Install
npx skills add https://github.com/phuryn/pm-skills --skill release-notesWhat is this skill?
- Ingests JIRA/Linear exports, PRDs, git logs, or internal changelogs as raw input
- Sorts changes into New Features, Improvements, Bug Fixes, Breaking Changes, and Deprecations
- User-benefit-first copy rules: plain language, no ticket IDs or internal codenames
- Optional web research when a product URL is provided to match audience tone
- 5 change categories: New Features, Improvements, Bug Fixes, Breaking Changes, Deprecations
Adoption & trust: 1.1k installs on skills.sh; 12.3k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have raw tickets or a git log but no time to rewrite them as benefit-led release notes your users will read.
Who is it for?
Indie SaaS founders shipping weekly who need consistent changelog voice from Linear, JIRA, or PRD exports.
Skip if: Deep technical API reference documentation or internal-only incident postmortems with no user announcement.
When should I use this skill?
Writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.
What do I get? / Deliverables
You get categorized, plain-language release notes ready for changelog pages, emails, or launch posts.
- Categorized user-facing release notes
- Breaking change and deprecation callouts
- Benefit-led entries suitable for changelog or blog
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Release notes are the primary artifact when communicating what shipped to users and distribution channels after build and ship work complete. Distribution covers customer-facing announcements, blog posts, and in-app update summaries derived from shipped work.
Where it fits
Draft release notes from the sprint ticket export before tagging the production release.
Publish a categorized changelog and blog post announcing new features to email and social channels.
Repurpose the same shipped-items list into a monthly customer newsletter section.
How it compares
Structured changelog generator from PM inputs—not a code-review or automated semantic-versioning tool.
Common Questions / FAQ
Who is release-notes for?
Solo builders and product-minded indies who own both shipping and telling users what changed.
When should I use release-notes?
At Launch distribution when publishing changelogs; during Ship launch prep when drafting notes alongside a release; or in Grow content when repurposing shipped work into update emails.
Is release-notes safe to install?
It may read tickets and search the web for product context—sanitize proprietary data before upload; review the Security Audits panel on this Prism page.
SKILL.md
READMESKILL.md - Release Notes
## Release Notes Generator Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes. ### Context You are writing release notes for **$ARGUMENTS**. If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience. ### Instructions 1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract: - What changed (feature, improvement, or fix) - Who it affects (which user segment) - Why it matters (the user benefit) 2. **Categorize changes**: - **New Features**: Entirely new capabilities - **Improvements**: Enhancements to existing features - **Bug Fixes**: Issues resolved - **Breaking Changes**: Anything that requires user action (migrations, API changes) - **Deprecations**: Features being sunset 3. **Write each entry** following these principles: - Lead with the user benefit, not the technical change - Use plain language — avoid jargon, internal codenames, or ticket numbers - Keep each entry to 1-3 sentences - Include visuals or screenshots if the user provides them **Example transformations**: - Technical: "Implemented Redis caching layer for dashboard API endpoints" - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing." - Technical: "Fixed race condition in concurrent checkout flow" - User-facing: "Fixed an issue where some orders could fail during high-traffic periods." 4. **Structure the release notes**: ``` # [Product Name] — [Version / Date] ## New Features - **[Feature name]**: [1-2 sentence description of what it does and why it matters] ## Improvements - **[Area]**: [What got better and how it helps] ## Bug Fixes - Fixed [issue description in user terms] ## Breaking Changes (if any) - **Action required**: [What users need to do] ``` 5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs. Save as a markdown document. If the user wants HTML or another format, convert accordingly.