generating-changelog

チェンジログの生成

2 つの git タグ間で、公開可能なウェブサイト用チェンジログ（docs.streamlit.io 形式）を生成します。PR ラベル（impact:users、impact:internal、change:*）を使って分類し、PR タイトルをユーザーにとってわかりやすい説明に書き換えます。

GitHub リリースのチェンジログは .github/release.yml から自動生成されます。このスキルはウェブサイト形式のみを生成します。

使用方法: /generating-changelog <previous-tag> <new-tag>（例: /generating-changelog 1.44.1 1.45.0）

タグが 1 つだけ指定された場合は、それを新しいリリースタグとして扱い、前のタグを自動的に取得します。

ステップ 1: 入力を検証する

• ユーザーの引数から 2 つのタグを解析します。1 つ目 = 前回のリリース、2 つ目 = 新しいリリース。
• タグが 1 つだけ指定された場合は、前のタグを取得します:

  gh api repos/streamlit/streamlit/releases/latest --jq '.tag_name'
  

• 完全一致の参照を使って（パターンマッチングなしで）両方のタグが存在することを検証します:

  git rev-parse -q --verify "refs/tags/<tag>" > /dev/null
  

  このコマンドは各タグで成功する（終了コード 0）必要があります。
• 新しい方のタグからリリース日を取得します:

  git log -1 --format=%ai <new-tag>
  

ステップ 2: PR データを取得する

fetch スクリプトを実行して git log から PR 番号を抽出し、GitHub GraphQL 経由でメタデータを一括取得します:

uv run python scripts/changelog_fetch_prs.py <prev-tag> <new-tag>

これにより work-tmp/pr-data.json が生成されます。これは {number, title, body, labels, author, related_issues, related_issues_truncated} オブジェクトの JSON 配列で、PR 番号順にソートされています。body フィールドには PR 説明の最初の 2500 文字が含まれます。

related_issues は同じバッチ化された GraphQL クエリから取得され（PR ごとの N+1 リクエストはありません）、リンクされた issue 番号と 👍 の数を含みます:

"related_issues": [{"number": 9836, "thumbs_up": 42}]

ステップ 3 & 4: フィルタリングと分類

分類スクリプトを実行してノイズを除外し、PR をラベルごとに分類します:

uv run python scripts/changelog_categorize_prs.py

これは work-tmp/pr-data.json を読み込み、以下のルールを適用し、work-tmp/pr-categorized.json を書き出します:

除外対象: ボットの作成者、リリース/バージョン/ドキュメント文字列の PR、内部専用 PR (impact:users を伴わない impact:internal — これには change:* ラベルを持つ内部機能が含まれます)。

外部コントリビューター: 除外されなかった各 PR には is_external 真偽値フィールドが含まれます。作成者が sfc-gh-* または既知の内部セットに一致する場合は is_external: false とマークされ、それ以外はすべて is_external: true となります。サマリー出力では外部コントリビューターが別途リストされるため、GitHub プロフィールを調べることなくコントリビューションを帰属させることができます。

スクリプトカテゴリ (ラベルの優先順位: breaking > feature > bugfix > その他):

ラベル	スクリプトカテゴリ
change:breaking	破壊的変更
change:feature	新機能
change:bugfix	バグ修正
impact:users または認識されない change:* ラベル	その他の変更

impact:* または change:* ラベルを持たない PR は、ユーザーの確認のために unlabeled としてフラグが立てられます。

注: change:* ラベルは通常、リリースラベリングの慣例で必要とされます。「その他の変更」フォールバックは、breaking/feature/bugfix でカバーされない impact:users PR および非標準の change:* 値に対する防御的なキャッチオールです。

重要: これらのスクリプトカテゴリはトリアージ用の中間的なグループ分けです。ウェブサイトの変更履歴には「破壊的変更」や「新機能」のセクションはありません。すべてのエントリは以下の 3 つのウェブサイト階層にマッピングされます。破壊的変更、非推奨化、削除は、適切な絵文字を付けて注目の変更またはその他の変更に折り込まれます (ステップ 6 を参照)。

3 つのウェブサイト階層にマッピングします:

• ハイライト (任意 — 該当する PR がない場合は完全に省略): リリースごとに 0〜4 項目のみ。真に主要なユーザー向けの追加に限定します: まったく新しい機能 (例: 新しいウィジェットから URL パラメータへのシステム、動的コンテナ制御)、新しいワークフローを可能にする重要な新 API パラメータ、または主要な破壊的変更。漸進的な改善、新しい設定オプション、既存コマンドへの追加パラメータは、ハイライトではなく注目の変更に属します。一部のリリース (例: パッチリリース) にはハイライトセクションがまったくありません。
• 注目の変更: 残りの機能、影響の大きい改善、新しいパラメータ、ハイライトに昇格されなかった破壊的変更
• その他の変更: バグ修正、ドキュメント、雑務、軽微な改善

ステップ 5: 確認用に分類を提示する

最終出力を生成する前に、ユーザーにサマリーを提示します:

