# Release Notes

Generate and publish concise, evidence-based notes in the body of the latest existing...

- Repository: https://github.com/kenryu42/cc-safety-net (1883 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kenryu42/cc-safety-net --skill release-notes -g -a claude-code -y`
Codex: `npx skills add kenryu42/cc-safety-net --skill release-notes -g -a codex -y`
Cursor: `npx skills add kenryu42/cc-safety-net --skill release-notes -g -a cursor -y`
Gemini CLI: `npx skills add kenryu42/cc-safety-net --skill release-notes -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add kenryu42/cc-safety-net`

## Description

Generate and publish concise, evidence-based notes in the body of the latest existing GitHub Release. Use only when the user explicitly invokes `$release-notes` or explicitly asks to update the latest existing GitHub Release body. Do not invoke for general release planning, changelog, tag, or version tasks.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

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

2. Confirm that `gh` is available:

   ```sh
   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:

   ```sh
   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:

   ```sh
   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:

The rest: https://github.com/kenryu42/cc-safety-net/blob/HEAD/.claude/skills/release-notes/SKILL.md