minutes-release-notes

name	minutes-release-notes
description	Draft user-facing Minutes release notes for a version from the commit range, recent GitHub releases, and the repository release checks. Use when the user asks to write, generate, prepare, revise, or review release notes or a changelog for a Minutes version.
triggers	["write release notes","generate release notes","prepare release notes","draft release notes","review release notes","release notes for x"]
user_invocable	true
metadata	{"display_name":"Minutes Release Notes","short_description":"Turn a version's commit range into polished, release-ready Minutes notes.","default_prompt":"Draft release notes for the requested Minutes version from the real commit range and current release conventions.","site_category":"Artifacts","site_example":"/minutes-release-notes v0.22.0","site_best_for":"Prepare accurate, user-facing release notes with install links and migration checks.","site_visible":false}
assets	{"scripts":[],"templates":[],"references":[]}
output	{"claude":{"path":".claude/plugins/minutes/skills/minutes-release-notes/SKILL.md"},"codex":{"path":".agents/skills/minutes/minutes-release-notes/SKILL.md"}}
tests	{"golden":true,"lint_commands":true}

/minutes-release-notes

Draft release notes that explain why a Minutes release matters without making users decode the commit history. Produce a draft only. Do not create, edit, or publish a GitHub release unless the user explicitly asks.

Inputs

Collect:

• the new version, such as v0.22.0
• the previous stable tag, or an explicit starting ref
• the target ref, normally HEAD
• the release channel, normally stable or preview
• any known breaking changes, migrations, compatibility notes, or contributor credits

Resolve missing refs from the repository instead of guessing:

git describe --tags --abbrev=0
git log <previous-tag>..HEAD --pretty='%s (%h)'

When HEAD is already tagged, resolve the previous tag from its parent so the range does not collapse to zero commits:

git describe --tags --abbrev=0 HEAD^

Confirm both refs with git rev-parse --verify before drafting. If the version or range is ambiguous, ask one short question.

Steps

1. Learn the current release voice

Read two or three recent stable releases before writing:

gh release list --limit 5
gh release view <recent-tag>

Match the current heading hierarchy, amount of detail, install wording, contributor treatment, and overall tone. Prefer concrete user outcomes, honest limitations, and short technical explanations. Do not copy stale version-specific claims.

Never use em dashes in the draft. Rewrite with commas, colons, parentheses, or separate sentences. This is a repository release convention, not an optional style preference.

2. Build the change ledger

Read the full range and inspect touched files when a subject is unclear:

git log <previous-tag>..HEAD --pretty='%s (%h)'
git diff --stat <previous-tag>..HEAD
git show --stat <commit>

Classify every relevant commit by conventional prefix:

• feat -> Features
• fix -> Fixes
• perf ->