releaselisted

# Release body This skill is the writing surface for cutting a release. It produces the **public-facing GitHub release body**: short, curated, scannable. The thing your users see on `github.com/<org>/<repo>/releases` and (if you've wired it) what an update command prints after upgrade. This skill stops at a ratified body. The technical cascade (version bumps, CHANGELOG dating, tag push, cargo-dist or equivalent, smoke tests) is engineering's job; the placeholders are demarcated below. ## Flow Six beats, in order. 1. **Read the merge surface.** `git log --oneline <last-tag>..origin/main` and `gh pr list --state merged --search "merged:>=<date>"` to gather the PRs that landed. Read `CHANGELOG.md` `[Unreleased]` if engineering keeps one; that's the exhaustive surface, you'll write the curated short version. 2. **Sort into tiers.** Tier 1: the changes that genuinely change what a user can DO (verbs, not nouns). Tier 2: the quiet wins. Cut: engineering-only changes (test deflakes, build hygiene, internal refactors). Hold: known-broken features; never lead the public with a foot-gun. 3. **Pick the shape.** Count weighty Tier-1 features. Three means **triplet shape**. Zero to two means **bullets shape**. A single fix means **hotfix shape**. See *Shape variants* below. The shape determines headline and body structure. 4. **Read the last shipped body side-by-side.** Match its rhythm: word count per paragraph, sentence count, bullet density. Drift on rhythm is the most common reas