release-notes

リリースノートのエキスパート

概要

チケット、変更履歴、git ログ、PRD などの未整理の技術的変更を、明確でユーザーのメリットを重視したリリースノートに変換します。このスキルでは、入力情報の収集、各変更の5つのカテゴリへの分類、ユーザーのメリットを伝える表現への書き換え、対象読者に合わせたトーンの調整、そして組み立てという5段階の手法を通じて、すべてのリリースで適切な対象読者に適切なトーンで価値を伝えられるようにします。

使用するタイミング

• 製品リリース — 顧客、パートナー、社内の関係者に新しいバージョンを告知する場合。
• スプリントデモ — スプリントレビューの対象者向けに、リリースした内容を要約する場合。
• 変更履歴のメンテナンス — リリースごとの変更を継続的に記録する場合。
• 顧客向けコミュニケーション — メール、アプリ内、ドキュメントでのリリース告知を準備する場合。

主な機能

• 5カテゴリへの分類 — 新機能、改善、バグ修正、破壊的変更、非推奨化を、明確な割り当てルールに基づいて分類します
• ユーザーのメリットを伝える表現への書き換え — 結果を先に示し、平易な言葉で1～3文にまとめます。開発者視点の表現も検出します
• 対象読者に合わせたトーンの指針 — B2B／エンタープライズ、コンシューマー、開発者／API、社内向け
• 自動生成 — release_notes_generator.py が項目をグループ化し、Markdown／JSON 形式に整え、書き換えが必要な技術用語を含む箇所にフラグを付けます

まず確認すること

リリースノートを生成する前に、以下の入力内容を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 対象読者 — B2B／エンタープライズ、コンシューマー、開発者／API、または社内向け（全体のトーンや詳細度を決定します）
• 変更のソース — 5カテゴリに分類した、対象となるチケット／PR／変更履歴（これらがなければ生成できません）
• 破壊的変更と非推奨化 — 何が変わったのか、必要な対応、対応期限（ユーザーの信頼を守るため、破壊的変更に必須の項目を明記します）

停止ルール：出力を最も大きく左右する2～3項目だけ質問します。ユーザーが「とりあえず下書きして」と言った場合は作業を進め、成果物の冒頭に前提条件を列挙してください。

クイックスタート

python scripts/release_notes_generator.py --input changes.json --product-name "Acme App" --version "2.5.0"
python scripts/release_notes_generator.py --demo --product-name "Acme App" --version "1.0.0"

項目があるカテゴリのみ含めてください。破壊的変更には、何が変わったのか、ユーザーが何をする必要があるのか、いつまでに対応すべきかを明記してください。手法、出力テンプレート、フラグのリファレンスについては、参考資料を参照してください。

参考資料

タスクに合った参考資料を読み込んでください。このファイルは簡潔に保ち、必要な詳細を都度参照します。

• references/methodology-and-tooling.md — 5段階の手法全体、分類表、書き換えの変更前／変更後の例、対象読者別のトーン一覧、出力テンプレート、トラブルシューティング、成功基準、および release_notes_generator.py のフラグと JSON スキーマのリファレンスを記載しています。ノートの作成時やツールの実行時に参照してください。
• references/release-notes-guide.md — カテゴリの定義、対象読者に関する指針、具体例をまとめたベストプラクティスガイドです。より詳しい背景を知りたい場合に参照してください。
• references/red-flags.md — 問題のある項目と適切な項目の具体例、および修正方法を記載しています。下書きを公開する前に参照してください。
• assets/release_notes_template.md — すぐに使えるリリースノートのドキュメントテンプレートです。

統合ポイント

統合	方向	説明
sprint-retrospective/	受け取る	スプリントのコミットデータとタイプの分布をもとに、掲載する変更を判断します
senior-pm/	補完する	関係者とのコミュニケーション計画を参考に、リリースノートの対象読者とトーンを決めます
execution/create-prd/	受け取る	PRD の機能説明（セクション7）をリリースノートの項目の下書きにします
scrum-master/	受け取る	スプリントレビューの成果物から、リリース済みでドキュメント化が必要な内容を特定します
summarize-meeting/	受け取る	リリース計画会議の要約から、リリースノートに必要な背景情報を得ます
job-stories/ / wwas/	受け取る	ユーザーストーリーの説明を参考に、各項目でユーザーのメリットを伝えます

対象範囲と制限事項

対象範囲：

• 5 つの項目カテゴリを含む、JSON 入力からの構造化されたリリースノートの生成
• 技術的な表現の自動検出と書き換えの提案
• カテゴリ別にグループ化した Markdown および JSON の出力形式
• 対象読者に合わせたトーンのガイダンス（B2B、消費者、開発者、社内向け）
• 新機能、改善、バグ修正、破壊的変更、非推奨に関する分類ルール

対象範囲外：

• git 履歴からの変更内容の自動抽出（git の分析については sprint-retrospective/ を参照）
• 完了したストーリーを取得するための Jira/Linear チケット連携（JSON の手動入力が必要です）
• 複数リリースにまたがる変更履歴の管理（このツールはリリースごとのノートを生成します）
• メール、アプリ内、ドキュメントの各チャネルへの配信（出力は後続の処理に使用する Markdown/JSON です）

重要な注意事項：

• 書き換えの提案は、パターンベースのヒューリスティックです。よくある技術的な表現は検出できますが、説明がユーザーのメリットを実際に伝えているかどうかは判断できません。
• セマンティックバージョニングとの整合性はユーザーの責任です。このツールは、変更の種類に応じてバージョン番号が semver の規約に従っているかどうかを検証しません。
• 破壊的変更には特別な注意が必要です。変更内容、ユーザーが行う必要のあること、期限を必ず記載してください。曖昧な破壊的変更のノートは、ユーザーの信頼を損ないます。