release-notes（リリースノート）
生のGit履歴を、人間が実際に読みたくなるリリースノートに変換します。
機能
- 2つのリファレンス（タグ、ブランチ、HEAD）間のコミットを差分表示
- 変更を種類別にグループ化：機能、修正、破壊的変更、雑務
- conventional-commit の
!マーカーおよびBREAKING CHANGE:フッターから破壊的変更を検出 - ハイライトセクション（ユーザーが実際に関心を持つ3～5の変更）を下書き
- GitHubリリースに対応したMarkdownを出力
使用法
# 次のリリースのノート（最新タグ -> HEAD）
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# 2つのタグ間
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
次に、エージェントに「これらのコミットから v1.3.0 のリリースノートを作成して」と依頼します。
または、GitHub CLI を使って、直接リリース下書きを作成することもできます：
# タグを作成し、差分からリリースノートを下書き
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# その後、このスキルで生成されたノートを編集します
プロセス
1. コミットを収集
git log <prev-tag>..<new-tag> --pretty=format:'%h|%s|%b|%an' --no-merges
マージコミットを別途含める（リポジトリがマージベースのフローを使用している場合）— マージのタイトルは、個々のコミットよりもPRをうまく要約できることがよくあります。
2. 各コミットを分類
| 接頭辞 / シグナル | セクション |
|---|---|
feat, feat! | 機能 |
fix | バグ修正 |
! または BREAKING CHANGE: | ⚠️ 破壊的変更（自身のセクションにも一覧表示） |
perf | パフォーマンス |
docs, chore, ci, refactor, test | 「その他」にグループ化、または省略 |
従来の接頭辞がないコミット：メッセージの内容で分類します。 疑わしい場合は、黙って削除するのではなく「その他の変更」に入れてください。
3. ハイライトを下書き
ソフトウェアのユーザーにとって最も重要な3～5の変更を選びます：
- ユーザーが気づく新しい機能
- ユーザーが対応しなければならない破壊的変更
- 広く報告されている問題の修正
それぞれを1つの平易な文で書きます。マーケティング用の形容詞は使いません。
4. ノートを書く
## v1.3.0
**ハイライト**
- ...
- ...
### ⚠️ 破壊的変更
- ...
### 機能
- ...
### バグ修正
- ...
### その他の変更
- ...
**完全なチェンジログ:** <prev-tag>...<new-tag>
5. 公開前の健全性チェック
- すべての破壊的変更が⚠️セクションに移行ヒントとともに表示されていること
- 内部専用の雑務がユーザー向け機能として表示されていないこと
- リポジトリの慣例に従って貢献者名がクレジットされていること
- バージョン番号がタグと一致していること
規約
- リポジトリに既存のリリースノートスタイルがあればそれに従うこと — 一貫性がどのテンプレートよりも優先されます。
- リポジトリが
gh release --generate-notesを使用している場合、その出力を下書きとして使用し、編集します。リストは正しいですが、ハイライトは正しくないことが多いためです。 - コミット範囲にない変更を決して作り出さないこと。範囲があいまいな場合は、推測せずにどのリファレンスを比較するかを尋ねること。