team-level

チームレベル

引数が指定されていない場合は、使用方法を案内して終了します。エージェントの起動やデザインファイルの読み込みは行いません。

使用方法：/team-level [level name or area to design] [--review full|lean|solo] — デザインするレベルまたはエリアを指定します（例：forest temple、tutorial village、final boss arena）。ここでは AskUserQuestion を使わないでください。案内を直接出力します。

このスキルが呼び出された場合：

意思決定ポイント： 各ステップの移行時に 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

上記で解決済みの設定をそのまま使用します。--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（デフォルト）：level-designer のみ。他のエージェントには level-designer を通じて相談し、個別には起動しません。
• small：systems-designer、art-director、qa-tester を追加します。
• studio：narrative-director、world-builder、accessibility-specialist を追加します（ドキュメントに記載された完全なパイプラインです）。 individual でコア以外のエージェントが必要になった場合は、情報メモを添えて、最も近いアクティブなコアエージェントを通じて相談します。「フェーズゲート」とは、automation モードにかかわらず、このパイプライン自体が列挙する AskUserQuestion の意思決定ポイントで終了するフェーズを指します。つまり、上記の「意思決定ポイント」で説明された移行、または以下のパイプラインに記載された Gate ステップです。guided と autonomous はゲートの通過方法（自動で進むか、log_decision で記録するか）を変えるだけで、ゲートであるかどうかは変わりません。そのため、以下の有界例外条件 (3) は、どのモードでも該当します。「フェーズゲートのみ」に制限されたエージェントは、該当するポイントでのみ起動し、それ以外では起動しません。このアクティブセットの適用範囲は、以下のパイプライン全体です。アクティブセットに含まれないエージェントを記載したフェーズでは、そのエージェントを起動する代わりに、最も近いコアエージェントを通じて相談します。

ステップ 1 の前にアクティブセットを告知してください。省略して黙って進めてはいけません。 何かを起動する前に、この実行で実際に起動するエージェントと、以下のパイプラインに記載されているものの、解決された team.size では起動しないエージェントを1行で明示します。例：

アクティブセット（team.size: <解決された値>）：上記の該当サイズに記載されたエージェント。 今回起動しないエージェント：このパイプラインに記載されたその他すべて — 最も近いアクティブなコアエージェントを通じて相談します。team.size（または modes.rigor）を上げると、対象を広げられます。

直前の team.size リストと、このファイルのパイプラインに記載されたエージェントをもとに記入してください。例の内容から判断してはいけません。オーケストレーターごとに、両方のセットは異なります。 以下のパイプラインは、複数のエージェントに処理を振り分けるように見えますが、出荷時のデフォルトではエージェントは1人か2人です。team-release は10人を指定していますが実際に動作するのは1人で、team-narrative は5つのフェーズにわたって6人を指定していますが、実際に動作するのは writer だけです。この縮退は正しい動作です。team.size は厳密性を優先し、狭いデフォルト設定はトークンを節約するための手段です。このことを明示しないと、読者は正しく縮退した実行と、壊れたパイプラインを区別できません。また、上記のエージェントごとの「情報提供の注記を添えて、最も近いコアエージェントにルーティングする」というルールは、ルーティング時に適用されるだけで、実行全体の構成については何も示しません。

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

1. 引数を読み取ります。対象となるレベルまたはエリア（例：tutorial、 forest dungeon、hub town、final boss arena）を確認します。

2. コンテキストを収集します（各デザインドキュメントをセクションごとに読みます。必要な見出しを見つけるには、Grep ツールをコンテンツモードで使用し、パターン ^# を指定します。その後、オフセットと上限を指定して、該当する範囲を読み取ります）。

   • ゲームコンセプトを design/gdd/game-concept.md から読み取ります。存在する場合は、rigor: minimal でその代わりとなる1ページのブリーフ design/game-brief.md を読み取ります。
   • ゲームの柱を design/gdd/game-pillars.md から読み取ります。
   • 既存のレベルドキュメントを design/levels/ から読み取ります。
   • 関連するナラティブドキュメントを design/narrative/ から読み取ります。
   • 対象エリアの地域または派閥に関する世界構築ドキュメントを読み取ります。

委任方法

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

• subagent_type: narrative-director — 物語の目的、登場人物、感情の展開
• subagent_type: world-builder — 伝承の背景、環境を通じたストーリーテリング、世界のルール
• subagent_type: level-designer — 空間レイアウト、ペース配分、遭遇、ナビゲーション
• subagent_type: systems-designer — 敵の構成、戦利品テーブル、難易度バランス
• subagent_type: art-director — ビジュアルテーマ、カラーパレット、ライティング、アセット要件
• subagent_type: accessibility-specialist — ナビゲーションの明確さ、色覚多様性への配慮、認知負荷
• subagent_type: qa-tester — テストケース、境界値テスト、プレイテスト用チェックリスト

