Our release notes swung between robotic ("Bumped dependency versions") and try-hard ("We've been cooking up something special"). Neither felt like us.
I built a prompt that takes a tone sample from our best past release note and generates new ones in that exact register, with a strict structure so they stay skimmable. Anchoring to our own past voice beat any adjective-based tone instruction I tried.
Does anyone gate this on whether a release is actually worth announcing?
Write release notes for version {VERSION} from the change list below. Match this tone sample from our previous notes exactly: {PASTE ONE GOOD PAST RELEASE NOTE}.
Structure:
- A one-line intro that states the single most important thing in this release. If nothing is exciting, say something honest and low-key, do not manufacture hype.
- 'Highlights': up to 3 changes users will actually notice, each 1-2 sentences, focused on what they can now do.
- 'Also in this release': terse bullets for the rest.
- 'Fixes': terse bullets, user-facing symptoms not internal causes.
Rules: no 'we're thrilled/excited to announce', no emoji unless the tone sample uses them, no marketing verbs (unlock, supercharge). If the entire release is internal/maintenance, output a two-line honest note and skip the Highlights section. Keep our voice; when unsure, be understated.We do gate it. A one-line pre-check prompt classifies the release as 'announce / mention / silent' based on whether any user-facing behavior changed. Silent releases just get a version tag and no notes. Stopped us from emailing users about a CI config change dressed up as news.
Pre-step: classify the release as ANNOUNCE (new user-facing capability), MENTION (fixes/improvements only), or SILENT (internal only). Only ANNOUNCE gets a full note.