Add

Writing & Editing

Write Release Notes From a Changelog

Rewrites raw commits or changelog entries as user-facing release notes grouped by benefit, with breaking changes called out first.

Designed for general-purpose AI assistantsPublished November 2026

Customize

Fill in the fields and the prompt updates. What you type stays in this page and is never saved or sent.

Preview

Turn the raw changes below into release notes for people who use the product, not people who build it.

Product: {{product}}
Version and date: {{version and date}}
Audience: existing customers
Tone: clear, friendly, no hype
Where the notes will appear: in-app and email

Raw changes (commit messages, tickets or changelog lines):
{{raw changes}}

Process:
1. Sort every item into one of: Breaking or action required, New, Improved, Fixed, or Internal. Internal items (refactors, dependency bumps, test changes) must not appear in the notes. Show me the list of items you excluded so I can overrule you.
2. Write each remaining item as one sentence that starts with what the user can now do or what no longer goes wrong. No ticket numbers, function names or jargon.
3. Put Breaking or action required first, with exactly what the user must do and by when. Only include a date if one appears in the raw changes.
4. Merge items that are the same change described twice.

Output: a headline of at most 10 words, a two-sentence introduction, the grouped list, and one closing line pointing to help or feedback.

Rules: do not invent features, dates, performance numbers or benefits that the raw changes do not support. If an item is too vague to describe honestly, list it under "Needs clarification" with the question to ask the developer. Do not describe a fix as complete if the raw text says it is partial.

3 required fields are empty and will stay as a {{placeholder}} in the copied text.

How to use it

  1. Paste the raw list including the ugly commit messages. The sorting step needs to see everything to decide what to keep.
  2. Look at the excluded items first. Something labeled internal may be user-visible, and you know the product better than the assistant does.
  3. Answer the 'Needs clarification' questions with the developer before publishing, then paste the answers back and regenerate.
  4. Adjust the audience and tone to publish the same changes in different places, such as a short in-app note and a longer email.

Example output

Illustrative only. Real answers depend on your input and the assistant you use.

Headline: Faster exports and a fix for duplicate invoices

Introduction: This release makes exporting large reports quicker and fixes a bug that could create duplicate invoices. One change needs action from API users.

Breaking or action required
- The /v1/invoices endpoint now requires the new api-version header. Add it to your requests; requests without it will stop working on December 1.

New
- You can now schedule a report to be emailed every Monday.

Improved
- CSV exports of large reports finish noticeably faster.

Fixed
- Duplicate invoices are no longer created when a payment notification is delivered twice.

Excluded as internal: bump lodash to 4.17.21; rename PaymentService; add tests for scheduler.

Needs clarification: "improve export perf" has no figures. Ask whether a number can be shared.

Questions or feedback? Reply to this email or visit the help center.

Tips

The excluded list is the quality check. The most common mistake is publishing an internal change as a feature, or hiding a user-visible change because its commit message sounded technical.

Do not let the assistant add numbers like "twice as fast" unless your team measured them. If you did, put the measurement in the raw changes.

Keep older release notes in the conversation so the new ones follow the same wording and structure.

Back to the Prompt Library

Related prompts

  • Coding & Software

    Write a Commit Message From a Diff

    Writes a Conventional Commits style message from a diff, and tells you when the diff is really two commits that should be split.

    Customizable fields
    5 fields

  • Coding & Software

    Write a Pull Request Description

    Turns a diff and a ticket into a pull request description with context, changes, risk and a test plan that reviewers can follow.

    Customizable fields
    6 fields

  • Writing & Editing

    Explain a Technical Topic to Non-Experts

    Explains a technical idea to a specific non-expert audience using one analogy, plain terms and an honest note on where the analogy breaks.

    Customizable fields
    6 fields