team-live-ops

チームライブオペレーション

引数の確認： シーズン名またはイベントの説明が指定されていない場合は、次のように出力します。

"Usage: /team-live-ops [season name or event description] [--review full|lean|solo] — 計画するシーズンまたはライブイベントの名前か説明を指定してください。" その後、サブエージェントを起動したり、ファイルを読み込んだりせず、直ちに停止します。

有効な引数を指定してこのスキルを呼び出した場合は、構造化された計画パイプラインを通じてライブオペレーションチームを統括します。

意思決定ポイント： 各フェーズの移行時に、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

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

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

automation は、上記の意思決定ポイントに関する注記に反映されます。各モードによってパイプラインの動作がどう変わるかについては、上記の意思決定ポイントに関する注記と .claude/docs/automation-modes.md を参照してください。

team.size：アクティブなエージェントを指定します（review_mode のゲート深度やワークフロードキュメントとは独立しています）。

• individual（デフォルト）：live-ops-designer + economy-designer。その他のエージェントには、この 2 つを通じて相談し、個別には起動しません。
• small：+ analytics-engineer + community-manager。
• studio：+ writer + narrative-director（ドキュメントに記載されている完全なパイプライン）。 individual でコア以外のエージェントが必要な場合は、情報注記を添えて、最も近いアクティブなコアエージェントを通じて対応します。「フェーズゲート」とは、automation モードにかかわらず、このパイプライン自体が記載する AskUserQuestion の意思決定ポイントで終わるフェーズすべてを指します。つまり、上記の意思決定ポイントに記載された移行、または以下のパイプラインに記載された ゲート ステップです。guided と autonomous はゲートの通過方法（自動的に次へ進むか、log_decision で記録するか）を変えるだけで、ゲートであるかどうかは変えません。そのため、以下の例外条件（3）はすべてのモードで適用されます。「フェーズゲートのみ」に制限されたエージェントは、それらのポイントでのみ起動され、それ以外では起動されません。このアクティブセットの適用範囲は以下のパイプライン全体に及びます。アクティブセット外のエージェントを指定するフェーズは、そのエージェントを起動するのではなく、最も近いコアエージェントを通じて対応します。

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

Active set (team.size: <resolved>): <上記でこのサイズに指定されているエージェント>. Not spawned this run: <このパイプラインに記載されているその他すべてのエージェント> — <最も近いアクティブなコアエージェント>を通じて相談。 範囲を広げるには、team.size（または modes.rigor）を引き上げてください。

直上の team.size のリストと、このファイルのパイプラインに記載されたエージェントから内容を埋めてください。例から転記してはいけません。どちらのセットもオーケストレーターごとに異なります。

以下のパイプラインは、複数エージェントへの振り分けとして書かれていますが、提供時のデフォルトでは 1 つか 2 つのエージェントになります。team-release は 10 個を指定し、そのうち 1 個を実行します。team-narrative は 5 つのフェーズにわたって 6 個を指定し、writer のみを実行します。この縮小は正しい動作です。team.size は厳密さを左右する主要な設定であり、狭いデフォルトはトークン数を調整する手段です。 これを明示しないと、読み手は適切に縮小された実行とパイプラインの不具合を区別できません。また、エージェントごとの「情報注記を添えて、最も近いアクティブなコアエージェントを通じて対応する」という上記のルールは、ルーティング時に適用されるだけで、実行全体の構成が示されることはありません。

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

チーム構成

• live-ops-designer — シーズン構成、イベント開催頻度、継続率を高める仕組み、バトルパス
• economy-designer — ライブ経済のバランス、ストアのローテーション内容と価格（開催頻度は live-ops-designer が設定）、通貨の価格設定、天井タイマー
• analytics-engineer — 成功指標、A/B テストの設計、イベントトラッキング、ダッシュボードの仕様
• community-manager — プレイヤー向けのお知らせ、イベントの説明、シーズンのメッセージ
• narrative-director — シーズンの物語テーマ、ストーリー展開、ゲーム内イベントの位置付け
• writer — イベントの説明、報酬アイテム名、シーズンのフレーバーテキスト、お知らせ文

委任方法

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

