patch-notes

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは、.claude/docs/automation-modes.md に従います （collaborative は常に質問 · guided は主要な項目のみ · autonomous は記録して続行； automation_always_ask のカテゴリでは常に確認します）。

パッチノート

出所の確認 — 履歴を読む前に

これから読む履歴がこのゲームのものか確認してください。 Phase 2 の前にこれを実行し、失敗した場合は停止してください。

1. 最近のログをサンプリングします：git log --oneline -20。空の場合、または git が 利用できない場合は、この確認をスキップしてください — 分類するものがないため、 Phase 2 の変更履歴データなしの分岐で停止するのが適切です。
2. 範囲内のすべてのコミットを1つずつ、次のいずれか1つに分類します：
   • ゲーム — プレイヤーが遊ぶゲームに変更を加えるもの：メカニクス、コンテンツ、バランス、 アート、オーディオ、UI、それらのいずれかのバグ。
   • フレームワーク／メンテナンス — CCGS 自体、またはプロジェクトのツールに変更を加えるもの： スキル、フック、エージェント、テスト計画、CI、フレームワーク自体のドキュメントに関する件名。 プレイヤー向けノートからは除外しますが、停止する理由にはなりません。
   • 不明 — フレームワークとして扱います。確信を持って分類できないコミットを、プレイヤー向けの文章に使ってはいけません。
3. その後、件数に基づいて判断します：
   • ゲームのコミットが1件以上 → 続行し、それらのみを使用します。フィルターが実行されたことが読者に分かるよう、使用した件数と全件数を伝えてください。
   • ゲームのコミットが0件 → 以下のメッセージを使って停止し、フィルターが実行されたことが読者に分かるよう、件数（全件中0件）を伝えてください。

リポジトリにメンテナンス作業が含まれているだけで停止せず、コミットごとにフィルタリングしてください。 このフレームワーク上に構築されたすべてのプロジェクトには、フック、CI、スキルに関するコミットが蓄積されます — ゲームのリポジトリはフレームワークのリポジトリでもあるため、リポジトリ単位で停止すると、実際のプロジェクトのほぼすべてで処理が止まります。危険なのは、そのようなコミットが存在することではなく、プレイヤー向けの文章として出力されることです。それらを除外すれば問題は正確に解決しますが、リポジトリ単位での停止では解決しません。

続行する前に、簡単な方法で裏付けを確認してください：ゲームのコミットには、design/ とコードのルート（src/、Assets/、または Source/）に登場するシステム名が含まれているはずです。これらのディレクトリに一度も登場しない製品名が含まれている場合、それこそが本当に履歴を間違えている兆候です — 停止してください。

範囲内のコミットにこのゲームのものがない場合は、その旨を伝えて停止してください：

「このリポジトリの git 履歴は [game] のものではないようです。最近の [N] 件のコミットのうち、ゲームのコミットは0件です。最近の コミットは実際には [what they actually describe] について記述しています。この履歴からリリースノートは生成できません — 正しい履歴を指定するか、変更リストを直接提示してください。」

判定：ブロック — ここで停止し、ノートを生成しないでください。

これが警告ではなく、強制的な停止である理由。 フレームワーク内部のコミットをプレイヤー向けの文章として出力すると、実際の変更のように読めてしまいます：セッションフックのタイムアウトが、セーブシステムのないゲームで「起動時に前回のセッションの進行状況が失われる問題を修正しました」となります。その文章は流暢で、もっともらしく、完全な誤りです。読者には見分けられません。この確認だけが見分けられます。

---

Phase 1：引数を解析する

• version：ノートを生成するリリースのバージョン（例：1.2.0）
• --style：出力スタイル — brief（箇条書き）、detailed（背景情報付き）、full（開発者の解説付き）。デフォルト：detailed。

バージョンが指定されていない場合は、続行する前にユーザーに尋ねてください。

---

フェーズ 2：変更データを収集する

• production/releases/[version]/changelog.md が存在する場合は、内部変更履歴を読みます
• 該当バージョンの項目があるか、docs/CHANGELOG.md も確認します
• 前回のリリースタグから現在のタグ／HEAD までの git log を実行し、データがない場合の代替とします
• 背景情報として、production/sprints/ にあるスプリントの振り返りを読みます
• design/balance/ にあるバランス変更ドキュメントを読みます
• 入手可能であれば、QA のバグ修正記録を読みます

変更履歴データが見つからない場合（production/releases/[version]/changelog.md がなく、 このバージョンの docs/CHANGELOG.md の項目もなく、さらに git log が空または利用できない場合）：

"[version] の変更履歴データが見つかりません。まず /changelog [version] を実行して 内部変更履歴を生成してから、/patch-notes [version] を再実行してください。"

判定：BLOCKED — ここで停止し、ノートを生成しないでください。

---

フェーズ 2b：トーンガイドとテンプレートを検出する

トーンガイドの検出 — ノートを作成する前に、文体のガイダンスを確認します。

