release-notes

リリースノート生成ツール

技術的なチケット、PRD、または内部 changelog を洗練されたユーザーフェイスのリリースノートに変換します。

コンテキスト

$ARGUMENTS のリリースノートを執筆しています。

ユーザーがファイル（JIRA エクスポート、Linear チケット、PRD、Git ログ、または内部 changelog）を提供する場合は、まずそれらを読んでください。ユーザーが製品 URL を言及している場合は、Web 検索を使用して製品とオーディエンスを理解してください。

手順

1. 生素材を収集: 提供されたすべてのチケット、changelog、または説明を読んでください。以下を抽出します：

   • 何が変わったか（機能、改善、または修正）
   • 誰に影響するか（どのユーザーセグメント）
   • なぜそれが重要か（ユーザーにとっての利点）

2. 変更を分類:

   • 新機能: まったく新しい機能
   • 改善: 既存機能の拡張
   • バグ修正: 解決された問題
   • 破壊的変更: ユーザーアクション（マイグレーション、API 変更）が必要な事項
   • 廃止予定: サポートが終了する機能

3. 各エントリを以下の原則に従って執筆:

   • 技術的な変更ではなく、ユーザーにとっての利点で始める
   • 平易な言葉を使用 — 専門用語、内部コード名、チケット番号は避ける
   • 各エントリは 1～3 文に保つ
   • ユーザーが提供する場合は、ビジュアルまたはスクリーンショットを含める

   例：変換方法:

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

   • ユーザーフェイス: 「ダッシュボードが最大 3 倍高速に読み込まれるため、待機時間を削減し、分析により多くの時間を費やせます。」

   • 技術的: 「並行チェックアウトフローの競合状態を修正」

   • ユーザーフェイス: 「トラフィック量が多い期間に注文が失敗する可能性がある問題を修正しました。」

4. リリースノートを構造化:

   # [Product Name] — [Version / Date]
   
   ## 新機能
   - **[機能名]**: [それが何をするのか、なぜ重要なのかを 1～2 文で説明]
   
   ## 改善
   - **[領域]**: [何が改善されたか、それがどう役に立つか]
   
   ## バグ修正
   - [ユーザー用語で説明した問題] を修正
   
   ## 破壊的変更（該当する場合）
   - **アクション必須**: [ユーザーが実行する必要があること]
   

5. トーンを製品の声に合わせて調整 — B2B 向けは専門的に、コンシューマー向けはフレンドリーに、API 向けは開発者向けに。

Markdown ドキュメントとして保存してください。ユーザーが HTML または別の形式を希望する場合は、適宜変換してください。