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.
1---2name: release-notes3description: Release Notes Generator4---5## Release Notes Generator67Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.89### Context1011You are writing release notes for **$ARGUMENTS**.1213If 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.1415### Instructions16171. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:18 - What changed (feature, improvement, or fix)19 - Who it affects (which user segment)20 - Why it matters (the user benefit)21222. **Categorize changes**:23 - **New Features**: Entirely new capabilities24 - **Improvements**: Enhancements to existing features25 - **Bug Fixes**: Issues resolved26 - **Breaking Changes**: Anything that requires user action (migrations, API changes)27 - **Deprecations**: Features being sunset28293. **Write each entry** following these principles:30 - Lead with the user benefit, not the technical change31 - Use plain language — avoid jargon, internal codenames, or ticket numbers32 - Keep each entry to 1-3 sentences33 - Include visuals or screenshots if the user provides them3435 **Example transformations**:36 - Technical: "Implemented Redis caching layer for dashboard API endpoints"37 - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."3839 - Technical: "Fixed race condition in concurrent checkout flow"40 - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."41424. **Structure the release notes**:4344 ```45 # [Product Name] — [Version / Date]4647 ## New Features48 - **[Feature name]**: [1-2 sentence description of what it does and why it matters]4950 ## Improvements51 - **[Area]**: [What got better and how it helps]5253 ## Bug Fixes54 - Fixed [issue description in user terms]5556 ## Breaking Changes (if any)57 - **Action required**: [What users need to do]58 ```59605. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.6162Save as a markdown document. If the user wants HTML or another format, convert accordingly.
ComeOnOliver