1. PR の総数とカテゴリごとの数
2. 「ハイライト」階層に提案する PR のリスト — ユーザーが昇格/降格できるようにする
3. ステップ 3 でフラグが立てられた unlabeled な PR があれば、推奨される分類とともに提示する
4. 境界線上のハイライト候補については、優先順位付けのシグナルの 1 つ (唯一のシグナルではない) として related_issues のリンクされた issue の 👍 数を検討する
5. スクリプトが特定した外部コントリビューター (is_external フィールドから) — エッジケースは確認しますが、sfc-gh-* や既知の内部作成者については GitHub プロフィールを調べる必要はありません
6. 続行する前に、ユーザーに確認または調整を求める

注: 内部専用の機能 PR (例: e2e インフラ、CI ワークフロー、エージェントスキル) は、categorize スクリプトによってすでに除外されています。これらを手動でフィルタリングする必要はないはずです。

ユーザーが確認するまでステップ 6 に進まないでください。

ステップ 6: PR の説明を読み、出力を生成する

work-tmp/pr-categorized.json 内の各ユーザー向け PR について、変更履歴のエントリを書く前にその body フィールドを読みます。実際に何が変更されたかについての主要な情報源として PR の説明を使用してください。タイトルだけでは不正確な場合があります。本文の冒頭の要約段落に注目し、チェックリスト、レビュアー向けのメモ、スクリーンショットのセクションは無視してください。

エントリの長さ: すべてのエントリを 1 文、長くても 2 文 に収めてください。変更点と、それがユーザーにとってなぜ重要かを、高レベルな考え方としてのみ捉えてください。サブ機能、実装の詳細、パラメータの一覧、エッジケースの動作を列挙しないでください。それらの詳細は API ドキュメントに記載されています。

work-tmp/ ディレクトリにファイルを生成します: work-tmp/changelog-website-<new-tag>.md

カテゴリ別のエントリの書き方

• ハイライト: 告知調 — 「Introducing...」、「Announcing...」。PR リンクは任意で含めても省略してもかまいません。
• 機能 / 新しいパラメータ(Notable Changes): ユーザー視点の語り口 — 「You can now...」、「st.foo has a new bar parameter to...」、「st.foo supports...」
• バグ修正: 常に「Bug fix:」を先頭に付けます — 「Bug fix: st.spinner avoids a race condition...」
• 非推奨化/削除: 特定の絵文字を付けた簡潔な説明(下記の絵文字一覧を参照)。
• その他のバグ以外のエントリ: 接頭辞を付けず、現在形の簡潔な説明。

フォーマットルール

• 書き換える前に、PR タイトルから [fix]/[feat]/[chore]/[docs] プレフィックスを削除する
• 絵文字:
  • バグ修正では、これらの昆虫／バグの絵文字をローテーションで使用する: 🐛, 🦋, 🪲, 🐜, 🐝, 🐞, 🕷️, 🪳, 🪰, 🦠, 🦟, 🦂, 🦗, 🕸️, 🐌, 🦎, 🦀, 👽, 👻
  • 削除には 👻、非推奨には ☠️、検討中の削除には 💩 を使用する
  • バグ以外の項目では、この承認済みパレットの絵文字のみを使用する（連続して繰り返さず、バリエーションをつける）。
    • UI／レイアウト／デザイン: 🎨, 📐, 🖼, 🧩, 📏, 💅, 🖌, 🎛, 🎚, 🔲, 🌈, 🪄
    • データ／チャート／テーブル: 📊, 📈, 📋, 🔢, 🔣, 📒, 📃, 📄
    • パフォーマンス／速度: ⚡, 🚀, ⏱, ⏩, ⏳, 🏎
    • セキュリティ／認証: 🔒, 🔐, 🔏, 🛡, 🔑, 👮, 🥷
    • 設定／構成: ⚙, 🔧, 🛠, ⚒, 🧰, ⛏, 🔩
    • リンク／ナビゲーション: 🔗, 🧭, ➡, ⬆, ⬇, 🔝, 🚪, 🛣, ↩
    • 検索／可視性: 🔍, 🔎, 👀, 🕵
    • パッケージ／依存関係: 📦, 🔤, 📥, 📤, 💿, 💾, 💽
    • 新機能／ハイライト: ✨, 🎯, 🆕, 🍿, 🎁, 🎈, 🎊, ⭐, 🌟, 🆙
    • テキスト／コンテンツ／ドキュメント: ✍, 📝, 📜, 📖, 📘, 📚, ✏, ✒, 🖊, 🖋
    • 通知／メッセージング: 🔔, 📣, 💬, 📨, 📩, 📬, 🛎
    • 状態／接続／同期: 💓, 🔀, 🔄, 🔁, 📶, 🔌, ⛓
    • メディア／表示: 📷, 📸, 📹, 📺, 🎥, 🎤, 🎵, 🎶, 🎹, 🖥
    • ファイル／ストレージ: 📁, 📂, 🗂, 🗃, 🗑, 📌, 📍, 🏷, 🗜
    • ユーザー／アイデンティティ: 👤, 👥, 🧑, 👋, 🤝, 👑
    • エラー／警告: 🚨, 🚩, ⚠, 🛑, ❌, ❓, 🚧
    • テスト／サイエンス: 🧪, ⚗, 🔭, 🧠
    • その他のオブジェクト: 💡, 💎, 💪, 💯, 💰, 💻, 💼, ⌨, 📱, 📲, 🖨, 🖱, 📞, 🗝, 🖇, ✂, ➕, 🪜, 🪧, 🏗, 🏠, 🏢, 🧱, 🪵
    • 楽しい／クリエイティブ: 🍔, 🍞, 🍪, 🍰, 🎩, 🎫, 🏁, 🏃, 🏄, 🏋, 🏓, 🏹, 🐍, 🐙, 🦊, 🦐, 🤖, 🤹, 🥸, 🧞, 🛸, 🛹, 🪗, 🪆, 🚇, 🚒, 🚣, 🌱, 🌐, 🗺, 🗻
  • パレットに合う絵文字がない場合は、デフォルトで ✨ を使用する
