release-notes

リリースノートジェネレーター

技術的なチケット、PRD、社内変更履歴を、洗練されたユーザー向けリリースノートに変換します。

コンテキスト

$ARGUMENTS のリリースノートを作成します。

ユーザーがファイル（JIRA のエクスポート、Linear のチケット、PRD、Git ログ、社内変更履歴など）を提供した場合は、まず内容を確認します。製品の URL が提示された場合は、ウェブ検索を使って製品と対象ユーザーを理解します。

手順

1. 素材を集める：提供されたすべてのチケット、変更履歴、説明を読みます。以下を抽出します。

   • 変更内容（新機能、改善、修正）
   • 影響を受けるユーザー（対象となるユーザー層）
   • 重要な理由（ユーザーにとってのメリット）

2. 変更を分類する：

   • 新機能：まったく新しい機能
   • 改善：既存機能の強化
   • バグ修正：解決した問題
   • 破壊的変更：ユーザーによる対応が必要な変更（移行、API の変更など）
   • 非推奨化：提供を終了する機能

3. 以下の原則に従って各項目を作成する：

   • 技術的な変更ではなく、ユーザーのメリットから始めます
   • 平易な表現を使い、専門用語、社内のコードネーム、チケット番号は避けます
   • 各項目は 1～3 文にまとめます
   • ユーザーが画像やスクリーンショットを提供した場合は含めます

   変換例：

   • 技術的な表現：「ダッシュボード API エンドポイントに Redis キャッシュレイヤーを実装」

   • ユーザー向けの表現：「ダッシュボードの読み込みが最大 3 倍速くなり、待ち時間が減って、分析により多くの時間を使えるようになりました。」

   • 技術的な表現：「同時実行されるチェックアウト処理の競合状態を修正」

   • ユーザー向けの表現：「アクセスが集中する時間帯に、一部の注文が失敗することがある問題を修正しました。」

4. リリースノートを以下の構成にする：

   # [Product Name] — [Version / Date]
   
   ## New Features
   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]
   
   ## Improvements
   - **[Area]**: [What got better and how it helps]
   
   ## Bug Fixes
   - Fixed [issue description in user terms]
   
   ## Breaking Changes (if any)
   - **Action required**: [What users need to do]
   

5. 製品のトーンに合わせて調整する：B2B 製品にはプロフェッショナルなトーン、消費者向け製品には親しみやすいトーン、API には開発者向けのトーンを使用します。

Markdown ドキュメントとして保存します。ユーザーが HTML など別の形式を希望する場合は、それに合わせて変換します。