• subagent_type: live-ops-designer — シーズン／イベント構成と継続率を高める仕組み
• subagent_type: economy-designer — ライブ経済のバランスと報酬の価格設定
• subagent_type: analytics-engineer — 成功指標、A/B テスト、イベントの計測設定
• subagent_type: community-manager — プレイヤー向けのコミュニケーションとメッセージ
• subagent_type: narrative-director — シーズンのテーマと物語の位置付け
• subagent_type: writer — プレイヤー向けテキスト全般：イベントの説明、アイテム名、文案

各エージェントには要点を伝えてください。コンテキストをそのまま渡してはいけません。共有インプットは一度だけ読み、要点をまとめたブリーフをインラインで渡します。各エージェントが実際に必要とする行だけを渡し、すでに読んだ文書のファイルパスは渡しません（パスを渡されたエージェントはファイル全体を読み直します）。未読で、そのエージェントだけが必要とする文書に限り、パスを渡してください。

エージェントへのすべてのプロンプトは、次の成果物の返却条件で締めくくってください。「出力全体を [path] に書き込んでください。そのパスは、以下の限定的な例外に基づく書き込み許可先として指定されているため、別途承認を求めずに書き込んでください。返答は、（1）書き込んだパス、（2）決定事項の箇条書き5項目以内の要約、（3）BLOCKED／CONCERNS 項目（各1行）のみとしてください。読んだ文書の内容を繰り返さないでください。」これがないと、エージェントは読んだ内容をすべてこのセッションに返してしまいます。

**[path] は実際のパスに置き換えてください。**作業用成果物は production/live-ops/[season-slug]/ の下に置きます。[season-slug] は引数をスラッグ形式にしたものです。つまり、小文字にして、スペースはハイフンに置き換えます。エージェントごとにファイルを1つ割り当てるため、並行して進むフェーズが同じファイルを共有することはありません。

フェーズ／エージェント	書き込み先
1 live-ops-designer	production/live-ops/[season-slug]/brief.md
2 narrative-director	production/live-ops/[season-slug]/narrative.md
3 economy-designer	production/live-ops/[season-slug]/economy.md
4 analytics-engineer	production/live-ops/[season-slug]/analytics.md
5 narrative-director	production/live-ops/[season-slug]/narrative-text.md
5 writer	production/live-ops/[season-slug]/copy.md
6 community-manager	production/live-ops/[season-slug]/comms.md

これらは作業用の草案です。最終文書は、これらをまとめて design/live-ops/seasons/ の下に作成します（出力文書）。

この方法が Collaboration Protocol に違反しない理由。 CLAUDE.md では、Write/Edit の前にエージェントが「このファイルパスに書き込んでもよいですか？」と尋ねることが求められています。ここで起動するサブエージェントは尋ねずに書き込みます。これは見落としではなく、意図的に範囲を限定した例外です。consistency-check が active.md に追記する場合と同じです。この例外が適用されるのは、次の3つすべてを満たす場合に限ります。（1）パスはプロンプトであなたが指定したものであり、フェーズの承認時にユーザーが保存先を承認している。（2）既存のソースや設定の編集ではなく、production/、docs/、tests/ の下に作成する新しい成果物である。（3）その成果物を作成するフェーズからパイプラインを進める前に、AskUserQuestion による確認を行う。この3つの条件以外では、エージェントは尋ねる必要があります。**サブエージェントごとに確認を求める形で、このルールを「修正」しないでください。**フェーズごとにエージェント全員へ個別のプロンプトを送るとオーケストレーターが使いものにならなくなるため、この例外が設けられています。

パイプラインで許される範囲で、独立したエージェントは並行して起動してください（フェーズ3と4は同時に実行できます）。

パイプライン

フェーズ 1：シーズン／イベントの範囲設定

live-ops-designer に委任します：

• シーズンまたはイベントを定義します：種類（季節限定、期間限定イベント、チャレンジ）、期間、テーマの方向性
• コンテンツ一覧の概要をまとめます：新要素（モード、アイテム、チャレンジ、ストーリー展開）
• リテンションの仕掛けを定義します：このシーズン中にプレイヤーが毎日／毎週戻ってくる理由
• リソース予算を特定します：新規コンテンツの制作量と再利用する量
• 出力：範囲、コンテンツ一覧、リテンションの仕組みの概要をまとめたシーズン概要書

