team-release

チームリリース

引数の確認： バージョン番号が指定されていない場合：

1. production/session-state/active.md と production/milestones/ 内の最新ファイル（存在する場合）を読み込み、対象バージョンを推定します。
2. バージョンが見つかった場合は、「バージョン引数が指定されていません — マイルストーンデータから [version] を推定しました。続行します。」と報告します。その後、AskUserQuestion で「[version] をリリースします。よろしいですか？」と確認します。
3. バージョンを特定できない場合は、AskUserQuestion を使って「リリースするバージョン番号は何ですか？（例：v1.0.0）」と尋ね、続行する前にユーザーの入力を待ちます。ハードコードされたバージョン文字列をデフォルトとして使用してはいけません。

このスキルが呼び出されたら、構造化されたパイプラインを通じてリリースチームを統括します。

意思決定ポイント： 各フェーズの移行時に、AskUserQuestion を使い、サブエージェントの提案を選択肢としてユーザーに提示します。エージェントの分析全文を会話に記載し、その後、簡潔なラベルで決定を記録します。 collaborative モードでは、次のフェーズに進む前にユーザーの承認が必要です。 guided モードでは、フェーズが BLOCKED でない限り、パイプラインは自動的に進みます。 autonomous モードでは、log_decision を使って各フェーズの結果を記録しながら、最初から最後まで実行します。 automation_always_ask カテゴリー（is_always_ask_category ヘルパー）に属する決定では、モードにかかわらず必ずユーザーに確認します。.claude/docs/automation-modes.md を参照してください。

フェーズ 0：設定の解決

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,workflow,project.stage

上記で解決済みです — そのまま使用してください。--review は review_mode を上書きします。ブロックされていない場合は、.claude/docs/config-resolution.md のデフォルト値を使用します。

ステージの確認 — 何かを起動する前に実施します。 このスキルはリリースを実行するものであり、/gate-check release は最初に通過しなければならない準備状況のゲートです。PASS になった場合のみ、project.stage が Release に設定されます。解決された project.stage が Polish、それ以前のステージ、または未設定の場合は、フェーズ 1 の前に停止し、何も起動しないでください。

「リリース準備状況のゲートに合格していません（project.stage: [stage]）— 先に /gate-check release を実行してください。」

続いて、すべての automation モードで AskUserQuestion を使って確認します。ユーザーに代わって上書きを選択してはいけません：[A] 停止 — /gate-check release を実行します（推奨）／[B] このまま進む — ステージ確認を上書きします。[A] の場合は実行を終了します。判定は BLOCKED — リリースゲートに未合格。 [B] の場合は、理由を（プレーンテキストで）尋ね、フェーズ 1 の概要、Go／No-Go 記録（go-no-go-[version].md）、および最終レポートに、上書き内容を Stage override: project.stage was [stage] — release gate not passed; the user chose to proceed: [reason] として記録します。上書きによってステージ自体が変更されることはありません。

review_mode はディレクターゲートの深度を設定しますが、このパイプラインにはディレクターゲートがありません。どの review_mode でも、以下のフェーズで CD-、TD-、PR-、AD-PHASE-GATE が起動されることはありません。パイプラインのフェーズゲートは独自の意思決定ポイント（以下の team.size で定義）であり、そこで作業するエージェントはチームメンバーであって、ディレクターゲートではありません。

automation は上記の「意思決定ポイント」の説明に従って動作します。各モードによるパイプラインの動作の違いについては、上記の「意思決定ポイント」と .claude/docs/automation-modes.md を参照してください。 team.size：アクティブなエージェントを指定します（review_mode のゲート深度やワークフローのドキュメントとは独立しています）。