各エージェントには要点を伝えてください。コンテキストを丸ごと渡してはいけません。 共有入力を一度だけ読み、要点をまとめたブリーフをインラインで渡します。各エージェントが実際に必要とする行だけを渡し、すでに読んだドキュメントのファイルパスは決して渡さないでください（パスを渡されたエージェントはファイル全体を再読します）。パスを渡すのは、まだ読んでいないドキュメントで、そのエージェントだけが必要とする場合に限ります。

すべてのエージェントへのプロンプトの末尾に、成果物の返却契約を付けてください：「出力全体を [path] に書き込んでください。その名前付きパスは、以下の限定的な例外のもとで許可されている書き込み先です。別途承認を求めずに書き込んでください。返すのは、（1）書き込んだパス、（2）決定事項の要約（最大5項目の箇条書き）、（3）BLOCKED/CONCERNS 項目（ある場合。各項目1行）のみです。読んだドキュメントの内容を繰り返さないでください。」これがないと、エージェントは読んだ内容をすべてこのセッションに返してしまいます。

[path] は実際のパスに置き換えてください。作業用成果物は、以下の「保存先」ステップに示す形式でスラッグ化した production/levels/[level-name]/ に格納します。各エージェントのファイルは別々にし、並行するステップ間で共有しないようにしてください：

ステップ／エージェント	書き込み先
1 narrative-director	production/levels/[level-name]/narrative.md
1 world-builder	production/levels/[level-name]/lore.md
1 art-director	production/levels/[level-name]/visual-direction.md
2 level-designer	production/levels/[level-name]/layout.md
3 systems-designer	production/levels/[level-name]/systems.md
4 art-director	production/levels/[level-name]/production-concepts.md
4 accessibility-specialist	production/levels/[level-name]/accessibility.md
5 qa-tester	production/qa/test-cases/[level-name]-cases.md — テストケース、エッジケース、プレイテスト用チェックリスト、受け入れ基準

これらは作業用のドラフトです。永続的な記録となるのは、これらをもとに編纂するレベルデザインドキュメント（design/levels/[level-name].md）です。

この方法がコラボレーションプロトコルに違反しない理由。 CLAUDE.md では、Write/Edit の前にエージェントが「[filepath] に書き込んでもよいですか？」と尋ねることが求められています。ここで起動したサブエージェントは確認を求めずに書き込みます。これは見落としではなく、意図的かつ限定的な例外です。consistency-check が active.md に追記するためにすでに認められている例外と同じです。この例外が適用されるのは、次の3つすべてを満たす場合に限ります：（1）パスがプロンプト内であなたが指定したものであり、ユーザーがフェーズを承認した時点で保存先も承認していること、（2）既存のソースや設定を編集するのではなく、production/、docs/、tests/ のいずれかに新しい成果物を作成すること、（3）その成果物を作成するフェーズ自体が、パイプラインを進める前に AskUserQuestion による確認を必要とすること。この3つに該当しない場合、エージェントは確認を求めなければなりません。サブエージェントごとに確認を求めて、この仕組みを「修正」しないでください。 フェーズごとにエージェント一人ひとりへ個別のプロンプトを送る方式ではオーケストレーターが使いものにならなくなるため、この例外が設けられています。

3. レベルデザインチームを順番にオーケストレーションします：

ステップ 1：物語とビジュアルの方向性（narrative-director + world-builder + art-director、並行）

3 つのエージェントを同時に起動します。結果を待つ前に、3 つの Agent 呼び出しをすべて実行してください。

narrative-director エージェントを起動して、次の内容を依頼します。

• このエリアの物語上の目的を定義する（ここではどのようなストーリー展開が起こるか）
• 重要なキャラクター、会話の発生条件、伝承に関する要素を特定する
• 感情の流れを指定する（プレイヤーが入るとき、滞在中、出るときにどう感じるべきか）

world-builder エージェントを起動して、次の内容を依頼します。

• このエリアの伝承に関する背景情報を提示する（歴史、勢力の存在、生態系）
• 環境を通じたストーリーテリングの機会を定義する
• このエリアのゲームプレイに影響する世界のルールを指定する

art-director エージェントを起動して、次の内容を依頼します。

