リリースノート生成スキル
スプリント分のクローズドチケットから、洗練されたユーザー向けリリースノートを自動生成します。
生のチケットからリリースノートを作成するのは退屈な作業です。内部作業のフィルタリング、エンジニア用語のユーザー言語への変換、一貫したフォーマット設定が必要です。このスキルがすべてを自動化します。
プロンプトテンプレート
/schedule
### ステップ1 — 完了したチケットを収集
{{TICKET_SOURCES}} で、過去 {{TIME_WINDOW}} の間に「完了」「出荷済み」「マージ」「クローズ」とマークされたアイテムを確認します。
スキップするもの: 進行中、内部限定、ユーザーに見えるUX変更がない純粋なバグ修正、雑務、リファクタリング、
「内部」「インフラ」「運用」タグが付いたもの。
### ステップ2 — プロダクト領域ごとにグループ化
チケットのラベルまたはプロジェクト名を使用します。アイテム数が2未満の領域は、最も近いグループにマージします。
### ステップ3 — リリースノートを作成
各領域について:
**[領域タグ]**
**[タイトル]** — 2～5語、現在形、コミットメッセージではなく機能名。
良い例: 「検索結果が高速に」「新しい請求ダッシュボード」。決して「追加」「修正」「出荷」は使わないでください。
[説明] — 1～3文、ユーザー向け。何が変わったか、なぜ重要なのかを最初に述べてください。
「これで～できるようになりました」という表現を使ってください。箇条書きは使用しないでください。チケットID、スプリント名、エンジニア名は記載しないでください。
### ステップ4 — 保存
先頭に日付: 月 DD, YYYY。エントリは領域ごとにグループ化。
ReleaseNotes_YYYY-MM-DD.docx として {{OUTPUT_FOLDER}} に保存します。
公開せず、レビュー用に保存します。チケットが見つからなかった場合は、どのソースを確認したかを報告してください。
セットアップ
| フィールド | 値 |
|---|---|
| 必要なMCP | Linear / Jira / GitHub Issues、Google Drive |
| 出力先 | ReleaseNotes_YYYY-MM-DD.docx → /Product/ReleaseNotes |
| スケジューラ | 各リリース前に手動、または週次 |
埋めるべきプレースホルダー
{{TICKET_SOURCES}}— 例:Linear、Jira、GitHub Issues{{TIME_WINDOW}}— 例:過去7日間、過去2週間、このスプリント{{OUTPUT_FOLDER}}— 例:/Product/ReleaseNotes
ヒント
- チケットの品質が高いほど、リリースノートの品質も高まります。「ユーザーはこれで～できるようになりました」と書かれた説明が最良の結果を生みます。
update-knowledge-baseと組み合わせて、各リリース後に更新が必要なヘルプ記事を特定できます。- API/Webhookの変更については、それらのチケットを別のラベルに保持してください。このスキルはそれらに明確な技術的な表現を与えます。