• individual（デフォルト）：release-manager のみです。他のエージェントには release-manager を通じて相談し、個別には起動しません。
• small：さらに producer、devops-engineer、qa-lead、community-manager が加わります。
• studio：さらに security-engineer、analytics-engineer、localization-lead、performance-analyst が加わり、ゲームがマルチプレイヤーの場合は network-programmer も加わります（ドキュメントに記載された完全なパイプラインです）。 individual でコア以外のエージェントが必要な場合は、情報を添えて最も近いアクティブなコアエージェントを通じて対応します。「フェーズゲート」とは、このパイプラインに記載された AskUserQuestion の判断ポイントで終わるフェーズを指します。つまり、上記の判断ポイントでの遷移、ステージチェック、または Phase 6 のデプロイに関する質問です。automation モードは問いません。guided と autonomous ではゲートの通過方法が変わります（自動で次へ進むか、log_decision で記録されます）が、ゲートであることに変わりはありません。そのため、以下の限定例外の条件（3）はどのモードでも満たされます。「フェーズゲートでのみ」起動が許可されているエージェントは、該当するポイントでのみ起動し、それ以外では起動しません。このアクティブセットの適用範囲は以下のパイプライン全体です。アクティブセット外のエージェントを指定するフェーズでは、そのエージェントを起動せず、最も近いコアエージェントを通じて対応します。

Phase 1 の前にアクティブセットを告知してください。縮小を黙って済ませてはいけません。 何かを起動する前に、この実行で実際に起動するエージェントと、以下のパイプラインで名前が挙がっているものの、解決済みの team.size では起動しないエージェントを1行で伝えてください。たとえば、次のようにします。

Active set (team.size: <resolved>): <the agents listed for that size above>. Not spawned this run: <every other agent this pipeline names> — consulted through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.

直前の team.size の一覧と、このファイル自体のパイプラインで指定されているエージェントから内容を埋めてください。例から流用してはいけません。どちらのセットもオーケストレーターごとに異なります。

以下のパイプラインは複数エージェントへの並列的な割り当てとして読めますが、提供時のデフォルトではエージェントは1〜2体です。team-release は10体を指定しますが、実際に動くのは1体です。team-narrative は5つのフェーズにわたって6体を指定しますが、動くのは writer だけです。この縮小は意図どおりです。team.size は厳格さを優先する設定であり、狭いデフォルトはトークンを節約するための調整手段です。 このことを明示しないと、読み手は正しく縮小された実行と、壊れたパイプラインを区別できません。また、エージェントごとの「情報を添えて最も近いアクティブなコアエージェントを通じて対応する」というルールは、振り分けの時点で適用されるだけで、実行全体の構成は示されません。

これは、このファイル内の他の箇所にあるチェック省略の報告ルールと同じです。適用された制約が表に出されなければ、出力を読む人には、制約が適用されなかった場合と見分けがつきません。

チーム構成

• release-manager — リリースタグ、バージョン管理、変更履歴、パッチノート、デプロイ
• qa-lead — テスト承認、回帰テストスイート、リリース品質ゲート
• devops-engineer — ビルドパイプライン、成果物、デプロイの自動化
• security-engineer — リリース前のセキュリティ監査（ゲームにオンライン機能、マルチプレイヤー機能、またはプレイヤーデータがある場合に呼び出します）
• network-programmer — ネットコードの安定性の承認（ゲームにマルチプレイヤー機能がある場合に呼び出します）
• analytics-engineer — テレメトリーイベントが正しく発火し、ダッシュボードが稼働していることを確認
• localization-lead — リリースされるすべての文字列が翻訳済みであることを確認
• performance-analyst — リリースビルドをパフォーマンス目標と照らし合わせてベンチマーク
• community-manager — パッチノートをもとに、ローンチ告知とプレイヤー向けメッセージを作成
• producer — Go／No-Go の判断、ステークホルダーとの連絡、スケジュール管理

委任方法

各チームメンバーをサブエージェントとして起動するには、Agent ツールを使用します。

• subagent_type: release-manager — リリースタグ、バージョン管理、変更履歴、パッチノート、デプロイ
• subagent_type: qa-lead — テスト承認、回帰テストスイート、リリース品質ゲート
• subagent_type: devops-engineer — ビルドパイプライン、成果物、デプロイ自動化
• subagent_type: security-engineer — オンライン／マルチプレイヤー／データ機能のセキュリティ監査
• subagent_type: analytics-engineer — テレメトリーイベントの検証、ダッシュボードの準備状況
• subagent_type: community-manager — パッチノートをもとにしたリリース告知
• subagent_type: producer — Go／No-Go の判断、ステークホルダーへの連絡
• subagent_type: network-programmer — ネットコードの安定性承認（ゲームにマルチプレイヤー機能がある場合に起動）
• subagent_type: localization-lead — 翻訳の完全性に関する承認（フェーズ 4）
• subagent_type: performance-analyst — 目標値に対するパフォーマンスベンチマーク（フェーズ 4）