• このエリアのビジュアルテーマの目標を設定する。これらはレイアウトの入力であり、出力ではありません
• このエリアの色温度と照明の雰囲気を定義する（隣接エリアとどう異なるか）
• 形状表現の方向性を指定する（角張った要塞？有機的な洞窟？朽ちた壮麗さ？）
• プレイヤーの位置把握に役立つ主要な視覚的ランドマークを挙げる
• design/art/art-bible.md が存在する場合は読み、確立されたアートバイブルにすべての方向性を沿わせる。セクションごとに読みます。Grep ツール（パターン ^#、コンテンツモード）で必要な見出しを見つけ、offset と limit を指定して該当範囲を Read してください。

アートディレクターがステップ 1 で示したビジュアル目標は、ステップ 2 でレベルデザイナーに明示的な制約として渡す必要があります。 レイアウトの決定はビジュアルの方向性に沿って行い、その前に決めてはなりません。

確認ポイント：AskUserQuestion を使用して、ステップ 1 の 3 つの成果物（物語の概要、伝承の基盤、ビジュアルの方向性の目標）をすべて提示し、ステップ 2 に進む前に確認を取ります。

ステップ 2：レイアウトと遭遇設計（level-designer）

ステップ 1 の出力全体をコンテキストとして、level-designer エージェントを起動します。

• 物語の概要（narrative-director から）
• 伝承の基盤（world-builder から）
• ビジュアルの方向性の目標（art-director から） — レイアウトはこれらの目標に沿って設計し、矛盾させてはなりません

level-designer には次の内容を依頼します。

• 空間レイアウトを設計する（主要ルート、任意ルート、秘密の場所）。主要ルートがステップ 1 の視覚的ランドマークの目標に沿うようにする
• ペース配分を定義する（緊張が高まる場面、休息エリア、探索ゾーン）。narrative-director の感情の流れと連携させる
• 難易度が段階的に上がるように遭遇を配置する
• 環境パズルやナビゲーション上の課題を設計する
• 進路案内のための注目地点とランドマークを定義する。これらは art-director が指定した視覚的ランドマークと一致させる
• 出入口と隣接エリアへの接続を指定する

隣接エリアの依存関係を確認する：レイアウトの作成後、level-designer が参照した各隣接エリアについて design/levels/ を確認します。参照先の .md ファイルが存在しない場合は、その不足を提示します。

"Level references [area-name] as an adjacent area but design/levels/[area-name].md does not exist."

次の選択肢を指定して AskUserQuestion を使用します。

• (a) プレースホルダー参照のまま進める — レベルドキュメント内で接続を UNRESOLVED と記し、概要レポートの未解決のレベル間依存関係セクションに記載する
• (b) いったん停止して、まず /team-level [area-name] を実行し、そのエリアを確立する

欠落している隣接エリアの内容を創作してはなりません。

確認ポイント：AskUserQuestion を使用して、ステップ 2 のレイアウト（未解決の隣接エリア依存関係がある場合はそれも含む）を提示し、ステップ 3 に進む前に確認を取ります。

ステップ 3：システム統合（systems-designer）

systems-designer エージェントを起動して、次の内容を依頼します。

• 敵の構成と遭遇の計算式を指定する
• 戦利品テーブルと報酬の配置を定義する
• 想定されるプレイヤーレベルや装備を基準に難易度のバランスを調整する
• エリア固有のメカニクスや環境ハザードを設計する
• リソースの配置を指定する（回復アイテム、セーブポイント、ショップ）

確認ポイント：AskUserQuestion を使用してステップ 3 の成果物を提示し、ステップ 4 に進む前に確認を取ります。

ステップ 4：本番向けコンセプトとアクセシビリティ（art-director + accessibility-specialist、並行）

注：art-director による方向性の検討（ビジュアルテーマ、色の目標、雰囲気）はステップ 1 で行っています。この検討は、場所ごとの本番向けコンセプトです。最終確定したレイアウトを踏まえ、個々の空間がどのような見た目になるかを検討します。

ステップ 2 で最終確定したレイアウトを渡して、art-director エージェントを起動します。

• 主要な空間（入口、重要な遭遇エリア、ランドマーク、出口）について、場所に特化したコンセプト仕様を作成する
• このエリア独自のアートアセットと、全体で共有するアセットプールから使用するものを指定する
• 主要な空間ごとに、視線誘導とライティングの設定を定義する（これらは方向性ではなく、レイアウトを踏まえたものです）
• このエリアのレイアウトに特化した VFX のニーズ（天候ボリューム、パーティクル、雰囲気効果）を指定する
• レイアウトによってビジュアルの方向性とステップ 1 の目標に食い違いが生じる場所を特定し、本番上のリスクとして提示する

並行して accessibility-specialist エージェントを起動し、以下を行います。

