Mole release notes

This skill drives the curated-notes step that runs after release.yml has finished. The workflow creates the GitHub Release with assets but with generate_release_notes: false, so notes must be added in a follow-up gh release edit (never gh release create, the release already exists, and create will conflict).

Inputs to gather

Before drafting, confirm:

1. Version. Capital V, e.g. V1.38.0. Lowercase v does not trigger the workflow and may indicate a botched tag.
2. CodeName + emoji. Ask the user. The title format is V<version> <CodeName> <emoji>.
3. Release commit range. git log <previous-tag>..V<version> --oneline gives the raw material.
4. User-visible behavior changes. Scan the full commit message bodies (not just subjects) for narrowed detection, removed features, or controlled regressions. These belong in notes even when they are not bug-fix-shaped, because users will encounter the changed boundary in production.
5. Issue reporters and PR contributors in this cycle. Use the merged PRs and fixed issues in the release range. Keep it short, for example Issue reporters and PR contributors this cycle: @a · @b. Exclude tw93 and bots.
6. Verify release exists. gh release view V<version> --repo tw93/Mole --json id,name should return non-empty. If it doesn't, the workflow hasn't finished, wait, don't gh release create.

Pre-flight (cross-check against AGENTS.md)

These should already be true if the tag was pushed correctly. Confirm before publishing notes: