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
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.