1. .claude/docs/technical-preferences.md に「tone」「voice」「style」の各フィールドまたはセクションがないか確認します。
2. docs/PATCH-NOTES-STYLE.md が存在する場合は確認します。
3. design/community/tone-guide.md が存在する場合は確認します。
4. いずれかの情報源にトーン／語り口／文体の指示があれば、それを抽出し、生成するノートの言葉遣いと表現に適用します。
5. どこにもトーンのガイダンスがない場合は、プレイヤーに親しみやすく、専門用語を避け、熱意は込めつつ大げさにせず、開発者の変更内容ではなくプレイヤーが体験することに焦点を当てることを既定とします。

テンプレートの検出 — パッチノートのテンプレートがあるか確認します。

1. docs/patch-notes-template.md と .claude/docs/templates/patch-notes-template.md を glob で検索します。
2. どちらかの場所で見つかった場合は、そのテンプレートを読み、組み込みのスタイルテンプレート（簡潔／詳細／全内容）の代わりに、フェーズ 4 の出力構成として使用します。分類したデータをテンプレートの各セクションに当てはめ、各カテゴリを意味の同じセクションに対応させます（新コンテンツ → 新機能のセクション、バグ修正 → 修正のセクションなど）。対応するセクションがないカテゴリは、最も近いセクションに含め、省略しないでください。テンプレートのヘッダーとフッターの文言はそのまま維持します。出力では、使用したテンプレートを明記し、--style が指定されている場合は、テンプレートがそのスタイルに代わって使用されたことも伝えます。
3. 見つからない場合は、フェーズ 4 で定義されている組み込みのスタイルテンプレートを使用します。

---

フェーズ 3：分類して翻訳する

変更をすべて、プレイヤー向けのカテゴリに分類します。

• 新コンテンツ：新機能、マップ、キャラクター、アイテム、モード
• ゲームプレイの変更：バランス調整、メカニクスの変更、進行状況の変更
• 利便性の向上：UI の改善、便利な機能、アクセシビリティ
• バグ修正：システム別に分類（戦闘、UI、ネットワークなど）
• パフォーマンス：プレイヤーが気づく可能性のある最適化の改善
• 既知の問題：未解決の問題について明示する

開発者向けの表現をプレイヤー向けの表現に変換します。

• 「ダメージ計算パイプラインをリファクタリング」→「攻撃の命中判定の精度を改善」
• 「インベントリマネージャーの null 参照を修正」→「インベントリを開くとクラッシュする問題を修正」
• 「戦闘ループの GC 割り当てを削減」→「戦闘中のパフォーマンスを改善」
• プレイヤーに影響しない、純粋に内部的な変更は削除します
• バランス変更の具体的な数値を維持します（ダメージ：50 → 45）

---

フェーズ 4：パッチノートを生成する

簡潔なスタイル

# Patch [Version] — [Title]

**New**
- [Feature 1]
- [Feature 2]

**Changes**
- [Balance/mechanic change with before → after values]

**Fixes**
- [Bug fix 1]
- [Bug fix 2]

**Known Issues**
- [Issue 1]

詳細なスタイル

# Patch [Version] — [Title]
*[Date]*

## Highlights
[1-2 sentence summary of the most exciting changes]

## New Content
### [Feature Name]
[2-3 sentences describing the feature and why players should be excited]

## Gameplay Changes
### Balance
| Change | Before | After | Reason |
| ---- | ---- | ---- | ---- |
| [Item/ability] | [old value] | [new value] | [brief rationale] |

### Mechanics
- **[Change]**: [explanation of what changed and why]

## Quality of Life
- [Improvement with context]

## Bug Fixes
### Combat
- Fixed [description of what players experienced]

### UI
- Fixed [description]

### Networking
- Fixed [description]

## Performance
- [Improvement players will notice]

## Known Issues
- [Issue and workaround if available]

全内容スタイル

詳細なスタイルのすべての内容に加えて、以下を含みます。

## Developer Commentary
### [Topic]
> [Developer insight into a major change — why it was made, what was considered,
> what the team learned. Written in first-person team voice.]

---

フェーズ 5：出力を確認する

生成したノートについて、以下を確認します。

• 内部用語が使われていない（技術用語をプレイヤーにわかりやすい表現に置き換える）
• 内部システム、チケット、スプリント番号への言及がない
• バランス変更に変更前／変更後の値が含まれている
• バグ修正で技術的な原因ではなく、プレイヤーが体験する内容を説明している
• トーンがゲームの語り口に合っている（ゲームのスタイルに応じてかしこまり具合を調整する）

フェーズ 6：パッチノートを保存する

変更カテゴリごとの件数と、レビュー用に除外した内部変更を添えて、完成したパッチノートをユーザーに提示します。

次のように尋ねます。「このパッチノートを docs/patch-notes/[version].md に、アーカイブ用のコピーを production/releases/[version]/patch-notes.md に書き込んでもよろしいですか？」

承諾された場合は、必要に応じてディレクトリを作成し、両方のファイルを書き込みます。 承諾されなかった場合は、何も書き込みません。

---

フェーズ 7：次のステップ

判定：完了 — パッチノートを生成して保存しました。（書き込みが拒否された場合：判定：完了 — パッチノートを生成して提示しましたが、保存していません。）

• 公開前に、ほかのすべてのリリースゲートが満たされていることを確認するため、/release-checklist を実行します。
• 公開前に、トーンのレビューを受けるため、パッチノートのドラフトを community-manager と共有します。