release-notes-generator について
release-notes-generator は、Git の tag と HEAD の間の変更から形式化されたリリースノートを作成するスキルです。リリースを準備する開発者向けに、変更の分類と破壊的変更の検出を行い、tag と GitHub Release の作成も選択できます。
主な機能
- 01前回の tag と HEAD を比較
- 02コミット種別ごとに変更を分類
- 03破壊的変更を検出
- 04形式化されたリリースノートを生成
- 05annotated tag と GitHub Release を任意で作成
活用シーン
- 01新バージョンのコミット変更を要約
- 02コミット履歴から CHANGELOG.md を生成
- 03リリース前に破壊的変更を確認
- 04リリースノートを作成してリリースを公開
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ wu529778790/ shenzjd-skills --skill release-notes-generatorインストール後、Claude Code で/release-notes-generatorを入力して読み込まれたか確認します。
同梱ファイルREADME.mdtemplates/release-notes.md
詳細
リリースノートジェネレーター
タグを付けると、コードの変更を自動で比較し、標準化されたリリースノートを生成します。
概要
前回のタグから現在の HEAD までの Git 履歴を比較し、Conventional Commits の分類(feat/fix/docs/refactor/chore)に従って変更を分類し、破壊的変更を自動検出して、標準化されたリリースノートを生成します。オプションで Git タグと GitHub Release を作成できます。
使用する場面
- タグまたはリリースを作成したい場合
- バージョン間の変更を要約したい場合
- changelog、リリースノート、バージョンに関するドキュメントについて言及した場合
/release-notesを入力した場合- コミット履歴から CHANGELOG.md を生成したい場合
- 分類された変更を含むリリースを準備したい場合
- リリース前に破壊的変更を自動検出したい場合
- リリースノート付きの注釈付き Git タグを作成したい場合
使用しない場面:
- Git ログを表示したいだけの場合
- 既存のリリースノートを変更したい場合
- 複数のリポジトリの changelog を生成したい場合(別のツールが必要です)
- CI/CD でリリースノートを自動生成したい場合(semantic-release または release-please をご検討ください)
基本的なパターン
ステップ 1:バージョン番号を検出する
最新のタグ(git describe --tags --abbrev=0)を取得し、ユーザーが指定したバージョン番号を使用するか、変更の種類に基づいて提案します。破壊的変更がある場合は major、新機能がある場合は minor、バグ修正のみの場合は patch を提案します。
ステップ 2:変更を比較する
PREV_TAG=$(git describe --tags --abbrev=0)
git log ${PREV_TAG}..HEAD --oneline
git diff ${PREV_TAG}..HEAD --stat
ステップ 3:変更を分類する
| カテゴリ | プレフィックス | 説明 |
|---|---|---|
| 🚀 Features | feat: | 新機能 |
| 🐛 Bug Fixes | fix: | 修正 |
| 📝 Documentation | docs: | ドキュメント |
| ♻️ Refactor | refactor: | リファクタリング |
| 🔧 Chores | chore: | ビルド/ツール/設定 |
| ⚡ Performance | perf: | パフォーマンス最適化 |
| 🧪 Tests | test: | テスト |
| 🔒 Security | security: | セキュリティ修正 |
| 💥 Breaking Changes | BREAKING CHANGE または ! サフィックス | 破壊的変更 |
破壊的変更の検出ルール:
- コミットメッセージに
BREAKING CHANGE:またはBREAKING CHANGES:が含まれている - コミットタイプの後に
!が付いている(例:feat!:、fix!:) - コミット本文に破壊的変更の説明が含まれている
コミットメッセージ内の Conventional Commits のプレフィックスを読み取り、プレフィックスがない場合はファイルの変更から推測します。
ステップ 4:リリースノートを生成する
templates/release-notes.md テンプレートを使用して、バージョン番号、日付、分類された変更の一覧、diff リンクを含むリリースノートを生成します。
ステップ 5:タグ/リリースを作成する(任意)
注釈付きタグと GitHub Release を作成するか、ユーザーに確認します。このスキルで生成したリリースノートをリリース本文として使用します。
# 创建 annotated tag
git tag -a "$TAG" -m "$TAG"
# 创建 GitHub Release,使用生成的 release notes
gh release create "$TAG" --title "$TAG" --notes-file release-notes.md
クイックリファレンス
/release-notes # 交互式,自动建议版本号
/release-notes v1.1.0 # 指定版本号
/release-notes --dry-run # 只生成不创建 tag
| パラメーター | 説明 | デフォルト値 |
|---|---|---|
version | バージョン番号 | 自動提案 |
--dry-run | 生成のみ行い、作成しない | false |
よくある間違い
| 間違い | 正しい方法 | 理由 |
|---|---|---|
| コミット数だけを見る | 実際のコード変更を分析する | コミット数は変更の規模を表すとは限りません |
| 破壊的変更を無視する | 💥 を使って明確に示す | ユーザーが互換性のない変更を把握できるようにする必要があります |
| 分類せず、すべてまとめて記載する | feat/fix/docs ごとにグループ化する | 読みにくくなります |
| リリースノートが長すぎる | 重要な変更と diff リンクに絞る | ユーザーは細部をすべて確認する必要はありません |
| プレフィックスのないコミットをそのまま無視する | ファイルの変更から種類を推測する | すべてのチームが Conventional Commits を厳密に使用しているわけではありません |
| semver のルールを無視してバージョン番号を付ける | major.minor.patch の規則に従う | 任意の番号付けは依存関係の管理を混乱させます |
| 破壊的変更が API に与える影響を確認しない | 影響を受けるインターフェースと移行方法を明記する | ユーザーがアップグレード後に初めて破壊的変更に気付くのを防ぎます |
| リリースノートに diff リンクを含めない | ${PREV_TAG}...${TAG} の比較リンクを追加する | ユーザーが具体的なコード変更を確認しやすくなります |