フェーズ 2：ナラティブテーマ

narrative-director に委任します：

• フェーズ 1 のシーズン概要書を読みます
• シーズンのナラティブテーマを設計します：このイベントはゲームの世界観とどのようにつながるか
• イベント中にプレイヤーが発見する、中心となるストーリーの仕掛けを定義します
• このシーズンで進展させられる既存のロアの筋書きを特定します
• 出力：ナラティブの枠組みをまとめたドキュメント（テーマ、ストーリーの仕掛け、ロアとのつながり）

フェーズ 3：エコノミー設計（フェーズ 4 と並行）

economy-designer に委任します：

• シーズン概要書と、design/live-ops/economy-rules.md にある既存のエコノミー規則を読みます
• 報酬トラックを設計します：無料ティアの進行、プレミアムティアの価値提案
• シーズン中のエコノミーを計画します：シーズン通貨、ストアのローテーション内容、価格設定
• ランダム要素がある場合は、天井システムと不運に対する救済措置の仕組みを定義します
• プレミアムトラックにペイ・トゥ・ウィンのアイテムがないことを確認します
• 出力：報酬テーブル、価格設定、通貨の流れをまとめたエコノミー設計ドキュメント

フェーズ 4：分析と成功指標（フェーズ 3 と並行）

analytics-engineer に委任します：

• シーズン概要書を読みます
• 成功指標を定義します：参加率の目標、リテンション向上の目標、バトルパス完了率
• シーズン中に実施する A/B テスト（例：異なる報酬頻度）を設計します
• このシーズンのコンテンツに必要な新しいテレメトリーイベントを指定します
• 出力：成功基準と計測要件をまとめた分析計画

フェーズ 5：コンテンツ執筆（並行）

フェーズ 3 とフェーズ 4 の結果が両方そろってから開始します。以下を並行して委任します：

• narrative-director（必要な場合）：シーズン用のゲーム内ナラティブテキスト（カットシーンの台本、NPC のセリフ、ワールドイベントの説明）を執筆します
• writer：プレイヤー向けのすべてのテキスト（イベント名、報酬アイテムの説明、チャレンジの目標文、シーズンのフレーバーテキスト）を執筆します
• 両者ともフェーズ 2 のナラティブの枠組みをまとめたドキュメントを読みます

フェーズ 6：プレイヤー向けコミュニケーション計画

community-manager に委任します：

• シーズン概要書、エコノミー設計、ナラティブの枠組みを読みます
• シーズン開始のお知らせを作成します（トーン、主な見どころ、プラットフォーム別のバージョン）
• コミュニケーションのスケジュールを計画します：事前告知、開始日の投稿、シーズン中盤のリマインダー、最終週の FOMO を促す告知
• 初日のパッチノート向けに、既知の問題のセクションのプレースホルダーを作成します
• 出力：各コミュニケーションのタイミングに合わせた草案を含むコミュニケーションカレンダー

Phase 7: レビューと承認

すべてのフェーズの成果物を集め、シーズン計画をまとめて提示します：

• シーズン概要（Phase 1）
• ナラティブの枠組み（Phase 2）
• 経済設計と報酬テーブル（Phase 3）
• 分析計画と成功指標（Phase 4）
• 作成コンテンツの一覧（Phase 5）
• コミュニケーションカレンダー（Phase 6）

次の項目を含む概要をユーザーに提示します：

• コンテンツの範囲：作成するもの
• 経済面の健全性チェック：報酬トラックは公平で、搾取的ではないと感じられるか
• 分析の準備状況：成功基準は定義され、計測できるようになっているか
• 倫理レビュー：Phase 3 の経済設計を design/live-ops/ethics-policy.md と照合して確認します
  • ファイルが存在しない場合は、「ETHICS REVIEW SKIPPED: design/live-ops/ethics-policy.md not found. Economy design was not reviewed against an ethics policy. Recommend creating one before production begins.」というフラグを表示します。このフラグをシーズン設計の出力ドキュメントに含めます。次のステップに design/live-ops/ethics-policy.md の作成を追加します。
  • ファイルが存在し、違反が見つかった場合は、「ETHICS FLAG: [element] in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved.」というフラグを表示します。解決されるまで COMPLETE の判定を出したり、出力ドキュメントを書き込んだりしないでください。選択肢「経済設計を修正する／根拠を文書化したうえで例外を認める／キャンセル」を指定して AskUserQuestion を使用します。ユーザーが修正を選んだ場合は、economy-designer を再起動して修正版の設計を作成し、その後 Phase 7 のレビューに戻ります。ユーザーがキャンセルを選んだ場合は、Verdict: BLOCKED — "Live ops design cancelled due to unresolved ethics violation. Resolve the flagged issues and re-run /team-live-ops." で終了します。
