Changelog Generator

チェンジログジェネレーター

git履歴から自動的に人間にわかりやすいチェンジログを生成します。Keep a Changelog形式に従い、コミットメッセージをユーザーフレンドリーな表現に書き換え、オプションでGitHub Releaseも作成します。

入力解決

主な入力はgit ref範囲です。引数（指定された場合）を以下のルールで解決します。

1. ... または .. を含む -> git ref範囲（例：v1.0.0...v1.1.0）
2. 単一のタグ/refに一致 -> そのrefからHEADまで
3. GitHub URL または #\d+ パターンに一致 -> PR（そのPRの変更のみを抽出）。単一PR入力の場合：PRの差分と説明を読み、変更をカテゴリ分類し、PRタイトルをエントリとして使用します。バージョンヘッダーはスキップします。これらのエントリを既存のチェンジログバージョンに追加するか、新しいバージョンを作成するかをユーザーに尋ねます。
4. 引数なし -> 次の質問をします：「チェンジログはどの範囲をカバーしますか？git ref範囲（例：v1.0.0...v1.1.0）、タグ（そのタグ以降の変更）、またはPR番号を指定できます。」

処理フロー

digraph changelog {
    rankdir=TB;
    "入力解決" [shape=box];
    "フェーズ1: 収集" [shape=box];
    "フェーズ2: カテゴリ分類" [shape=box];
    "フェーズ3: 推敲" [shape=box];
    "フェーズ4: レビュー" [shape=box];
    "承認済み?" [shape=diamond];
    "フェーズ5: 出力" [shape=box];

    "入力解決" -> "フェーズ1: 収集";
    "フェーズ1: 収集" -> "フェーズ2: カテゴリ分類";
    "フェーズ2: カテゴリ分類" -> "フェーズ3: 推敲";
    "フェーズ3: 推敲" -> "フェーズ4: レビュー";
    "フェーズ4: レビュー" -> "承認済み?";
    "承認済み?" -> "フェーズ3: 推敲" [label="修正あり"];
    "承認済み?" -> "フェーズ5: 出力" [label="はい"];
}

フェーズをスキップしないでください。 自然なペースで質問を行ってください。ユーザーが複数の質問に一度に回答した場合は、まとめて受け入れ、先に進みます。

ユーザーが「デフォルトでいいよ」などと言った場合は、適切なデフォルトを選択し、その選択内容を伝えてから、確認を1回求めてください。

フェーズ1: 収集

ステップ1 - コミットとPRを収集

2つのrefの間で git log を実行し、すべてのコミットを収集します。リポジトリがPRを使用している場合は、gh pr list --state merged を使用して、範囲内のマージ済みPRも確認します。

各コミット/PRについて、以下を抽出します：

• コミットメッセージ（件名 + 本文）
• 変更されたファイル（スコープを特定するため）
• PRタイトルと説明（利用可能な場合）
• 従来のコミットタイププレフィックス（feat、fix、choreなど）

ステップ2 - 広範なプロダクトコンテキストを読む

README、package.json（または同等のファイル）が存在する場合は読んでください。目的は、プロダクトの内容を理解し、ユーザーフレンドリーな説明を書くことです。

何も見つからない場合は、次の質問をします：「プロダクトについて簡単に説明していただけますか？ユーザーフレンドリーなチェンジログエントリを書くためにコンテキストが必要です。」

ステップ3 - 既存の形式を検出

リポジトリに既存の CHANGELOG.md があるか確認します。ある場合：

• 形式を検出（Keep a Changelog、カスタムなど）
• 絵文字ラベル（例：新機能、バグ修正、破壊的変更）を使用しているか、プレーンテキストカテゴリを使用しているかを検出
• 既存のスタイルに合わせる

既存のチェンジログがない場合：

• デフォルトでKeep a Changelog形式を使用
• 次の質問をします：「既存のチェンジログが見つかりません。絵文字ラベル（例：新機能、バグ修正）とプレーンテキストカテゴリ（Added、Fixedなど）のどちらを希望しますか？」

フェーズ2: カテゴリ分類

すべての変更をKeep a Changelogカテゴリに分類します。Breaking Changes は先頭に専用セクションを設けます。

• Breaking Changes - 既存の動作、APIを壊す、またはユーザーのアップグレード作業が必要な変更。各変更に移行ノートを含めます。feat!:, fix!:, BREAKING CHANGE: フッター、または差分内の削除/リネームされたAPIから検出します。
• Added - 新機能
• Changed - 既存機能の変更
• Deprecated - 将来削除される機能
• Removed - 削除された機能
• Fixed - バグ修正
• Security - 脆弱性修正

分類ルール:

