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

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

背景

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

ユーザーからファイル（JIRAのエクスポート、Linearのチケット、PRD、Gitログ、または内部変更履歴）が提供された場合は、まずそれらを読み込んでください。製品URLが記載されている場合は、ウェブ検索を利用して製品や対象ユーザー層を把握してください。

手順

素材を収集する：提供されたすべてのチケット、変更履歴、または説明文を読み込みます。以下の情報を抽出してください：
- 何が変更されたか（機能、改善点、または修正点）
- 誰に影響するか（どのユーザー層か）
- なぜ重要なのか（ユーザーにとってのメリット）
変更を分類する：
- 新機能：まったく新しい機能
- 改善：既存機能の機能強化
- バグ修正：解決された問題
- 互換性を損なう変更：ユーザーの対応が必要な変更（マイグレーション、APIの変更など）
- 非推奨機能: 提供終了となる機能
各項目は以下の原則に従って記述してください：
- 技術的な変更点ではなく、ユーザーにとってのメリットを最初に記載する
- 平易な言葉を使う — 専門用語、内部コードネーム、チケット番号は避ける
- 各項目は1～3文にまとめる
- ユーザーから提供された場合は、図やスクリーンショットを含める
変換例：
- 技術的：「ダッシュボードAPIエンドポイント向けにRedisキャッシュ層を実装しました」
- ユーザー向け：「ダッシュボードの読み込み速度が最大3倍速くなり、待ち時間が短縮され、分析に費やす時間が増えました。」
- 技術的：「同時チェックアウトフローにおけるレースコンディションを修正しました」
- ユーザー向け：「アクセスが集中する時間帯に一部の注文が失敗する問題を修正しました。」

リリースノートの構成：

# [製品名] — [バージョン / 日付]

## 新機能
- **[機能名]**: [機能の内容と重要性を1～2文で説明]

## 改善点
- **[対象領域]**: [どのような点が改善され、どのようなメリットがあるか]

## バグ修正
- [ユーザー目線での不具合の説明]を修正しました

## 互換性変更 (該当する場合)
- **必要な対応**: [ユーザーが行うべきこと]

製品のトーンに合わせて文体を調整してください— B2B向けはプロフェッショナルな口調、一般消費者向けは親しみやすい口調、API向けは開発者向けの口調。

Markdown形式のドキュメントとして保存してください。ユーザーがHTMLやその他の形式を希望する場合は、それに応じて変換してください。

GitHubで見る

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

### Context

You are writing release notes for **$ARGUMENTS**.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

### Instructions

1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
   - What changed (feature, improvement, or fix)
   - Who it affects (which user segment)
   - Why it matters (the user benefit)

2. **Categorize changes**:
   - **New Features**: Entirely new capabilities
   - **Improvements**: Enhancements to existing features
   - **Bug Fixes**: Issues resolved
   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
   - **Deprecations**: Features being sunset

3. **Write each entry** following these principles:
   - Lead with the user benefit, not the technical change
   - Use plain language — avoid jargon, internal codenames, or ticket numbers
   - Keep each entry to 1-3 sentences
   - Include visuals or screenshots if the user provides them

   **Example transformations**:
   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."

   - Technical: "Fixed race condition in concurrent checkout flow"
   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

4. **Structure the release notes**:

   ```
   # [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. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.