release-notes

release-notes

Git の履歴から変更履歴のエントリーと GitHub リリースを生成します。

インストール

claude skill add --from https://github.com/thatrebeccarae/claude-skills/release-notes

使用する場面

• リリースを作成する：リリース可能なコミットがあり、変更履歴のエントリーや GitHub リリースが必要な場合。
• 月次の変更履歴を更新する：定期的に変更履歴を更新しており、前回のエントリー以降のすべての変更を記録する必要がある場合。
• 遡及的に変更履歴を作成する：既存のプロジェクトに CHANGELOG.md がなく、Git の全履歴から生成したい場合。

使い方

変更履歴のエントリーを生成する

/release-notes changelog [repo-path]

最後のタグ以降のコミットを読み取り、分類して、新しいエントリーを CHANGELOG.md の先頭に追加します。

変更履歴のエントリーと GitHub リリースを作成する

/release-notes release [repo-path] [version]

changelog のすべての処理を行った後、gh release create を使って GitHub リリースを作成します。version が省略された場合、検出された変更に基づいてバージョンを提案します。

遡及的に完全な変更履歴を生成する

/release-notes init [repo-path]

タグの履歴全体（タグがない場合はコミット履歴全体）をたどり、CHANGELOG.md を一から生成します。

手順

ステップ 1 — 最後のタグまたはリリースを見つける

git describe --tags --abbrev=0 を実行して最新のタグを見つけます。タグが存在しない場合は、最初のコミットを開始点として使用します。gh release list --limit 1 と照合し、ローカルのタグと異なる可能性がある GitHub リリースを確認します。

ステップ 2 — 最後のタグ以降のコミットを収集する

git log <last-tag>..HEAD --pretty=format:"%H %s" --no-merges

各コミットメッセージから、Conventional Commits のプレフィックス（type(scope): description）を解析します。Conventional Commits の形式に従っていないコミットについては、元のメッセージを記録します。

ステップ 3 — マージされた PR を確認する

gh pr list --state merged --search "merged:>YYYY-MM-DD" --json number,title,labels,mergedAt --limit 200

最後のタグの日付を締め切りとして使用します。PR のタイトルをコミットメッセージと照合し、重複を避けます。PR のタイトルはコミットメッセージより明確な説明になっていることが多いため、コミットがマージ済みの PR に関連付けられている場合は、PR のタイトルを優先します。

ステップ 4 — 変更を分類する

各コミットまたは PR を変更履歴のカテゴリに対応付けます。

プレフィックス／シグナル	カテゴリ
feat、feature	追加
fix	修正
本文中の BREAKING CHANGE または ! サフィックス（例：feat!:）	破壊的変更
docs	ドキュメント
refactor、perf	変更
chore、ci、build	メンテナンス
deprecate	非推奨
remove	削除
security	セキュリティ

Conventional Commits が使われていない場合：コミットメッセージの内容を分析してカテゴリを推測します。「add」、「fix」、「remove」、「update」、「refactor」、「document」などのキーワードを探します。分類が曖昧なコミットは変更にまとめ、人による確認が必要なものとして明示します。

ステップ 5 — バージョンの更新を提案する

セマンティック バージョニングのルールを適用します。

• 破壊的変更がある場合は、メジャーバージョンを更新します。
• 追加エントリーがあり、破壊的変更がない場合は、マイナーバージョンを更新します。
• 修正、変更、またはメンテナンスのみの場合は、パッチバージョンを更新します。

理由を添えて提案を提示します。最終的なバージョンは人が決定します。

ステップ 6 — 変更履歴のエントリーを整形する

Keep a Changelog 形式を使用します。

## [X.Y.Z] — YYYY-MM-DD

### Breaking Changes
- Description of breaking change (#PR)

### Added
- Description of new feature (#PR)

### Fixed
- Description of bug fix (#PR)

### Changed
- Description of refactor or improvement (#PR)

### Documentation
- Description of docs change (#PR)

### Maintenance
- Description of chore (#PR)

空のカテゴリは省略します。上記の順序でカテゴリを並べます。破壊的変更は必ず最初にします。

ステップ 7 — 人による確認

整形したエントリーと提案するバージョンをユーザーに提示します。何かを書き込む前に、明示的な承認を待ちます。分類が曖昧だったコミットを強調表示します。

ステップ 8 — CHANGELOG.md に書き込む

ファイルのヘッダーの後に新しいエントリーを追加します。既存のエントリーを上書きしたり、並べ替えたりしてはいけません。CHANGELOG.md が存在しない場合は、標準的なヘッダーを付けて作成します。

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

ステップ 9 — 必要に応じて GitHub リリースを作成する

ユーザーが /release-notes release を実行した場合、または明示的に要求した場合に限ります。

gh release create vX.Y.Z --title "vX.Y.Z" --notes "RELEASE_BODY"

変更履歴のエントリーをリリース本文として使用します。ユーザーの確認なしにリリースを作成してはいけません。

基本原則

1. 自動で公開しないでください。 リリースと変更履歴の記述には、必ず人間による明示的な承認が必要です。
2. 既存の項目を保持してください。 以前の変更履歴の項目を変更、並べ替え、削除しないでください。
3. 機械による解析より、人が読みやすいことを優先してください。 変更履歴を読む人に伝わる説明を書き、パーサー向けの記述は避けてください。コミットハッシュより、わかりやすい言葉を使ってください。
4. PR と作成者を明記してください。 PR 番号はリンクにしてください。複数の貢献者がいるプロジェクトでは、初めて貢献した人についても記載することを検討してください。
5. 判断に迷ったら、確認してください。 コミットの内容が曖昧な場合は、分類を推測せず、ユーザーに確認してください。