公式スキル · プロダクト

マージ済みの変更からリリースノート

v1.0.0・2026年11月4日更新

マージ済みの PR やチケットから、新機能・改善・修正に分けて利点から書く顧客向けリリースノートと、社内用の変更履歴を書く。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• リリースを出し、PR、チケット、コミットの一覧が手元にあるとき
• 「新着情報」のページ、アプリ内の変更履歴、毎月のアップデートのお知らせが必要なとき

AI に渡すもの

• マージ済みの変更またはチケットの一覧
• リリース名か日付
• 顧客はどんな人か（任意）

できあがるもの

新機能・改善・修正に分けた顧客向けリリースノートと、チケット ID とサポート向けメモつきの社内用変更履歴。

手順

1. 顧客から見えないものを外す リファクタリング、依存パッケージの更新、テストの変更、CI、社内ツール、ログ出力は社内用だけに入れる。目に見える変化がない変更は、リリースノートに載せない。
2. 「新機能」「改善」「修正」に分ける 新機能 = 前はできなかったこと。改善 = 前からできたことが、速く、わかりやすく、広くなったもの。修正 = 壊れていて、今は動くもの。中身がはっきりしないチケットは、推測せず、社内用の一覧に「[要確認: ユーザーにとって何が変わったか]」をつけて入れる。
3. 各行を利点から書き直す まずユーザーが今できることを書き、次にどうやるかを書く。「請求書ページから請求書を CSV で書き出せます」と書き、「CSV エクスポートのエンドポイントを追加」とは書かない。コード上の名前ではなく、製品の画面名やボタン名を使う。
4. 修正は、ユーザーがその不具合だとわかるように書く ユーザーが目にした症状を書く。「アジアのタイムゾーンで、日付が1日ずれなくなりました。」誰かのせいにせず、謝りすぎない。顧客に届く前に直った不具合は載せない。
5. 影響の大きい順に並べる 各グループで、いちばん使われている変更、いちばん要望の多かった変更を先頭に置く。ユーザーから見て1つの変更である複数のチケットは、1行にまとめる。
6. 短くする 1つの変更につき1行、50字以内（このスキルの既定。一般的な目安は1〜2文）。導入の1文は、1つの変更がリリースの中心になっているときだけ足す。設定が必要な新機能には、ヘルプ記事のリンクをつける。
7. 社内用を書く Keep a Changelog の分類を使う。Added（追加）、Changed（変更）、Deprecated（非推奨）、Removed（削除）、Fixed（修正）、Security（セキュリティ）。最新のリリースを日付つきで先頭に置く。チケット ID、見えない作業をまとめる「社内」グループ、サポートが知っておくべきこと（動きが変わった点、既知の問題、移行の手順）を足す。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: release-notes
description: マージ済みの変更、プルリクエスト、チケットの一覧から、顧客向けのリリースノートを書く。「新機能」「改善」「修正」に分け、各行はユーザーにとっての利点から書き、社内用語やチケット ID は入れない。チーム向けの社内用変更履歴（changelog）も書く。マージ済みの PR、Jira や Linear のエクスポート、スプリントの一覧を貼られて、リリースノート、changelog、「新着情報」「アップデートのお知らせ」を頼まれたときに使う。
---

# リリースノート

顧客がリリースノートを読むのは、1つの問いに答えるためだ。前はできなかったことで、今できるようになったことは何か。どの行も、その答えを顧客の言葉で最初に書く。顧客から見えないものは外し、チケットのタイトルを読み解かせない。

## 使う場面

- リリースのあと、マージ済みの PR、チケット、コミットメッセージの一覧から書くとき。
- 「新着情報」のページ、アプリ内の変更履歴、毎月のアップデートメールに使うとき。
- サポートや営業のために、チケット ID つきの社内用変更履歴も必要なとき。
- 大きな機能1つのローンチ告知には使わない。launch-announcement を使う。

## 用意するもの

- 変更の一覧。PR のタイトル、チケットのタイトルと説明、またはコミットメッセージ。
- リリース名か日付。なければ一度だけ聞き、それでもなければ「[リリース日]」と書く。
- 顧客はどんな人か。使う言葉を選ぶため。わからなければ、技術に詳しくないユーザー向けに書く。
- 任意: 新機能のヘルプ記事へのリンク。

## 手順

