1. Capture messy truth first
Start from the PR titles, commit subjects, or the notes you already typed in Slack. Do not polish yet. One idea per line. Include the crashes and the user-visible wins. Drop pure internal noise later (dependency bumps, pure refactors) unless customers feel them.
2. Rewrite for humans, not for git log
Each bullet should answer: what changed for the person using the product? Prefer complete sentences. Prefer benefits and outcomes over ticket IDs. Never invent features you did not ship - honesty is the product.
3. Tell the same story four ways
- Changelog - scannable, versioned, repo-native.
- Customer email - subject that earns an open, short lead, then bullets, then a human sign-off.
- Social posts - announcement, benefit hook, soft ask for what to polish next.
- GitHub Release - what's new + changes list for the tag page.
4. Ship the pack the same day you tag
The cost of waiting is silent users. Copy the changelog into the repo, the email into your ESP, one social post into your timeline, and the GitHub body into the release draft before you context-switch.
5. Keep a lightweight history
Save what you shipped. ShipNote keeps the last few packs in this browser so you can restore and tweak tone. Paid Launch Pack unlocks full markdown export for that launch period without a subscription.
What this is not
Not a legal-reviewed release management suite. Not multi-language localization CMS. Not a place to invent marketing claims. If you already write release notes sometimes, ShipNote is the packaging step between "merged" and "told people."