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