Forge release notes derive from the changelog without contradicting it
Auto-generated release notes list merged pull requests, which repeats work the changelog already did better. Two divergent descriptions of one release is worse than one.
Observable check
the release body on the forge contains the corresponding changelog section without omissions or contradictory claims. It may add release-scoped installation, verification, migration, asset, or contributor details. Read it with gh release view <tag> --json body on GitHub, or from the description field of GET /projects/:id/releases/:tag_name on GitLab.
Where this comes from
No upstream source. This is oss-kit's own position, and the argument for it is below.
Neither Keep a Changelog nor either forge's release documentation says what a release body should contain, and GitHub's auto-generated notes list merged pull requests, which is the behaviour this rule argues against. Observed: a project that keeps both ends up maintaining two descriptions of one release, and the reader arriving from a release feed finds the weaker one first. Retire this rule if a forge learns to render a tag's changelog section itself.