• レベルレイアウトを確認し、ナビゲーションが明確か評価する（プレイヤーは色だけに頼らずに現在地を把握できますか？）
• 重要な経路を示す手がかりに、色に加えて形状、アイコン、音が使われているか確認する
• パズルの仕組みに必要な認知負荷を確認する。3 つを超える状態を同時に保持する必要があるものがあれば指摘する
• 主要なゲームプレイエリアに、色覚障害のあるプレイヤーにとって十分なコントラストがあるか確認する
• 出力：重大度（BLOCKING / RECOMMENDED / NICE TO HAVE）を付記したアクセシビリティ上の懸念事項リスト

両エージェントからの結果が揃うまで待ちます。

ゲート：AskUserQuestion を使って、ステップ 4 の両方の結果を提示します。accessibility-specialist から BLOCKING の懸念事項が返された場合は、それを目立つように強調し、次の選択肢を提示します。

• (a) ステップ 5 の前に、指摘された要素を再設計するため level-designer と art-director に戻す
• (b) 既知のアクセシビリティ上の問題として記録し、最終レポートに懸念事項を明記したうえでステップ 5 に進む

ユーザーが BLOCKING のアクセシビリティ上の懸念事項を確認するまで、ステップ 5 に進んではいけません。

ステップ 5：QA 計画（qa-tester）

qa-tester エージェントを起動し、以下を行います。

• 重要な経路のテストケースを作成する
• 境界条件とエッジケース（順序の破綻、ソフトロック）を特定する
• エリアのプレイテストチェックリストを作成する
• レベル完了の受け入れ基準を定義する

4. すべてのチームの出力を統合し、レベルデザインテンプレート形式でレベルデザイン文書をまとめます。

オーケストレーターは、すべてのサブエージェントの出力をすでに保持しています。文書はオーケストレーター自身でまとめてください。level-designer を再起動し、すべての出力をそのまま再送信してはいけません。 2 回目の起動では、新しいエージェントのオーバーヘッドが発生し、オーケストレーターがすでに保持しているコンテキストをすべて再送信することになります。すでに保持しているテキストを移すだけのために、こうした手順を踏む必要はありません。レベルデザインテンプレート形式で文書をまとめたら、ユーザーに直接 AskUserQuestion で次のように確認します。「まとめたレベルデザインを design/levels/[level-name].md に書き込んでもよろしいですか？」承認後に書き込みます。

5. 承認後、design/levels/[level-name].md に保存します。 [level-name] は引数をスラッグ形式にします。小文字にし、スペースはハイフンに置き換えます（forest dungeon → forest-dungeon.md）。隣接エリアの確認で使う [area-name] も同じ方法でスラッグ化します。

6. 以下を含む概要を出力します：エリアの概要、遭遇数、推定アセット一覧、ナラティブの展開、チーム間の依存関係や未解決の質問、未設計の隣接エリアへの参照を含むレベル間の未解決の依存関係（それぞれ UNRESOLVED と明記）、および解決状況を付記したアクセシビリティ上の懸念事項。

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

エージェントごとの成果物（説明資料、テストチェックリスト）は、上記の「これがコラボレーションプロトコルに違反しない理由」で説明されている限定的な例外の範囲内で、それを作成したサブエージェントが書き込みます。パスは指定済みで、成果物は production/、docs/、または tests/ 以下に新規作成され、フェーズは AskUserQuestion によってゲートされています。この範囲内でサブエージェントが書き込みごとに確認を求める必要はありませんが、範囲外では確認が必要です。唯一の例外は、最終的に統合するレベルデザイン文書です。オーケストレーターはすでにすべての入力を保持しているため、自身の「書き込んでもよいですか？」という確認（ステップ 4）の後、そのファイルを自らまとめて書き込みます。オーケストレーターがすでに保持している文章を書かせるためだけにエージェントを再起動するのは、まったくの余分な作業です。

判定：完了 — レベルデザイン文書を作成し、チームのすべての出力を統合しました。 判定：ブロック中 — 1 人以上のエージェントがブロックされた、またはエージェントがスキップされた（.claude/docs/error-recovery-protocol.md のステップ 5）ため、未解決項目を列挙した部分レポートを作成しました。

次のステップ

• /design-review design/levels/[level-name].md を実行して、完成したレベルデザイン文書を検証します。
• デザインの承認後、/dev-story を実行してレベルの内容を実装します。
• /qa-plan を実行して、このレベルの QA テスト計画を作成します。

エラー復旧プロトコル

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

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

よくあるブロッカー：

• 入力ファイルがない（ストーリーが見つからない、GDD がない）→ そのファイルを作成するスキルに案内します
• ADR のステータスが Proposed → 実装せず、決定後に /architecture-decision accept ADR-NNNN で承認します
• スコープが大きすぎる → /create-stories で 2 つのストーリーに分割します
• ADR とストーリーの指示が競合している → 競合を伝え、推測で判断しません