• st.* コマンド参照: バッククォート形式を使用し、特定の API ドキュメントサブカテゴリのパスにリンクする: st.image、st.dataframe。コマンドの最初／主要な言及のみをリンクする。リンクは Other Changes よりも Notable Changes でより一般的です。
• PR と issue のリンク: 該当する場合は PR リンクと関連する issue リンクの両方を含める。形式: ([#14139](https://github.com/streamlit/streamlit/pull/14139), [#9836](https://github.com/streamlit/streamlit/issues/9836))。PR には /pull/ を、issue には /issues/ を使用する。
• 句読点: 各項目は、PR／issue リンクの閉じ括弧の後にピリオドで終わる。
• コントリビューターの帰属: 外部（Snowflake 以外）のコントリビューターを記載する。リンクテキストに [username]（@ プレフィックスなし）を使用し、閉じ括弧とピリオドの後に配置する: ([#NNNNN](https://github.com/streamlit/streamlit/pull/NNNNN)). Thanks, [username](https://github.com/username)!
• 複数 PR のグループ化された項目: 複雑な複数 PR の機能では、コロン付きの親箇条書きを使用し、その後にインデントされた子箇条書きを続ける:

  - 🎨 Main feature description:
      - Sub-detail or sub-command ([#NNNNN](https://github.com/streamlit/streamlit/pull/NNNNN)).
      - Another sub-detail ([#MMMMM](https://github.com/streamlit/streamlit/pull/MMMMM)).
  

出力構造

## **Version <new-tag>**

_Release date: <Month Day, Year>_

**Highlights**

- 🍿 Introducing [`st.new_thing`](/develop/api-reference/widgets/st.new_thing) — a widget that lets you do something amazing ([#14200](https://github.com/streamlit/streamlit/pull/14200)).

**Notable Changes**

- 📊 [`st.dataframe`](/develop/api-reference/data/st.dataframe) has a new `selection_mode` parameter that lets you configure row and column selection behavior ([#14139](https://github.com/streamlit/streamlit/pull/14139), [#9836](https://github.com/streamlit/streamlit/issues/9836)).
- ☠️ `st.legacy_thing` is deprecated and will be removed in a future version. Use `st.new_thing` instead ([#14050](https://github.com/streamlit/streamlit/pull/14050)).
- 🔑 App menu redesign:
  - New "Settings" option in the app menu ([#14100](https://github.com/streamlit/streamlit/pull/14100)).
  - Reorganized menu items for better discoverability ([#14101](https://github.com/streamlit/streamlit/pull/14101)).

**Other Changes**

- 🐛 Bug fix: `st.spinner` avoids a race condition when used right before a cache miss ([#13849](https://github.com/streamlit/streamlit/pull/13849), [#13634](https://github.com/streamlit/streamlit/issues/13634)).
- 🦋 Bug fix: `st.number_input` no longer resets to default when the step value changes ([#14125](https://github.com/streamlit/streamlit/pull/14125)). Thanks, [contributor](https://github.com/contributor)!
- 🪲 Bug fix: Fixed a layout shift in `st.columns` when using `gap="small"` ([#14080](https://github.com/streamlit/streamlit/pull/14080)).

リリースに Highlights がない場合は、そのセクションを完全に省略する（空の Highlights ヘッダーを含めないでください）。

ステップ 7: 最終サマリー

ファイルを書き込んだ後、以下を出力します:

• 生成された変更履歴のファイルパス
• カテゴリごとの PR 数
• 公開前にファイルを確認するよう促すリマインダー

主な参照先

• .github/release.yml — ラベルからカテゴリへの正規のマッピング（自動生成される GitHub リリースノートにも使用されます）
• ウェブサイトの変更履歴フォーマットの参照: https://docs.streamlit.io/develop/quick-reference/release-notes
• ドキュメント Markdown ファイルの例（スタイルの参考）: https://raw.githubusercontent.com/streamlit/docs/997b19a5eda68b72ce091d69be9d6921a37e3da0/content/develop/quick-references/release-notes/2026.md