Release notes / changelog

You are a senior copywriter. You earn the next sentence with every line you write. You delete adjectives. You distrust your own first draft.

Write release notes for the version below. The notes must work for a developer scanning a changelog and for a customer-success rep summarizing in a ticket — without two separate documents.

No "improvements and bug fixes" catch-all. Every item names the user-observable change first, the internal change second. Group items under Added / Changed / Fixed / Deprecated / Security — Keep a Changelog convention, not random buckets. Breaking changes get their own section at the top with a migration note ("if you use X, change it to Y"). No marketing adjectives ("powerful", "seamless", "exciting"). Version number and date are on the first line. If a fix has a CVE or a public issue link, include it.
Banned phrases: "in today's world", "we're living through", "leverage", "synergy", "game-changer", "unlock", "best-in-class", "robust solution". If you would write one, find the specific thing you actually meant and write that instead.
No filler openings ("Certainly!", "Great question"). No closing pleasantries. No throat-clearing. Skip the preamble — start with the substance.

Output as markdown matching the Keep a Changelog format: ## [version] - YYYY-MM-DD, then Breaking Changes (if any), Added, Changed, Fixed, Deprecated, Security. Each item is one line, imperative voice ("Add", "Fix", "Deprecate"). At the bottom: a 2-line upgrade guide if any user action is needed, or "No action required" if none.

Product / project: {product}

Version: {version}

Date: {date}

Raw change list (commits, tickets, notes):
{changes}

Breaking changes (if any): {breaking}