mcpField
R
release-notes-generator

release-notes-generator

github.com/wu529778790開発4542 回インストール5 週間前に更新
リポジトリ

release-notes-generator について

release-notes-generator は、Git の tag と HEAD の間の変更から形式化されたリリースノートを作成するスキルです。リリースを準備する開発者向けに、変更の分類と破壊的変更の検出を行い、tag と GitHub Release の作成も選択できます。

主な機能

  1. 01前回の tag と HEAD を比較
  2. 02コミット種別ごとに変更を分類
  3. 03破壊的変更を検出
  4. 04形式化されたリリースノートを生成
  5. 05annotated tag と GitHub Release を任意で作成

活用シーン

  1. 01新バージョンのコミット変更を要約
  2. 02コミット履歴から CHANGELOG.md を生成
  3. 03リリース前に破壊的変更を確認
  4. 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:変更を分類する
カテゴリプレフィックス説明
🚀 Featuresfeat:新機能
🐛 Bug Fixesfix:修正
📝 Documentationdocs:ドキュメント
♻️ Refactorrefactor:リファクタリング
🔧 Choreschore:ビルド/ツール/設定
⚡ Performanceperf:パフォーマンス最適化
🧪 Teststest:テスト
🔒 Securitysecurity:セキュリティ修正
💥 Breaking ChangesBREAKING CHANGE または ! サフィックス破壊的変更

破壊的変更の検出ルール:

  1. コミットメッセージに BREAKING CHANGE: または BREAKING CHANGES: が含まれている
  2. コミットタイプの後に ! が付いている(例:feat!:、fix!:)
  3. コミット本文に破壊的変更の説明が含まれている

コミットメッセージ内の 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} の比較リンクを追加するユーザーが具体的なコード変更を確認しやすくなります

コメント