各エージェントには要点を伝えてください。コンテキストをそのまま渡してはいけません。 共有入力は一度だけ読み、必要な行だけを抽出した簡潔な概要をインラインで渡します。すでに読んだドキュメントのファイルパスは絶対に渡さないでください（パスを渡されたエージェントはファイル全体を読み直します）。まだ読んでおらず、そのエージェントだけが必要とするドキュメントに限り、パスを渡してください。

すべてのエージェントプロンプトの末尾に、次の返却要件を必ず付けてください。 「完全な出力を [path] に書き込んでください。この指定パスは、以下の限定的な例外に基づく書き込み許可です。別途承認を求めずに書き込んでください。返答は（1）書き込んだパス、（2）判断事項の箇条書き（最大 5 項目）、（3）BLOCKED／CONCERNS 項目（一項目につき一行）のみとしてください。読んだドキュメントの内容を繰り返さないでください。」これを付けないと、エージェントが読んだ内容をすべてこのセッションに返してしまいます。

[path] は実際のパスに置き換えてください。2 つのエージェントは指定された別の保存先を使用し、それ以外はエージェントごとに production/releases/ 内へ 1 ファイルずつ作成します。担当外のエージェントの役割を代行する場合も、そのエージェントのファイルに書き込みます。

フェーズ／エージェント	書き込み先	保存先の指定元
1 producer	production/releases/release-plan-[version].md	このスキル
2 release-manager	production/releases/release-checklist-[version].md	/release-checklist
3 qa-lead	production/releases/qa-gate-[version].md	このスキル
3 devops-engineer	production/releases/build-[version].md	このスキル
3 security-engineer	production/releases/security-signoff-[version].md	このスキル
3 network-programmer	production/releases/netcode-signoff-[version].md	このスキル
4 localization-lead	production/releases/localization-signoff-[version].md	このスキル
4 performance-analyst	production/releases/performance-signoff-[version].md	このスキル
4 analytics-engineer	production/releases/analytics-signoff-[version].md	このスキル
5 go/no-go	production/releases/go-no-go-[version].md	このスキル
6 release-manager	docs/patch-notes/[version].md	/patch-notes
6 community-manager	production/releases/announcement-[version].md	このスキル
7 release-manager	production/releases/release-report-[version].md	このスキル

これら 13 件の出力すべてに、保存先を明記する必要があります。 /release-checklist がすでに書き込む先は production/releases/、/patch-notes がすでに書き込む先は docs/patch-notes/[version].md です。そのため、どちらのスキルが作成しても、リリース記録は所定の場所に保存されます。

記録を追記するのではなく、エージェントごとに別のファイルを作成してください。 フェーズ 3 とフェーズ 4 ではエージェントを並行して起動します。複数のエージェントが同じファイルに追記すると競合し、片方のセクションが気付かれないまま消失します。 これが Collaboration Protocol に違反しない理由。 CLAUDE.md では、Write/Edit の前にエージェントが「これを [filepath] に書き込んでもよいですか？」と尋ねるよう求めています。ここで起動したサブエージェントは、尋ねることなく書き込みます。これは見落としではなく、意図的かつ範囲を限定した例外です。consistency-check が active.md に追記することをすでに認めた判断と同じです。この例外が適用されるのは、次の3つすべてに当てはまる場合のみです。（1）パスがプロンプトであなたが指定したもの。つまり、フェーズを承認した時点でユーザーが保存先も承認しています。（2）production/、docs/、tests/ のいずれかにある新しい成果物であり、既存のソースや設定ファイルの編集ではないこと。（3）その成果物を作成するフェーズ自体が、パイプラインの進行前に AskUserQuestion による承認を受けること。これら3つに該当しない場合、エージェントは尋ねなければなりません。サブエージェントごとに尋ねるよう「修正」しないでください — フェーズごとにエージェント1つにつきプロンプト1つを要求すると、オーケストレーターが使いものにならなくなるため、この例外を設けています。

