Problem
SwiftASB release prep found that the repo-maintenance release scripts create GitHub releases with gh release create --generate-notes by default. When a repo carries a checked-in release-note draft such as docs/releases/v1.7.2.md, the release flow does not use that file for the GitHub release body.
Expected Behavior
The shared repo-maintenance release flow should prefer a checked-in release-note file when present, for example:
docs/releases/<tag>.md, such as docs/releases/v1.7.2.md- possibly
docs/releases/<version>.md, such as docs/releases/1.7.2.md
If no release-note file exists, falling back to GitHub-generated notes is fine, but the script should log that fallback clearly.
Why It Matters
Patch releases often need curated sections for what changed, breaking changes, migration notes, and verification. Generated notes are useful, but they can miss license changes, compatibility-window details, and maintainer-reviewed migration guidance.
Concrete Example
In SwiftASB v1.7.2 prep, the repo has docs/releases/v1.7.2.md, but the standard release path and the dispatch GitHub-release step both used --generate-notes. SwiftASB patched its local copy to prefer --notes-file when a matching file exists; the shared repo-maintenance skill/script should get the same update.
Problem
SwiftASB release prep found that the repo-maintenance release scripts create GitHub releases with
gh release create --generate-notesby default. When a repo carries a checked-in release-note draft such asdocs/releases/v1.7.2.md, the release flow does not use that file for the GitHub release body.Expected Behavior
The shared repo-maintenance release flow should prefer a checked-in release-note file when present, for example:
docs/releases/<tag>.md, such asdocs/releases/v1.7.2.mddocs/releases/<version>.md, such asdocs/releases/1.7.2.mdIf no release-note file exists, falling back to GitHub-generated notes is fine, but the script should log that fallback clearly.
Why It Matters
Patch releases often need curated sections for what changed, breaking changes, migration notes, and verification. Generated notes are useful, but they can miss license changes, compatibility-window details, and maintainer-reviewed migration guidance.
Concrete Example
In SwiftASB
v1.7.2prep, the repo hasdocs/releases/v1.7.2.md, but the standard release path and the dispatch GitHub-release step both used--generate-notes. SwiftASB patched its local copy to prefer--notes-filewhen a matching file exists; the shared repo-maintenance skill/script should get the same update.