Release notes
The user-facing summary of what a version added, changed, fixed, removed, and now requires people to do.
See it
What it is
Release notes tell users what changed in a specific version and why they should care. They turn internal tickets and commits into recognizable outcomes: a new control, a fixed failure, a changed workflow, or a breaking requirement. Keep a Changelog gives teams a useful set of headings such as Added, Changed, Fixed, and Removed.
Write them when a release changes what users can do, see, depend on, or need to prepare for. Put breaking changes and required actions first, link to migration steps, name the affected surface, and describe the result in the user's language rather than copying an issue title.
Gotcha: a commit log is raw material, not release notes. 'Refactored auth service' tells a user nothing, while 'Sign-in no longer loops after a password reset' names the repaired experience. Do not hide removed behavior under 'improvements', and do not claim a bug is fixed unless the released version contains the fix.
Ask AI for it
Turn these merged pull requests and issue summaries into release notes using Keep a Changelog categories: Added, Changed, Deprecated, Removed, Fixed, and Security. Apply Semantic Versioning 2.0.0 to identify the version impact, put breaking changes and migration actions first, and translate each internal ticket into a user-visible outcome. Include the version, ISO 8601 release date, affected surface, required action, and links supplied in the source. Do not invent fixes, dates, links, or benefits.