パイプラインで可能な場合は、独立したエージェントを並行して起動してください（例：フェーズ3のエージェントは同時に実行できます）。

パイプライン

フェーズ1：リリース計画

producer に委任します：

• マイルストーンの受け入れ基準がすべて満たされていることを確認する
• 今回のリリースで延期されたスコープ項目を特定する
• リリース目標日を設定し、チームに伝える
• 出力：スコープ確認を含むリリース承認

フェーズ2：リリース候補

release-manager に委任します：

• main 上の関連ファイルすべてでバージョン番号を更新します。更新を含むコミットがリリース候補になります。開発はトランクベースです。リリースはブランチではなく、main に付けるタグです（フェーズ6で適用）
• Polish のリリースチェックリスト（/release-checklist、/gate-check release の実行前に実施）がこの候補について完了していることを確認します。まだ存在しない場合のみ、今ここで実行します
• このリリースで安定化（フリーズ、プラットフォーム認証）が必要な場合に限り、候補から release/[version] ブランチを作成します。そこでの修正はバグ修正に限り、すべての修正を main にも反映します
• 出力：リリース候補のコミット（作成した場合は release/* ブランチも含む）とチェックリスト

フェーズ3：品質ゲート（並行実行）

並行して委任します：

• qa-lead：回帰テストスイート全体を実行します。すべてのクリティカルパスをテストします。この workflow で /gate-check release がブロックする重大度（すべてのティアでS1、full ではS2とS3も）の未解決バグがないことを確認します。品質を承認します。
• devops-engineer：対象プラットフォームすべてのリリース成果物をビルドします。ビルドがクリーンで再現可能であることを確認します。CIで自動テストを実行します。
• security-engineer（ゲームにオンライン機能、マルチプレイヤー機能、またはプレイヤーデータがある場合）：リリース前のセキュリティ監査を実施します。認証、不正対策、データプライバシーへの準拠を確認します。セキュリティ態勢を承認します。
• network-programmer（ゲームにマルチプレイヤー機能がある場合）：ネットコードの安定性を承認します。ラグ補償、再接続処理、負荷時の帯域幅使用量を確認します。

いずれかのエージェントが有効なエージェントのセットに含まれる場合は、project.yaml の platform.online と platform.multiplayer、およびゲームがプレイヤーデータを保存するかどうかから、その条件を判断してください。キーが存在しない場合、それは false を意味するわけではありません。オフラインのゲームだと決めつけず、ユーザーに確認してください。この理由でエージェントを起動しない場合は、フェーズ3の出力で名前を挙げて明記します。例：security-engineer: not spawned — platform.online: false, platform.multiplayer: false, no player data

フェーズ4：ローカライズ、パフォーマンス、分析

委任します（リソースがあればフェーズ3と並行して実行できます）：

• すべての文字列が翻訳されていることを確認します（可能であれば localization-lead に委任します）
• 目標に対するパフォーマンスベンチマークを実行します（可能であれば performance-analyst に委任します）
• analytics-engineer：リリースビルドですべてのテレメトリーイベントが正しく発生することを確認します。ダッシュボードがデータを受信していることを確認します。重要なファネル（オンボーディング、進行状況、該当する場合は収益化）が計測されていることを確認します。
• 出力：ローカライズ、パフォーマンス、分析の承認 — エージェントごとに1ファイル（上の表を参照）

Phase 5: Go/No-Go

委任する前に、technical-director からリリースの承認を得てください。producer はエージェントを起動できないため、オーケストレーターが起動します。review_mode: full の場合にのみ technical-director を起動してください。これはディレクターによるレビューであり、PHASE-GATE ではないため、lean と solo では省略します。リリース候補の技術的な状態について、GO、CONCERNS、NO-GO のいずれか、または確認できなかった内容を示す NOT ASSESSED を求めてください。起動しない場合、Go/No-Go 記録には、承認済みとして列挙する代わりに technical-director sign-off: not run (review_mode: <mode>) と記録します。NOT ASSESSED の回答はそのまま記録し、承認として数えてはいけません。

producer に委任し、これまでに集めたすべての承認を渡してください。

• 承認を集める対象：qa-lead、release-manager、devops-engineer、security-engineer（Phase 3 で起動した場合）、network-programmer（Phase 3 で起動した場合）、technical-director（上記で起動した場合）
• ステージチェックのオーバーライドがあった場合は、Stage override: の行として Go/No-Go 記録に引き継ぐ
• 未解決の問題を評価する — リリースを妨げるものか、リリースしてよいものか？
• Go/No-Go の判断を下す
• 出力：根拠を添えたリリース判断

producer が NO-GO と判断した場合：

• 判断を直ちに提示します：「PRODUCER: NO-GO — [根拠。例：Phase 3 で S1 バグを発見]。」
• 次の選択肢を提示して AskUserQuestion を使用します。
  • ブロッカーを修正して、該当するフェーズを再実行する
  • リリースを後日に延期する
  • 根拠を文書化して NO-GO をオーバーライドする（ユーザーは書面で正当な理由を提示する必要があります）
• Phase 6 は完全にスキップします — タグ付け、ステージング環境へのデプロイ、本番環境へのデプロイ、community-manager の起動は行いません。
• Phase 1～5 と、Phase 6 をスキップしたことおよびその理由をまとめた部分レポートを作成します。
• 判定：BLOCKED — リリースはデプロイされていません。

ユーザーが「根拠を文書化して NO-GO をオーバーライドする」を選択した後：

• （ウィジェットではなく）通常のテキストで質問します：「NO-GO 判定をオーバーライドする正当な理由を説明してください。この内容はリリース記録に埋め込まれます。」
• ユーザーが書面で正当な理由を提示するまで待ちます。
• Phase 6 の前に、その理由を部分承認記録に埋め込み、「⚠️ Override Justification: [user's text]」フィールドを追記します。
• その後に限り、Phase 6 に進みます。

Phase 6: デプロイ（GO の場合）

このフェーズでは、modes.automation の設定に関係なく、autonomous モードも含め、常にユーザーの明示的な承認が必要です。 本番環境へのデプロイは取り消せず、重大な影響を伴います。また、設定可能な automation_always_ask カテゴリーの対象外であるため、このスキルでは例外なくユーザーの承認を求めます。タグ付けまたはデプロイの前に、AskUserQuestion を使用します。

• プロンプト：「Producer の判定は GO です。Phase 6 を実行しますか — タグ付け、ステージング環境へのデプロイ、本番環境へのデプロイ？」
• 選択肢：[A] はい、デプロイする / [B] ステージングのみ — 本番環境へのデプロイは保留 / [C] ここで停止

明示的な承認を得た後に限り、release-manager と devops-engineer に委任します。

• バージョン管理でリリースにタグを付ける
• ポーランド語で下書きされた変更履歴（/changelog）を仕上げ、ゲート以降の変更を追記する
• 最終スモークテストのため、ステージング環境にデプロイする
• 本番環境へのデプロイ（上記でユーザーが本番環境へのデプロイを承認した場合のみ）
• 人間のチームによる作業：リリース後48時間、ダッシュボードとエラー率を監視します。48時間後に /retrospective を使用した振り返りを予定します。

デプロイと並行して、release-manager に委任します。

• ポーランド語で下書きされたパッチノートを /patch-notes [version] を使用して仕上げます。release-manager はこのスキルと、その git log 手順で必要な Bash アクセス権を持っていますが、community-manager はどちらも持っていません。

その後、パッチノートを community-manager に渡します。

• リリース告知を準備する（ストアページの更新、ソーシャルメディア、コミュニティへの投稿）
• S3 以上の問題を出荷した場合は、既知の問題に関する投稿を下書きする
• 出力：デプロイ確認時に公開できる、プレイヤー向けリリース告知一式

フェーズ 7：リリース後

• release-manager：リリースレポートを作成します（リリース内容、延期した内容、メトリクス）。
• producer：マイルストーンの追跡情報を更新し、関係者に連絡します。
• qa-lead：新たに寄せられるバグ報告を監視し、リグレッションがないか確認します。
• community-manager：プレイヤー向けの告知をすべて公開し、コミュニティの反応を監視します。
• analytics-engineer：本番ダッシュボードが正常であることを確認し、重要なイベントが欠落している場合はアラートを出します。
• フェーズ 6 の 48 時間の監視期間を維持します。リリース後 48 時間、バグ、ダッシュボード、コミュニティの反応を監視します（release-manager 自身の監視は、72 時間後のレポートまで続きます）。
• 問題が発生した場合は、リリース後の振り返りを予定します。

エラー復旧プロトコル

まず、成果物を確認してください。 返却条件でパスが指定されている場合は、フェーズ完了と判断する前に、そのパスが存在することを確認してください。指定された成果物がディスク上に存在しなければ、応答がどれほど流暢でもフェーズは失敗です。 エージェントがフェーズ全体を費やして何も書き込まず、もっともらしい前置きだけを返すことがあります。これは BLOCKED でもエラーでも「完了できない」でもないため、以下のトリガーは発動しません。満たされていない返却条件を明示して再開してください。通常、コンテキストはまだ残っています。

起動したエージェントが BLOCKED を返す、エラーになる、または完了できない場合：すぐに状況を報告し、そのエージェントが妨げている依存作業を越えて先に進まず、必ず部分レポートを作成してください。 手順の全文は .claude/docs/error-recovery-protocol.md を参照してください。

よくあるブロッカー：

• 入力ファイルが見つからない（ストーリーが見つからない、GDD が存在しない）→ そのファイルを作成するスキルに引き継ぎます。
• ADR のステータスが Proposed → 実装せず、決定後に /architecture-decision accept ADR-NNNN で承認します。
• スコープが大きすぎる → /create-stories で 2 つのストーリーに分割します。
• ADR とストーリーの指示が矛盾している → 矛盾を報告し、推測で判断しないでください。

ファイル書き込みプロトコル

すべてのファイル書き込み（リリースチェックリスト、変更履歴、パッチノート、デプロイスクリプト）は、サブエージェントとサブスキルに委任します。この 2 つには異なるルールが適用され、このパイプラインではその違いが特に重要です。

• Agent 経由で起動したサブエージェントには、前述の「これがコラボレーションプロトコルに違反しない理由」に記載された限定的な例外が適用されます。パスは明示的に指定したものであり、成果物は production/、docs/、tests/ のいずれかに新規作成され、フェーズは AskUserQuestion によってゲートされています。この範囲内では、サブエージェントは書き込みごとに確認を求めません。範囲外では確認が必要です。
• サブスキルはサブエージェントではなく、この例外の対象外です。通常のコラボレーションプロトコルに従い、書き込み前に確認を求めます。

このオーケストレーターはファイルを直接書き込みません。ここに記載された内容は、外部に影響する操作や取り消せない操作を許可するものではありません。タグ付け、プッシュ、ビルド、ストアフロントの変更には、上記のどのルールが適用されるかにかかわらず、明示的な確認が必要です。

出力

リリースバージョン、スコープ、品質ゲートの結果、Go/No-Go の決定、デプロイ状況、監視計画を網羅したサマリーレポート。

判定：COMPLETE — リリースが実行され、デプロイされました。 判定：BLOCKED — リリースは停止しました。ステージチェックで停止された、Go/No-Go の判定が NO だった、または重大なブロッカーが未解決です。

次のステップ

• リリース後のダッシュボードを 48 時間監視します。
• リリース中に重大な問題が発生した場合は、/retrospective を実行します。
• ステージチェックが上書きされていない限り、project.stage は Release を読み取ります。/gate-check release は Polish → Release の準備状況ゲートであり、このスキルの実行前に実行します。上書き後も、ステージは以前と同じ値を読み取ります。project.stage を変更するのは /gate-check のみです（PASS の場合、またはリスクをユーザーが受け入れた CONCERNS の場合）。そのため、このスキルは project.stage も production/stage.txt も書き込みません。Release は project.stage の列挙型における最終ステージであり、ローンチ後のステージ値はありません。ライブ／ローンチ後のステータスは project.stage ではなく、リリースレポートに記録してください。