Release Notes Generator
Transform raw engineering artifacts (git commits, Jira tickets, changelogs, raw notes) into polished, user-facing release notes. Write for users, not engineers.
Process
- Read the input — either from a provided file path or from pasted commits/tickets in the argument.
- If a git repository path is provided, use
git log --oneline (read-only) to extract recent commits.
- Group changes into categories: New features, Improvements, Bug fixes.
- Translate each technical change into user-facing language.
- Infer the tone from context. If not clear, default to B2B Formal.
- Write the release notes.
- Save the output to a file in the current working directory as
release-notes-[version-or-date].md.
Output Format
[Release Title — descriptive, not just a version number]
Version: [if applicable]
Date: [release date]
New Features
For each feature:
- [Feature name] — What it does and why it matters to the user. Not how it was built.
Improvements
For each improvement:
- [What improved] — What the user will notice is better. Be specific.
Bug Fixes
For each fix:
- [What was fixed] — Describe the problem the user experienced, not the technical root cause.
Internal Notes (optional, only if requested)
- Technical details relevant for support teams, CSMs, or internal stakeholders
- Migration notes, feature flags, rollout percentages
- Known issues that weren't fixed in this release
Tone Guide
B2B Formal:
- Professional, clear, concise
- "We've introduced..." / "This release includes..."
- Suitable for enterprise customers, changelog pages
B2C Friendly:
- Warm, conversational, benefit-focused
- "You can now..." / "We fixed a bug that..."
- Suitable for consumer apps, in-app changelogs
Internal:
- Direct, technical context included
- Can reference ticket numbers, feature flags, team names
- Suitable for Slack updates, internal wikis
Rules
- Write for USERS, not engineers. Translate every change into user impact.
- "Fixed null pointer exception in auth service" becomes "Fixed an issue where some users couldn't log in."
- "Refactored payment module" becomes an Improvement only if users notice something — otherwise omit it.
- Internal refactors with zero user impact should be omitted from user-facing notes (move to Internal Notes if needed).
- Group related commits into a single release note item. Five commits about the same feature = one bullet point.
- Never expose internal system names, error codes, or infrastructure details in user-facing sections.
- If the tone is not specified, default to B2B Formal.
- Every item must answer: "Why should the user care?"
1---2name: release-notes3description: Turn git commits, tickets, or raw notes into user-facing release notes. Adjustable tone (B2B formal, B2C friendly, internal).4---56# Release Notes Generator78Transform raw engineering artifacts (git commits, Jira tickets, changelogs, raw notes) into polished, user-facing release notes. Write for users, not engineers.910## Process11121. Read the input — either from a provided file path or from pasted commits/tickets in the argument.132. If a git repository path is provided, use `git log --oneline` (read-only) to extract recent commits.143. Group changes into categories: New features, Improvements, Bug fixes.154. Translate each technical change into user-facing language.165. Infer the tone from context. If not clear, default to B2B Formal.176. Write the release notes.187. Save the output to a file in the current working directory as `release-notes-[version-or-date].md`.1920## Output Format2122### [Release Title — descriptive, not just a version number]23**Version:** [if applicable]24**Date:** [release date]2526---2728#### New Features29For each feature:30- **[Feature name]** — What it does and why it matters to the user. Not how it was built.3132#### Improvements33For each improvement:34- **[What improved]** — What the user will notice is better. Be specific.3536#### Bug Fixes37For each fix:38- **[What was fixed]** — Describe the problem the user experienced, not the technical root cause.3940---4142#### Internal Notes (optional, only if requested)43- Technical details relevant for support teams, CSMs, or internal stakeholders44- Migration notes, feature flags, rollout percentages45- Known issues that weren't fixed in this release4647## Tone Guide4849**B2B Formal:**50- Professional, clear, concise51- "We've introduced..." / "This release includes..."52- Suitable for enterprise customers, changelog pages5354**B2C Friendly:**55- Warm, conversational, benefit-focused56- "You can now..." / "We fixed a bug that..."57- Suitable for consumer apps, in-app changelogs5859**Internal:**60- Direct, technical context included61- Can reference ticket numbers, feature flags, team names62- Suitable for Slack updates, internal wikis6364## Rules6566- Write for USERS, not engineers. Translate every change into user impact.67- "Fixed null pointer exception in auth service" becomes "Fixed an issue where some users couldn't log in."68- "Refactored payment module" becomes an Improvement only if users notice something — otherwise omit it.69- Internal refactors with zero user impact should be omitted from user-facing notes (move to Internal Notes if needed).70- Group related commits into a single release note item. Five commits about the same feature = one bullet point.71- Never expose internal system names, error codes, or infrastructure details in user-facing sections.72- If the tone is not specified, default to B2B Formal.73- Every item must answer: "Why should the user care?"
Mehdibargach