Release Notes and Changelog

Turn a list of merged changes into release notes users read: benefit-led highlights, honest breaking-change warnings, and a clean changelog.

Write release notes for [PRODUCT] version [VERSION].

Raw changes (commits, PR titles, ticket titles, or notes):
"""
[PASTE]
"""

Audience: [e.g. "non-technical end users" / "developers using our API" / "IT admins who deploy this"]
Release type: [regular / major / hotfix]

Produce two documents.

**A. Release notes (what users read):**
- One-sentence summary of what this release is about. If the release has no theme, say what the biggest single change is instead of inventing one.
- **Highlights**: 2-5 items. Each one leads with what the user can now do, then how to get to it. Write "You can now export a filtered view to CSV from the table toolbar", not "Added CSV export functionality".
- **Breaking changes and required actions**: put this above the fold if any exist, never at the bottom. For each: what breaks, who is affected, what to do, and by when. If there are none, write "None".
- **Fixes**: group by area. One line each, describing the symptom the user saw, not the internal cause. "Fixed timestamps showing in UTC on the activity log" beats "Fixed tz bug in ActivityLog.tsx".
- **Known issues**: only real ones. Omit the section if empty.

**B. Changelog entry (Keep a Changelog format):** grouped under Added, Changed, Deprecated, Removed, Fixed, Security. One line per change, imperative and terse.

Rules:
- Every item must trace to something in the raw changes. If a change is too internal to matter to this audience, drop it from A and keep it in B.
- If a change is ambiguous from its title alone, mark it [UNCLEAR: title] rather than guessing at user impact.
- No marketing adjectives. "Faster" needs a number or it needs to be cut.

How to use

Commit titles are written for other engineers, which is why raw changelogs read as noise to users. The rewrite rule ('what you can now do', symptom instead of cause) is the entire job. Putting breaking changes above the highlights costs you nothing and saves support tickets: users who miss a migration note blame the product, not their reading. Run the [UNCLEAR] items past whoever wrote them rather than shipping a guess about user impact.

More writing prompts

Rewrite the text below in plain language for [AUDIENCE, e.g. "patients with no medical background" / "customers reading a policy update" / "new hires on day one"].

Target reading level: [e.g. "8th grade" / "as simple as the content allows"].

How to rewrite:
- Lead with what the reader must DO or what happens to them. Background comes af

Plain Language Rewrite

Rewrite dense policy, legal, medical, or technical text at a target reading level without losing a single obligation or number.

Writingbeginner

Write a comparison article for the query: [e.g. "Notion vs Obsidian" / "best Mailchimp alternatives"].

Options to compare: [LIST 2-8 OPTIONS]
Who is searching this: [READER + WHAT THEY ARE TRYING TO DECIDE]
My relationship to these products: [e.g. "I make one of them" / "I use two of them daily" / "none, I am researching"]
Facts I can su

Comparison Article

Write an honest X vs Y or best alternatives article: real differentiators, a decision table, and a clear pick for each type of reader.

Writingintermediate

Build an FAQ page for [PRODUCT/SERVICE/TOPIC].

Real questions people ask me:
"""
[PASTE SUPPORT TICKETS, SALES CALL NOTES, SEARCH QUERIES, OR COMMENTS. RAW IS FINE.]
"""

Facts I can state as true: [PRICING, POLICIES, LIMITS, TIMELINES]

Do this:
1. **Cluster** the raw questions into distinct questions people actually ask. Merge duplicat

FAQ Page From Real Questions

Turn support tickets and sales objections into an FAQ page that answers in the first sentence and is structured for AI search engines.