Write Human-Friendly Release Announcements from Git Tags

Commit messages are written for developers. GitHub Release notes are read by users. Claude bridges the gap — pipe your tag-to-tag log and get prose that non-developers can actually understand.

git log v1.4.0..v1.5.0 --oneline | claude -p "
Write user-facing release notes for v1.5.0. Focus on the impact
of each change, not the implementation details. Write for a technical
audience but not a git audience. Skip merge commits and dependency bumps.
"

The output is release-ready copy:

## What's new in v1.5.0

This release focuses on checkout reliability and a long-requested
export feature.

**Product variants now support custom attributes per SKU** — you can
define per-variant metadata without adding new columns.

**Bulk CSV export from the orders dashboard** is now available for
all account tiers.

**Fixed:** Checkout no longer fails when a coupon is applied after
changing the cart currency — a bug that affected roughly 3% of
discount-code purchases.

For richer context, pipe the full diff rather than just the log — Claude can explain the impact of changes rather than just listing them:

git diff v1.4.0..v1.5.0 -- src/ | claude -p "
Summarise the user-facing changes as a GitHub Release announcement.
Lead with the headline improvement. Keep it under 200 words.
"

This is distinct from maintaining a CHANGELOG.md (which tracks every change in structured format). Release notes are your public-facing story for a specific release.

Ship polished release notes every time — your users will notice, and your support queue will thank you.