generate-releaselisted

# Generate Release Write release notes that describe **what actually changed in this release**, derived from the commit / PR / use-case diff since the previous tag. This skill exists to kill a specific failure mode: release bodies that are copied forward release after release, so the notes keep "talking about the same crypto change for ages" while the real changes go undocumented. Every line you emit must be traceable to a change in *this* tag's range. The output has exactly two sections, each a **bullet list**: - `## New features` — one bullet per feature; **each** bullet up to **200 words**. - `## Bugfixes` — one bullet per fix; **each** bullet at most **50 words**. The word caps are **per individual bullet**, not per section. Every bullet **links to the use case(s) it came from** wherever a use case exists. ## Hard rules (the whole point of this skill) 1. **Never read, copy, or paraphrase the previous release's notes/body.** Do not run `gh release view <prev> --json body`. Generate solely from the code/commit diff in this release's range. If you find yourself reusing a sentence from an older release, that is the exact bug this skill prevents — stop and re-derive from the diff. 2. **Every bullet traces to a change in the range.** No carried-over items, no boilerplate, no aspirational/roadmap entries. 3. **No fabrication.** If a section has nothing in the range, write the explicit empty marker (below) — never invent content to fill space. 4. **Respect the per-bullet wo