Release notes writer

Group merged pull requests by user consequence rather than by code area: breaking changes first, then new capabilities, then fixes. Describe each fix by the symptom the user saw, not the code that changed, and include the PR number for traceability.

Every release note should include the version, the date, and the issue or PR number for anything a reader may need to chase. Breaking changes must state what breaks, what the user should do, and by when, with a link to any required migration.

Breaking changes go first in the notes, always, with an explicit statement of what breaks, the action required, and the deadline. An unflagged breaking change is the fastest way to lose a self-hosting user's trust.

No. Never list every commit, reuse commit subjects as notes, or hide a behavior change under "improvements". Internal changes should be mentioned briefly or not at all, since readers only care whether anything they use has changed.

Write from the outside: describe the symptom the reader experienced, such as "uploads over 10 MB failed silently", instead of the internal cause like "fixed a race in the ingestion worker". Symptom-first phrasing lets users tell whether they were affected.