• 未解決の質問：本番開始前に必要な判断

本番チームに作業を委任する前に、ユーザーにシーズン計画の承認を求めます。ユーザーの承認を得て、未解決の倫理違反がない場合に限り、COMPLETE の判定を出します。倫理違反が未解決の場合は、Verdict: BLOCKED で終了します。

出力ドキュメント

すべてのドキュメントは design/live-ops/ に保存します。ただし、オーケストレーターは書き込み前に確認を求めます。 design/ は、制限付き書き込み例外の対象となる3つのディレクトリ（production/、docs/、tests/）に含まれません。そのため、これらのパスを渡されたサブエージェントは書き込み前に確認を求める必要があります。例外の範囲を広げて、確認を回避してはいけません。 team-level のパターンに従います。サブエージェントは作業用成果物を production/ の下に書き込みます。ここは例外の対象です。最終ドキュメントをまとめるのはあなたです。 AskUserQuestion で「シーズン計画を design/live-ops/… に書き込んでもよいですか？」と確認し、承認された場合にのみ書き込みます。

パス：

• seasons/S[N]_[name].md — シーズン設計ドキュメント（Phase 1-3）
• seasons/S[N]_[name]_analytics.md — 分析計画（Phase 4）
• seasons/S[N]_[name]_comms.md — コミュニケーションカレンダー（Phase 6）

エラー復旧プロトコル

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

起動したエージェントが BLOCKED を返した場合、エラーになった場合、または完了できない場合は、直ちにユーザーに伝え、そのエージェントが妨げている依存関係の先には進まず、必ず部分レポートを作成してください。 スキップされたエージェントのセクションは、名前を付けた未対応項目のまま残します。内容を自分で補ってはいけません。手順全文は .claude/docs/error-recovery-protocol.md を参照してください。

BLOCKED 状態を解決できない場合は、COMPLETE ではなく Verdict: BLOCKED で終了します。

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

サブエージェントは、上記の「これがコラボレーションプロトコルに違反しない理由」で説明した範囲限定の例外に従い、作業成果物をproduction/の下に書き込みます。パスは指定されたもので、成果物はproduction/、docs/またはtests/の下に新規作成され、フェーズはAskUserQuestionによってゲートされています。この範囲内であれば、サブエージェントは書き込みのたびに確認を求めません。範囲外の場合は確認を求める必要があります。design/live-ops/の最終ドキュメント（シーズン設計、分析計画、コミュニケーションカレンダー）は例外です。オーケストレーターが「書き込んでもよろしいですか？」という確認を自身で行った後（上記の出力ドキュメントを参照）、それらを取りまとめて書き込みます。

出力

シーズンのテーマと範囲、経済設計の主なポイント、成功指標、コンテンツ一覧、コミュニケーション計画、および制作前にユーザーの判断が必要な未決事項をまとめます。

判定：完了 — シーズン計画を作成し、制作に引き継ぎました。

次のステップ

• 整合性を検証するため、シーズン設計ドキュメントに対して/design-reviewを実行します。
• シーズンのコンテンツ制作作業をスケジュールするため、/sprint-planを実行します（workflow: minimalではスプリントがないため、ブリーフのビルド順に追加してください）。
• シーズンのコンテンツをデプロイする準備ができたら、/team-releaseを実行します。
• 実行が倫理に関するフラグによってブロックされた場合：design/live-ops/ethics-policy.mdに照らして経済設計を見直し、/team-live-opsを再実行します。上記の3つのステップは、計画が完了するまで保留してください。