Draft release notes

This skill fires inside a release cut (stable or RC-line, both published under latest). The release-cutting agent runs it from the release/<version> worktree that publish-npm-version created, with the target version already known, and produces the committed notes file that is the GitHub Release body (the publish workflow ships it verbatim via gh release create --notes-file docs/releases/v<version>.md). There is no --generate-notes fallback, the file you author here is what every consumer reads.

The skill is prose-driven: there is no codemod or script to run. You, the agent, do the enumeration, the Linear-context lookup, the triage, and the writing directly, the same way record-upgrade-instructions walks you through authoring an upgrade entry rather than running one for you.

When to use

Run this skill when all of the following hold:

• A release is being cut (stable or 8.0.0-rc.N), the target version $NEXT is known (computed by publish-npm-version step 1, e.g. 8.0.0-rc.2).
• You are in the release/<version> worktree with the bumped root version and reviewed, assembled upgrade guides committed, following the upgrade instruction lifecycle.
• docs/releases/v$NEXT.md needs drafting or refreshing after new fragments were incorporated (the PR-mode release-notes gate, pnpm check:release-notes --mode pr, requires the notes file).

Do not run it for -dev.N or -beta.N builds: those create no GitHub Release and are not gated. Do not run it to backfill notes for an already-shipped release, the convention starts from the first release cut after it landed.

The two hard rules

These are project requirements, not style preferences. A draft that violates either is wrong even if everything else is perfect.

Rule 1, Never copy Linear content verbatim