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
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)
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
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."
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]
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.