release-notes

Release Notes

Update only the body of the latest existing GitHub Release. Treat the repository diff as the source of truth. Use pull requests and commits only as supporting evidence.

Safety rules

• Use gh for all GitHub Release, pull request, issue, and API operations. Use git fetch only when required tag objects or history are missing.
• Do not create or delete a release.
• Do not change a tag, title, target, draft state, prerelease state, latest-release state, or other release metadata.
• Do not publish a draft.
• Do not use a new release as a fallback when no release exists.
• Do not infer release order from version text, semantic versions, or Git tag order.
• Stop when required evidence is unavailable. Do not publish partial or speculative notes.
• Treat the notes file as a full replacement for the current release body, not as text to append.

1. Verify prerequisites

Run all checks from the repository that the user wants to release:

1. Confirm that the current directory is in a Git worktree:

   git rev-parse --is-inside-work-tree
   

2. Confirm that gh is available:

   command -v gh
   

3. Confirm that gh can resolve and access the current GitHub repository. Save its URL and get the GitHub host from it:

   REPO_URL="$(gh repo view --json url --jq '.url')"
   GH_HOSTNAME="${REPO_URL#*://}"
   GH_HOSTNAME="${GH_HOSTNAME%%/*}"
   

4. Use the repository URL to get its GitHub host. Confirm the active account for that host:

   gh auth status --active --hostname "$GH_HOSTNAME"
   

Stop with a clear error if a check fails. Do not initialize a Git repository, change authentication, or select another repository as a fallback.

2. Select the release range

Use GitHub's descending release-list order as the release sequence. Include drafts and prereleases because they are existing releases:

gh release list --limit 2 --order desc \
  --json tagName,name,createdAt,publishedAt,isDraft,isPrerelease,isImmutable,isLatest