minutes-release-notes

1# /minutes-release-notes
2 
3Draft 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.
4 
5## Inputs
6 
7Collect:
8 
9- the new version, such as `v0.22.0`
10- the previous stable tag, or an explicit starting ref
11- the target ref, normally `HEAD`
12- the release channel, normally stable or preview
13- any known breaking changes, migrations, compatibility notes, or contributor credits
14 
15Resolve missing refs from the repository instead of guessing:
16 
17```bash
18git describe --tags --abbrev=0
19git log <previous-tag>..HEAD --pretty='%s (%h)'
20```
21 
22When `HEAD` is already tagged, resolve the previous tag from its parent so the range does not collapse to zero commits:
23 
24```bash
25git describe --tags --abbrev=0 HEAD^
26```
27 
28Confirm both refs with `git rev-parse --verify` before drafting. If the version or range is ambiguous, ask one short question.
29 
30## Steps
31 
32### 1. Learn the current release voice
33 
34Read two or three recent stable releases before writing:
35 
36```bash
37gh release list --limit 5
38gh release view <recent-tag>
39```
40 
41Match 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.
42…