update-changelog

変更履歴の更新

推測ではなく、リポジトリの根拠に基づいて docs/CHANGELOG.md を更新します。

使用する場面

• docs/CHANGELOG.md に最新のリリース項目を追加する
• 変更履歴の内容を GitHub Releases と同期する
• git の履歴またはコードの差分から最新のタグを要約する

デフォルト

• 簡潔な表現にします
• ユーザーから過去のリリースも追加するよう明示的に求められない限り、最新の未記載バージョンのみを追加します
• 特に Releases とタグのメタデータなど、まずは GitHub の情報源を優先します
• リリースに明確な項目が少ししかない場合は、Features／Improvements／Bug Fixes の見出しを省略します

手順

1. 既存のスタイルを確認する

• docs/CHANGELOG.md を開きます
• 既存の文体、箇条書きのスタイル、セクションの順序、日付の書式に合わせます

2. 対象のリリースを特定する

• ルートの package.json のバージョンを読み取り、変更履歴の最上部の項目と比較します
• 対象バージョンの前のタグを探します
• 最新バージョンがすでに記載されている場合は、作業を中止し、変更履歴の更新は不要であることを報告します

3. 根拠を収集する

次の順に情報源を優先します。

1. GitHub のリリースノート

GH_PAGER=cat gh release view v<version> --repo <owner>/<repo> --json tagName,name,publishedAt,body

2. タグの日付

git log -1 --format=%cs v<version>

3. タグ間のコミット履歴

git --no-pager log --format='%h %s' --no-merges v<previous>..v<version>

4. コミットの件名が曖昧な場合は差分の範囲

git --no-pager diff --name-only v<previous>..v<version>
git --no-pager diff --stat v<previous>..v<version>

5. ユーザーに見える変更がまだ不明な場合に限り、変更されたファイルを直接確認します

4. 変更履歴に記載する内容を選ぶ

次の内容を含めます。

• ユーザーに見える機能
• 重要な動作の変更
• 信頼性、互換性、開発者エクスペリエンスを向上させるバグ修正
• サポート対象のセットアップやオンボーディングに実質的な変更をもたらす場合に限り、小規模なドキュメントの更新

明示的に求められない限り、次の内容は除外します。

• バージョン番号だけの更新
• 定期的な依存関係の更新
• 目に見える影響のない内部リファクタリング
• 機械的なフォーマット変更によるノイズ

5. 構成を決める

• 明確な項目が1〜3件の場合は、バージョン見出しの直下に箇条書きで記載します
• 複数の異なる項目がある場合は、### Features、### Improvements、### Bug Fixes などの短い見出しを使用します
• 項目が長くなったりノイズが増えたりする場合は、カテゴリー分けを無理に行いません

6. 項目を記述する

• 依頼されたリリース項目のみを追加または更新します
• 箇条書きは短く、具体的にします
• 近くの項目で使われているプロジェクト用語に合わせます
• マーケティング的な表現は避けます
• ノイズの多い GitHub のリリース文をそのままコピーしません

7. 検証する

• 日付、バージョン番号、タグの境界を確認します
• Markdown の構造が近くの項目と一致していることを確認します
• 依頼がない限り、中間バージョンが追加されていないことを確認します

完了チェック

• 依頼された最新バージョンが記載されています
• 簡潔で、周囲の変更履歴と一貫した表現になっています
• GitHub のリリース、git の履歴、またはコードの差分が記述の根拠になっています
• シグナルの弱い内部変更は除外されています