القائمة
次回リリースのリリースノート下書きを生成する。GitHub Releases に掲載するリリース告知文（冒頭の概要文・付箋ブロック・What's Changed 箇条書き）を、前回リリースタグ以降のコミット・PR から自動で整理し /tmp に出力する。リリース直前にユーザーから実行される想定
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
KonomiTV のリリース前チェックリストと手順ガイド。リリースを打つ前にユーザーと一緒に確認事項を順番に潰していくためのスキル。リリース前の準備やリリース手順を確認したいときに使う
【設定追加時は必ず参照】KonomiTV に新しい設定 (v-switch/v-select など) を追加する際の必須手順。SettingsStore.ts / Settings.ts / config.py / Settings/*.vue への追加が必要
| name | generate-release-notes |
| description | 次回リリースのリリースノート下書きを生成する。GitHub Releases に掲載するリリース告知文（冒頭の概要文・付箋ブロック・What's Changed 箇条書き）を、前回リリースタグ以降のコミット・PR から自動で整理し /tmp に出力する。リリース直前にユーザーから実行される想定 |
KonomiTV の GitHub Releases に掲載するリリースノート全体の下書きを生成するスキル。
冒頭のリリース告知文・付箋ブロック (NOTE/WARNING 等)・## What's Changed の箇条書きまでを一括で出力する。
ユーザーが次のバージョンをリリースする直前に実行し、/tmp/konomi-tv-release-notes-draft.md に Markdown ファイルを出力する。
リリースノートの執筆はユーザー本人にしか書けない文体・判断が求められる高負荷な作業であり、この負荷がリリース頻度の低下に直結していた。 このスキルの目的は ユーザーの過去のリリースノートの文体・構成・ニュアンスを忠実に再現し、ユーザーの手修正を最小限に抑えた下書きを生成すること にある。
単なる changelog の羅列ではなく「この人が書いたリリースノートに見える」品質が求められる。 具体的には:
過去のリリースノートの実例は以下のファイルに収録している。スキル実行時は必ず目を通し、文体・トーンを合わせること。
gh CLI が認証済みの前提で使ってよい書き分けの軸は バージョン番号そのもの ではなく 「告知文で目立たせる価値のある目玉 (新機能・大規模改善) が含まれているか」 である。 バージョン番号はあくまで補助的な目安にすぎず、最終的にはコミット内容を見て判断する。
v0.13.0 → v0.14.0)新機能の追加や大きな UX 改善など、ユーザーがアップデートする動機になる目玉が1つ以上ある ケース。 コミット数が多いマイナーリリースが中心だが、パッチリリースでもユーザー要望対応で新機能を一つ入れたなど、目玉に相当する変更があるなら同じ扱いでよい。
- ) で経緯や使い方を補足するv0.14.0 → v0.14.1)機能追加がほとんどなく、不具合修正と細かな改善が中心のケース。 そもそも目立たせる対象がないので、無理に強調しない。 ユーザーは「何が直ったか」を一覧したいだけで、各修正の背景説明までは求めていない。
- ) を原則として使わない
Add: prefix のコミット・大きな Update: での機能追加コミット・ユーザーが体感できるレベルの大規模改善コミットを数えるバージョン番号の遷移はあくまで参考程度の傾向であり、コミットの実態が優先される。 パッチリリースでも目玉があれば普通に強調していいし、マイナーリリースでも目玉がなければ目玉なし扱いで書く。
KonomiTV では Issue / PR / フィードバックフォーム / Twitter DM など複数のチャネルからユーザー報告が寄せられる。 報告者由来の修正にはきちんと感謝の意を示し、報告チャネルを明示する ことで、ユーザーが報告しやすい雰囲気を維持する。 これはマイナー・パッチ問わず全リリース共通で適用する。
各コミットの body (git log --format='%b' <hash> で取得) や PR 本文を確認し、以下のいずれかが当てはまる場合に「報告者由来の修正」として扱う。
(Close #XX) / (Fix #XX) / (Related: #XX) がある: 該当 Issue がユーザーから提出されたバグ報告/機能要望かを gh issue view #XX で確認する。ユーザー報告 Issue であれば対象(thanks @author) 表記の対象としている。重複しないよう注意報告者由来の修正項目には、以下のいずれかの形で末尾に感謝表記を添える。
(Close [#XX](https://github.com/tsukumijima/KonomiTV/issues/XX) — ご報告ありがとうございました！)(PR [#XX](https://github.com/tsukumijima/KonomiTV/pull/XX), thanks @author)(フィードバックフォームからのご報告に対応 — ありがとうございました！)(ご報告ありがとうございました！)過去のリリースノートでも「フィードバックフォームからいただいたリクエストへの対応です」「ご報告ありがとうございました」「(thanks @author)」のような表記が散見される。下書き段階ではこれらを 必ず明示 すること (ユーザーが後で削るのは簡単だが、追加し忘れて公開してしまうと報告者に伝わらない)。
Fix: [Server] EpgTimerSrv.ini の同一セクションに重複するキーが存在する場合でもパースエラーが発生しないようにする、body: ご報告いただいて調べたらこれで横転 → 対象 (body に「ご報告」あり、フィードバックフォームか DM 由来と推定)Fix: [Server][Streams/VideoEncodingTask] MP4 形式の録画再生時、〜 (Close #246) → 対象 (Issue #246 を gh issue view 246 で確認し、ユーザー報告であれば感謝表記を添える)Refactor: [Server][Streams/LiveEncodingTask] 型ヒントを厳密化 → 対象外 (内部リファクタで報告由来ではない)ユーザーに「今回リリースするバージョン番号は何ですか？」と確認する。
例: v0.14.0 / v0.14.1
ただし、バージョン番号は単なる開始トリガーであり、書き分けの判定材料ではない (詳細は上の「リリースの粒度判定と書き分け」セクションを参照)。 書き分け (目玉ありリリース / 目玉なしリリース) の判定はバージョン番号からは行えず、Step 1 でコミット一覧を取得して内容を読み込んで初めて確定する。 このため、Step 0 の段階では判定を保留し、Step 1 → Step 3 を経てコミットの実態を把握してから判別する。 判別結果は以降の全工程に影響する ため、Step 3 完了時点で曖昧なら、その場でユーザーに確認すること。
# 前回リリースタグ (最新のリリースタグ) を取得
PREV_TAG=$(gh release list --limit 1 --json tagName -q '.[0].tagName')
# 前回リリースタグ以降のコミット一覧 (ハッシュ・サブジェクト) を取得
git log --format='%H %s' "$PREV_TAG"..HEAD
リリースノートの品質は コミットをどれだけ丁寧に読み解いたか に直結する。以下のルールを厳守すること。
git show --stat や git log --format='%b' でコミット body・変更ファイル一覧を確認する。 特に以下のケースでは必ず確認する:
[GitHub][workflows] スコープのコミットは大半がスキップ対象だが、中にはサードパーティーライブラリ自体のバグをパッチで修正するような、ユーザー影響が非常に大きい変更が含まれることがある (例: Arrow Lake 環境での Intel Media Driver のハードウェアデインタレース機能のバグを Intel Media Driver にパッチを当てることで修正する等)。これらを見落とさないこと前回リリースのリリースノート本文を取得し、> [!NOTE] / > [!WARNING] / > [!TIP] / > [!IMPORTANT] で始まる GitHub Alerts ブロックをすべて抽出する。
gh release view "$PREV_TAG" --json body -q .body
これらの付箋ブロックは ダウンロード前にユーザーに読んでほしい注意書き として毎回のリリースに意図的に掲載されているもので、基本的にリリース間で内容を引き継いでいく。 具体的には以下のような定型的な内容が含まれる。
引き継ぎ時の判断基準:
0.12.0 → 0.13.0 など) は今回のバージョンに合わせて更新する<!-- この付箋は今回不要？ --> を付けておき、ユーザーの判断に委ねるDependabot 以外の外部コントリビューターによる PR を取得する。 これは箇条書き本文に盛り込む際の参考情報として使う (PR 一覧自体は出力しない)。
PREV_DATE=$(gh release view "$PREV_TAG" --json publishedAt -q .publishedAt)
gh pr list --state merged --limit 200 --json number,title,author,mergedAt \
--jq ".[] | select(.mergedAt > \"$PREV_DATE\") | select(.author.login != \"app/dependabot\") | \"\(.number) | \(.author.login) | \(.title)\""
全コミットをメッセージの prefix (Add:, Fix:, Update:, Refactor:, Remove:, Revert:, Build(deps) など) と内容を読み取り、以下のカテゴリに分類する。
| カテゴリ | 判定基準 | リリースノートでの扱い |
|---|---|---|
| 機能追加 | Add: prefix、または大きな Update: で新しいユーザー向け機能を追加しているもの | 箇条書き上部に配置、太字 (重要度順、下記参照) |
| 重要な改善 | Update: / Refactor: でユーザー体験に影響する改善 | 機能追加の次に配置、太字 |
| バグ修正 | Fix: prefix でユーザーに影響のあるバグ修正 | 改善の次に配置、太字 |
| 内部改善・リファクタ | Refactor: / Fix: でユーザーに直接影響しない内部改善 | 「その他」にまとめるか省略 |
| CI/Dockerfile/ワークフロー | [GitHub][workflows], [Dockerfile] などのスコープ | 基本的に省略、重要なものだけ記載 |
| スキップ対象 | Build(deps) (Dependabot)、[Readme.md]、Update: [Client] ビルドを更新、CodeRabbit に指摘された点を修正 などの定型コミット | 出力しない (GitHub 自動生成 or 省略) |
機能追加の重要度順と配置ルール:
機能追加の箇条書きは 重要度の高いものを上 に配置する。重要度の判断基準はコミット数や差分の大きさではなく、プロジェクトにとっての意味合い で決める。
さらに、機能的に近い項目は隣接して配置する。 重要度が離れていても、関連する機能同士はまとめて並べる方がユーザーにとって読みやすい。
分類時の重要なポイント:
Type: [Scope][Component] 説明 という形式で書かれている
[Client] はフロントエンド、[Server] はバックエンド[Client][Panel/Twitter] のようにサブコンポーネントまで示されることもあるRevert と対応する元コミットは相殺して無視するMerge pull request #XXX のマージコミットは集計から除外し、PR の内容はコミットの方から読み取るFix: [Server] 細かな修正 のような漠然としたコミットは基本的にスキップしてよいバグ修正の掲載基準 (極めて重要):
リリースノートは 前回リリースとの差分のスナップショット である。リリースノートに載せるバグ修正は 前回リリース時点で既に存在していた機能やバグに対する修正のみ に限定する。
バグ修正の重要度順:
バグ修正の箇条書きは 重要度の高いものを上、低いものを下 に配置する。重要度の判断基準:
また、修正に大きな労力がかかったもの (例: サードパーティーライブラリ自体のバグを特定してパッチを当てて解決したケースなど) は、その苦労の経緯を含めて手厚く記述する。過去リリースでも「文句は〜サイドへどうぞ」「原因を特定するのに苦労した」のように経緯に言及する傾向がある
分類されたコミットそれぞれについて、以下の情報を使って説明文を作成する。
git show --stat <hash> や git log --format='%b' <hash> でコミットの body や変更ファイルを確認する説明文の文体ルール (過去のリリースノートから抽出):
- で補足説明を追加)過去のリリースノートの構成に従い、以下の構造で Markdown ファイルを組み立てる。
箇条書き部分の実例は past-release-notes-examples.md を参照。
出力ファイルは上から順に以下の3パートで構成する。
画像/動画の配置場所を示す TODO コメントの後に、今回のリリースの 概要紹介文 (1〜3段落) を生成する。
<!-- TODO: 冒頭にスクリーンショットや動画を貼る -->
(ここにリリース告知文を記述)
告知文の書き方 (過去リリースから抽出したパターン):
正式版が公開されるまでのリリースはあくまで〜) を含める<br> として表示される。これを活用して、文の途中で折り返されて読みにくくなる前に、意味のまとまりで意図的に改行を入れる。具体的には:
過去の告知文の実例は past-intro-examples.md を参照。
Step 1.5 で引き継いだ NOTE/WARNING/TIP/IMPORTANT ブロックをここに配置する。 バージョン番号の参照は今回のリリースに合わせて更新済みの状態で出力する。
## What's Changed
<!-- === 機能追加 (重要度順) === -->
* **項目タイトル**
- 補足説明1
- 補足説明2
* **項目タイトル**
<!-- === 重要な改善 === -->
* **項目タイトル**
<!-- === バグ修正 === -->
* **項目タイトル (Close #XX)**
* **項目タイトル**
<!-- === その他 === -->
* その他大量のバグ修正、依存ライブラリの更新など
<!-- ここから下は GitHub の「Generate release notes」ボタンで自動生成される部分。
ユーザーが手動でマージするため、このスキルでは出力不要 -->
箇条書きの書式ルール:
* **タイトル** の太字形式[テキスト](URL) で含める
(Close #XX) を末尾に付ける- ) は2スペースインデントで記述(thanks @author) の形で言及する完成した下書きを /tmp/konomi-tv-release-notes-draft.md に出力する。
出力後、ユーザーにファイルパスを伝え、中身の要約も併せて報告する。
コミットの影響範囲が不明確な場合は、変更されたファイルとコミット本文を確認した上で判断する。
それでも迷う場合は 含める側 に倒す（ユーザーが後から削除する方が、書き漏らしを後から追加するより楽なため）。
前回リリースからのコミット数が 200 を超える場合: