generate-release-notes

COG リリースノート生成スキル

呼び出すタイミング

• ユーザーがバージョン、スプリント、またはサイクルのリリースノートを作成したい場合
• ユーザーが「リリースノート」「変更履歴」「何をリリースしたか」「リリースノートを書いて」と言った場合
• 新しいバージョンまたはマイルストーンが完了した場合
• スプリント／サイクル終了時のドキュメント作成

エージェントモードの確認

00-inbox/MY-PROFILE.md のフロントマターにある agent_mode を確認します。

• agent_mode: team の場合 — 並列エージェントを使って、すべての有効なソースから同時にデータを収集します
• agent_mode: solo の場合 — 主要なトラッカーから順次データを収集します

コマンド：/generate-release-notes

事前確認

1. **00-inbox/MY-INTEGRATIONS.md を読み、**データソースと公開オプションを確認します

2. **00-inbox/MY-PROFILE.md を読み、**有効なプロジェクトを確認します

3. 現在のタイムスタンプを取得します。 Bash を使って date '+%Y-%m-%d %H:%M' を実行します

4. ユーザーに確認します（まだ情報が提供されていない場合）：

   • 対象のバージョン／リリース／サイクルは何ですか？
   • 対象期間はいつですか？（または、どのマイルストーン／サイクル／スプリントですか？）
   • 対象のプロジェクトはどれですか？（有効なプロジェクトが複数ある場合）
   • 対象読者は社内チーム、顧客、または両方ですか？

---

実行方法

フェーズ 1：リリースデータを収集する

チームモード（並列エージェント）

Task ツールを使い、run_in_background: true を指定してデータ収集エージェントを起動します。

エージェント：「github-release-collector」（GitHub が有効な場合）

Collect all merged PRs and release data for the specified version/period.
Repository: [CUSTOMIZE: your-org/your-repo]
Period: [START_DATE] to [END_DATE]

1. Get merged PRs in the period:
   gh pr list --repo [CUSTOMIZE: your-org/your-repo] --state merged --search "merged:[START_DATE]..[END_DATE]" --json number,title,author,labels,body,mergedAt --limit 200

2. Check for existing GitHub release (if version tag exists):
   gh release view [VERSION_TAG] --repo [CUSTOMIZE: your-org/your-repo] --json name,body,tagName,createdAt 2>/dev/null

3. Get commits between tags (if applicable):
   gh api repos/[CUSTOMIZE: your-org/your-repo]/compare/[PREV_TAG]...[CURRENT_TAG] --jq '.commits[] | {sha: .sha[:7], message: .commit.message, author: .author.login}'

Categorize each PR by its labels or title prefix:
- "feat"/"feature"/"enhancement" labels → Enhancements
- "fix"/"bug"/"bugfix" labels → Bug Fixes
- "tech"/"refactor"/"chore"/"infrastructure" labels → Technical Improvements
- "docs"/"documentation" labels → Documentation
- "security" labels → Security
- "breaking"/"breaking-change" labels → Breaking Changes
- "deprecation" labels → Deprecations

Return: categorized list of changes with PR numbers, titles, authors, and descriptions

エージェント：「linear-release-collector」（Linear が有効な場合）

Collect completed issues for the specified cycle/period.

1. Use ToolSearch to load Linear tools
2. List cycles: mcp__claude_ai_Linear_2__list_cycles
3. Find the target cycle or filter by date range
4. List all completed issues in the cycle/period: mcp__claude_ai_Linear_2__list_issues
5. For each issue, get details including labels and project

Categorize by label or issue type:
- Feature/Enhancement labels → Enhancements
- Bug labels → Bug Fixes
- Technical/Infrastructure labels → Technical Improvements
- Documentation labels → Documentation

Return: categorized list of changes with issue IDs, titles, assignees, and descriptions

エージェント：「jira-release-collector」（Jira が有効な場合）

Collect issues for the specified version/sprint.
Project: [CUSTOMIZE: YOUR-PROJECT-KEY]

1. Search by fixVersion:
   JQL: project = "[CUSTOMIZE: YOUR-PROJECT-KEY]" AND fixVersion = "[VERSION]" AND status = Done ORDER BY issuetype, priority DESC

   OR search by sprint:
   JQL: project = "[CUSTOMIZE: YOUR-PROJECT-KEY]" AND sprint = "[SPRINT_NAME]" AND status = Done ORDER BY issuetype, priority DESC

2. For each issue, collect: key, summary, issuetype, priority, assignee, labels, description

Categorize by issue type:
- Story/Feature → Enhancements
- Bug → Bug Fixes
- Task/Technical Task → Technical Improvements
- Documentation → Documentation

Return: categorized list with issue keys, titles, assignees, types, and descriptions

ソロモード

主要なトラッカーから順次データを収集します。

手動入力へのフォールバック

有効なトラッカーがない場合、またはユーザーが手動入力を希望する場合：

No project tracker detected. You can provide release items manually.

Please list the changes in this release. I'll categorize them for you.
Format: one change per line, optionally prefix with [feature], [fix], [tech], [docs], [security], [breaking]

フェーズ 2：分類して整理する

収集した項目を標準カテゴリに分類します。

1. 破壊的変更（該当する場合は必ず最初に記載）
2. 新機能と機能強化
3. バグ修正
4. 技術的な改善
5. セキュリティ更新
6. ドキュメント
7. 非推奨化
8. 既知の問題（残っている場合）

各カテゴリ内では、次の順に並べます。

1. 優先度（高いものから）
2. ユーザーへの影響（影響の大きいものから）

フェーズ 3：リリースノートを生成する

顧客／社外向け：

---
type: release-notes
project: [project-name]
version: [version]
date: [YYYY-MM-DD]
created: [YYYY-MM-DD HH:MM]
audience: external
tags: ["#release-notes", "#[project-name]", "#v[version]"]
items_count: [total count]
categories:
  enhancements: [count]
  bug_fixes: [count]
  technical: [count]
  security: [count]
  breaking_changes: [count]
---

# Release Notes — [Project Name] [Version]

**Release Date:** [Date]

## What's New

[2-3 sentence executive summary of the most important changes in this release]

---

### Breaking Changes

> **Action Required:** The following changes may require updates to your workflow.

- **[Change title]** — [User-friendly description of what changed and what to do]

---

### New Features & Enhancements

- **[Feature title]** — [User-friendly description focused on the benefit to users]
- **[Feature title]** — [User-friendly description]

### Bug Fixes

- **[Fix title]** — [What was broken and how it's fixed, in user terms]
- **[Fix title]** — [Description]

### Security Updates

- **[Update title]** — [Description without exposing vulnerability details]

### Deprecations

- **[Deprecated feature]** — [What's being deprecated, timeline, and migration path]

---

### Known Issues

- [Known issue description] — [Workaround if available]

---

*For questions or feedback, [CUSTOMIZE: contact info or link]*

社内／チーム向け：

---
type: release-notes
project: [project-name]
version: [version]
date: [YYYY-MM-DD]
created: [YYYY-MM-DD HH:MM]
audience: internal
tags: ["#release-notes", "#[project-name]", "#v[version]"]
source_tracker: [github/linear/jira/manual]
---

# Release Notes — [Project Name] [Version] (Internal)

**Release Date:** [Date]
**Cycle/Sprint:** [Name if applicable]

## Summary
[Executive summary with key stats: N features, N fixes, N tech improvements]

---

### Breaking Changes
- **[Title]** ([PR/Issue #link]) — [Technical description] — @[author]

### New Features & Enhancements
- **[Title]** ([PR/Issue #link]) — [Description] — @[author]

### Bug Fixes
- **[Title]** ([PR/Issue #link]) — [Description] — @[author]

### Technical Improvements
- **[Title]** ([PR/Issue #link]) — [Description] — @[author]

### Documentation
- **[Title]** ([PR/Issue #link]) — [Description] — @[author]

---

### Stats
- **Total items:** [N]
- **Contributors:** [list of contributors]
- **PRs merged:** [N]
- **Issues resolved:** [N]

---

### Known Issues & Follow-ups
- [ ] [Issue description] — Owner: [name]

フェーズ 4：レビューゲート

生成したリリースノートをユーザーに提示します。

Release notes draft is ready for [Project] [Version].

Summary:
- [N] New Features & Enhancements
- [N] Bug Fixes
- [N] Technical Improvements
- [N] other items

Audience: [external/internal]

Would you like to:
a) Review the full release notes
b) Save as-is to the vault
c) Make changes
d) Publish to [active platform] (requires your approval)

自動で公開してはいけません。必ずユーザーの明示的な承認を待ちます。

フェーズ 5：Vault に保存する

保存先：04-projects/[project]/release-notes/release-[version]-YYYY-MM-DD.md

mkdir -p "04-projects/[project]/release-notes"

フェーズ 6：公開する（任意、承認が必要）

ユーザーが明示的に承認した場合にのみ進めます。

GitHub リリース

gh release create [VERSION_TAG] \
  --repo [CUSTOMIZE: your-org/your-repo] \
  --title "[Project] [Version]" \
  --notes-file [path-to-release-notes]

Confluence

Use WebFetch to publish via Confluence REST API:
- Space: [CUSTOMIZE: YOUR-SPACE-KEY]
- Parent page: [CUSTOMIZE: Release-Notes-parent-page-id]
- Title: "Release Notes — [Project] [Version]"

Notion

1. Use ToolSearch to load Notion tools
2. Use mcp__claude_ai_Notion__notion-create-pages

HackMD

Use WebFetch to publish via HackMD API

公開後、Vault 内のコピーを公開 URL で更新します。

---

フォールバック動作

シナリオ	動作
有効なトラッカーがない	手動入力を受け付けるか、対象期間のコミットを git log でスキャンします
トラッカー API が失敗した	git log の分析に切り替えます：git log --oneline [PREV_TAG]..[CURRENT_TAG]
バージョンタグが指定されていない	代わりに対象期間を使うか、最近完了した作業を一覧表示します
複数のソースが混在している	複数のトラッカーの項目を統合し、重複を除去します
公開プラットフォームがない	Vault のみに保存します
リリースの規模が非常に大きい	「ハイライト」セクションと変更履歴全文に分割します

エラー処理

• 項目が多すぎる場合：100 件を超える場合は、軽微な変更を自動で要約し、重要な項目のみを詳しく記載します
• PR の説明がない場合：代わりに PR のタイトルとコミットメッセージを使用します
• トラッカー間で項目が重複している場合：タイトル／説明を照合して重複を除去します
• コンテキストがあふれる場合：データ収集をページ分割し、バッチごとに要約します