Skip to content
Back to skills

Release Notes

ASecurity

Draft release notes for a tag by grouping commits since the previous tag using Conventional Commit prefixes.

  • 56 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 20, 2026
toolsrustshellgit

Works with

  • cli

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add block/proto-fleet --skill release-notes --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Release Notes?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Release Notes
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/block-release-notes/badge)](https://www.skillsdirectory.com/skills/block-release-notes)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: release-notes
description: Draft release notes for a tag by grouping commits since the previous tag using Conventional Commit prefixes.
argument-hint: <version> (e.g. v0.2.0)
---

Draft release notes for the version supplied with the skill invocation. Save
that value as `version`. The repo's `release.yml` workflow
fires on `v*` tags matching `vMAJOR.MINOR.PATCH(-prerelease)?`.

## Steps

1. **Validate `version` as a tag string before any shell call.** It must
   match `^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9._-]+)?$` (the same pattern
   the `release.yml` workflow validates against). If it doesn't match,
   stop and ask the user for a clean tag. Treat `version` as untrusted
   data and never expand it into a shell command containing other text.
2. Determine the previous tag with `git describe --tags --abbrev=0 --match 'v*' HEAD`.
   If `version` is the previous tag's successor on `main`, use the previous
   tag as the range start; otherwise ask the user for the comparison base.
3. List commits in range with
   `git log --pretty=format:"%h %s" <previous>..HEAD`.
4. Group by Conventional Commit type:
   - **Features** — `feat:`, `feat(scope):`
   - **Fixes** — `fix:`
   - **Refactors** — `refactor:`
   - **Docs** — `docs:`
   - **Chores / CI / deps** — `chore:`, `ci:`, `build:`, `chore(deps):`
   - **Tests** — `test:`
   - **Other** — anything not matching the above
5. For each entry, keep the short description; strip the prefix and scope.
   Append the PR number if present (`(#123)`) as a link target in the
   final draft.
6. Surface anything that looks load-bearing for users — schema migrations,
   CLI flag changes, breaking proto changes, deprecation removals — in a
   **Breaking changes** block at the top of the draft if applicable.
7. Output a markdown draft suitable for the GitHub release body. Do NOT
   create the tag, push it, or call `gh release create` — stop after
   presenting the draft.

## Notes

- Full releases must be on `main` per `release.yml`. Prereleases (with
  `-rc`, `-beta`, etc.) can come from any commit.
- If the diff between the previous tag and HEAD is empty, say so and stop.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.