• コミットが従来のコミット（feat:、fix: など）に従っている場合、そのタイプを使用して分類
• 従っていない場合は、差分とコミットメッセージを分析してカテゴリを決定
• 内部のみの変更（リファクタリング、テスト追加、CI変更、依存関係の更新）は、ユーザーに影響を与える場合を除きスキップ
• ユーザーに影響するかどうか不明な場合は、含めてレビューでユーザーに削除してもらう
• 50コミット以上の範囲では、関連する変更をより高レベルのエントリにグループ化（例：12個の個別API修正を「複数のエンドポイントでAPIエラーハンドリングを改善」と書く）。グループ化バージョンを提示し、詳細が必要な場合はユーザーが展開できるようにする。

分類リストを提示：

「この範囲で見つかったものは以下の通りです：」

Added (3)

• 機能A
• 機能B
• 機能C

Fixed (2)

• バグ修正A
• バグ修正B

「追加、削除、または再分類したい項目はありますか？」

ユーザーが確認するまで次に進まないでください。

フェーズ3: 推敲

各エントリを人間にわかりやすい言葉に書き換えます。

• 実装の詳細ではなく、ユーザーベネフィットを先頭に
• 「レポートの読み込みが3倍高速になりました」と書き、「レポートモジュールのSQLクエリ実行計画を最適化しました」とは書かない
• 「レポートをPDFにエクスポートできるようになりました」と書き、「レポートサービスにPDFエクスポート機能を追加しました」とは書かない
• 各エントリは1行に（複雑な変更は2行まで）
• PR/Issue参照がある場合は含める（例：(#123)）

バージョンヘッダー

形式：## [バージョン] - YYYY-MM-DD

範囲の上限がバージョンタグ（例：v1.2.0）の場合は、そのバージョンを使用します。上限がHEADまたはブランチ名の場合は、次の質問をします：「このチェンジログはどのバージョン番号にしますか？」

範囲内の最新コミットの日付をISO形式（YYYY-MM-DD）で使用します。

技術付録

ユーザーフレンドリーなチェンジログを生成した後、次の質問をします：

「実装の詳細を含む技術付録も生成しましょうか？（開発者向けドキュメントに役立ちます）」

「はい」の場合、技術的な詳細、破壊的変更の移行ガイド、API変更を含むより詳細なセクションを生成します。

執筆ルール

• 生成コンテンツにemダッシュは使用しないでください。 「---」文字は使用しないでください。代わりにカンマ、コロン、ピリオド、または括弧を使用してください。
• デフォルトでユーザーフレンドリーな言葉遣い（専門用語なし、内部機能名なし）
• 各エントリは1行に（複雑な変更は2行まで）
• 一貫した動詞の時制（過去形：「Added」「Fixed」「Removed」）
• PR/Issue参照がある場合は含める

フェーズ4: レビュー

完全なチェンジログエントリを提示：

「こちらがチェンジログです：」

## [1.2.0] - 2026-04-11

### Added
- レポートをPDFにエクスポートできるようになりました (#123)

### Fixed
- ダッシュボードがページ読み込み時にちらつかなくなりました (#456)

「変更はありますか？」

承認を待ちます。ユーザーが確認した場合のみ出力に進みます。

フェーズ5: 出力

CHANGELOG.md

リポジトリルートに既存の CHANGELOG.md を検出します。見つかった場合、ファイル全体を読み、挿入ポイント（最初の ## [ 行の前）を特定し、挿入ポイントをユーザーに提示して確認してから書き込みます。見つからない場合は、標準ヘッダー付きで新規作成します：

# Changelog

このプロジェクトのすべての重要な変更はこのファイルに記録されます。

形式は [Keep a Changelog](https://keepachangelog.com/) に基づいています。

常に書き込み前に確認します：

「これを CHANGELOG.md の先頭に追加します。よろしいですか？」

GitHub Release

チェンジログを保存した後、次の質問をします：

「このチェンジログでGitHub Releaseも作成しましょうか？」

「はい」の場合、gh release create <タグ> --notes "<チェンジログ内容>" を使用してリリースを作成します。gh が利用できない場合は、ユーザーに通知してスキップします。

エラーハンドリング

• gh が利用できない -> ユーザーに通知し、PRエンリッチメントとGitHub Releaseをスキップし、git logのみに依存
• 無効なref/タグ -> ユーザーに確認を求める
• 範囲内にコミットがない -> ユーザーに伝え、範囲を確認するよう求める
• プロダクトコンテキストがない -> ユーザーにプロダクトの説明を求める
• 従来のコミットでない -> 分類のために差分分析にフォールバック

このスキルが行わないこと

• バージョニング戦略の管理（セマンティックバージョニングの決定はユーザーに委ねます）
• パッケージレジストリへの公開
• ブログ記事やニュースレターの生成（/blog-post または /newsletter を使用してください）
• ブランチ戦略やリリースワークフローの処理