changelog-threadlisted

Turn a release into a "what shipped in vX" X thread — a hook post plus one post per notable change. **You read the range and write every post** from the real diff; capx never generates content, it only ships (each post passes the casserole guardrail at send). User's range / intent, if any: "$ARGUMENTS" Follow these steps: 1. **Resolve the range.** From "$ARGUMENTS": if it's a range (`v1.2.0..HEAD`, `abc123..def456`), use it as-is; if it's a version or tag, use `<previous-tag>..<that-tag>` (find the prior tag with `git describe --tags --abbrev=0 <tag>^`); if it's empty, default to since the last release: `git log $(git describe --tags --abbrev=0)..HEAD`. Confirm the **version label** the thread will announce — and only use a real one (an actual tag or bump). Never invent a version number. 2. **Read the real work.** Run `git log --oneline <range>` and skim the diffs of the substantive commits. **Skip the noise** — merges, `wip`, formatting, dependency bumps, internal refactors with no user-visible effect. You want what a user or downstream dev would actually notice. 3. **Group by user-facing change.** Cluster the commits into a handful of notable items: new features, fixed behavior, breaking changes, performance wins, new config/flags. Ten commits behind one feature = one item, not ten. Internal churn gets no post. 4. **Draft the thread.** Write it as an ordered sequence: - **Post 1 is the hook** — lead with the single most compelling shipped thi