1. **顧客から見えないものを外す。** リファクタリング、依存パッケージの更新、テストの変更、CI、社内ツール、ログ出力は社内用だけに入れる。目に見える変化がない変更は、リリースノートに載せない。
2. **「新機能」「改善」「修正」に分ける。** 新機能 = 前はできなかったこと。改善 = 前からできたことが、速く、わかりやすく、広くなったもの。修正 = 壊れていて、今は動くもの。中身がはっきりしないチケットは、推測せず、社内用の一覧に「[要確認: ユーザーにとって何が変わったか]」をつけて入れる。
3. **各行を利点から書き直す。** まずユーザーが今できることを書き、次にどうやるかを書く。「請求書ページから請求書を CSV で書き出せます」と書き、「CSV エクスポートのエンドポイントを追加」とは書かない。コード上の名前ではなく、製品の画面名やボタン名を使う。
4. **修正は、ユーザーがその不具合だとわかるように書く。** ユーザーが目にした症状を書く。「アジアのタイムゾーンで、日付が1日ずれなくなりました。」誰かのせいにせず、謝りすぎない。顧客に届く前に直った不具合は載せない。
5. **影響の大きい順に並べる。** 各グループで、いちばん使われている変更、いちばん要望の多かった変更を先頭に置く。ユーザーから見て1つの変更である複数のチケットは、1行にまとめる。
6. **短くする。** 1つの変更につき1行、50字以内（このスキルの既定。一般的な目安は1〜2文）。導入の1文は、1つの変更がリリースの中心になっているときだけ足す。設定が必要な新機能には、ヘルプ記事のリンクをつける。
7. **社内用を書く。** Keep a Changelog の分類を使う。Added（追加）、Changed（変更）、Deprecated（非推奨）、Removed（削除）、Fixed（修正）、Security（セキュリティ）。最新のリリースを日付つきで先頭に置く。チケット ID、見えない作業をまとめる「社内」グループ、サポートが知っておくべきこと（動きが変わった点、既知の問題、移行の手順）を足す。

## 出力の形式

```markdown
## [リリース名または日付]

[任意: いちばん大きな変更を1文で。]

### 新機能
- [ユーザーが今できること、どこでできるか。] [設定が必要ならリンク]

### 改善
- [よくなったこと。ユーザーの言葉で。]

### 修正
- [ユーザーが目にしていた症状。直ったこと。]

---

## 社内用変更履歴 — [リリース名または日付]

### Added（追加）
- [平易な説明]（[チケット ID]、[担当]）

### Changed（変更）
- [平易な説明]（[チケット ID]）

### Deprecated / Removed（非推奨・削除）
- [平易な説明。なければこのセクションを消す]（[チケット ID]）

### Fixed（修正）
- [平易な説明]（[チケット ID]）

### Security（セキュリティ）
- [平易な説明。なければこのセクションを消す]（[チケット ID]）

### 社内
- [リファクタリング、依存パッケージの更新、ツール]（[チケット ID]）

### サポートが知っておくこと
- [動きが変わった点、既知の問題、または「なし」]
```

## 例

**入力:**

> LIN-412 Add CSV export to invoices list
> LIN-418 Fix timezone offset bug in due date picker (UTC+8 and later)
> LIN-420 Bump stripe-node to 14.2
> LIN-421 Invoice list pagination now 50 instead of 20
> LIN-425 Refactor PDF renderer
> LIN-426 Reminder emails: add customer's company name to subject

**出力:**

```markdown
## 3月12日（木）のリリース

### 新機能
- 請求書ページから CSV で書き出せるようになりました。表計算ソフトにも税理士さんにもそのまま渡せます。

### 改善
- 請求書ページに一度に50件表示されるようになり、スクロールが減りました。
- 督促メールの件名に取引先の会社名が入るようになり、受信トレイで見分けやすくなりました。

### 修正
- アジアとオーストラリアのタイムゾーンで、支払期日が1日前にずれなくなりました。

---

## 社内用変更履歴 — 3月12日（木）

### Added（追加）
- 請求書一覧の CSV エクスポート（LIN-412）

### Changed（変更）
- 請求書一覧の1ページの件数を20件から50件に（LIN-421）
- 督促メールの件名に取引先の会社名（LIN-426）

### Fixed（修正）
- 支払期日ピッカーの UTC+8 以東でのずれ（LIN-418）

### 社内
- stripe-node 14.2（LIN-420）
- PDF レンダラーのリファクタリング（LIN-425）

### サポートが知っておくこと
- 督促メールを件名で振り分けている顧客は、設定の変更が必要かもしれない（LIN-426）。
```

## 送る前のチェック

- [ ] 顧客向けの部分に、チケット ID、コード上の名前、「エンドポイント」「リファクタリング」「バンプ」のような語がない。
- [ ] どの行も、ユーザーができること、または気づくことから始まっている。
- [ ] 各変更は、ちょうど1つのグループにだけ入っている。
- [ ] チケットに書かれている以上のことを書いていない。中身がはっきりしないものは、社内用の一覧で「[要確認: …]」がついている。
- [ ] どの行も50字以内。

## よくある失敗

- チケットのタイトルを少し直しただけで載せる。「タイムゾーンのずれのバグを修正」は顧客には意味がない。症状を書く。
- リリースを大きく見せるために、見えない作業を並べる。顧客が気にしている変更が埋もれる。
- リリースノートで次の予定を約束する。出したものだけを書く。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.