# Minutes Release Notes

Draft user-facing Minutes release notes for a version from the commit range, recent...

- Repository: https://github.com/silverstein/minutes (1583 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

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

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

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

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

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

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

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

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

The rest: https://github.com/silverstein/minutes/blob/HEAD/.agents/skills/minutes/minutes-release-notes/SKILL.md