team-combat

チーム戦闘

引数の確認： 戦闘機能の説明が指定されていない場合は、次を出力します。

"Usage: /team-combat [combat feature description] [--review full|lean|solo] — 設計・実装する戦闘機能の説明を指定してください（例：melee parry system、ranged weapon spread）。" その後、サブエージェントを起動したり、ファイルを読み込んだりせず、ただちに終了します。

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

意思決定ポイント： 各フェーズの移行時に 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 を参照してください。

workflow は、/design-system と同じ方法でフェーズ 1 の設計ドキュメントの規模を設定します。 full では、## Summary と 8 つのセクションすべてを作成します。 standard では、Overview、Detailed Design、Edge Cases、Dependencies、Acceptance Criteria に加え、メカニクスで数値ルールを定義する場合は Formulas も作成します（戦闘メカニクスではほとんどの場合、数値ルールを定義します）。 minimal では、ゲーム概要を設計記録とし、GDD は任意とします。この 5 つのセクションの草案を作成し、このワークフローレベルでは任意であることをユーザーに伝えてください。 team.size：アクティブなエージェント（review_mode のゲート深度やワークフローのドキュメントとは別の設定です）。

• individual（デフォルト）：gameplay-programmer がパイプラインを実行します。機能に AI の作業が含まれる場合に限り、ai-programmer にエスカレーションします。他の Team Composition のエージェントは、個別に起動せず、gameplay-programmer を介して相談します。
• small：以下に記載されている Team Composition のパイプライン全体を実行します。
• studio：パイプライン全体に加え、エンジンのサブスペシャリストと敵対的レビューを実施します。エンジンのサブスペシャリスト：プライマリのエンジンスペシャリストのプロンプトには、tools: の付与内容に名前があるサブスペシャリストにレビューの一部を委任してもよいと記載されています（たとえば、アビリティなら ue-gas-specialist）。studio ではない場合、プライマリが単独で回答します。敵対的レビュー：フェーズ 5 では、qa-tester に「これが動作することを確認するのではなく、どうすれば壊れるかを見つけることが仕事です」と指示し、レポートにはレビューを実施したことを記載します。

individual で必要となる非コアエージェントには、情報メモを添えて最も近いアクティブなコアエージェント経由で対応します。「フェーズゲート」とは、このパイプライン自体が列挙する AskUserQuestion の判断ポイントで終わるフェーズすべてを指します。つまり、上記の Decision Points にある移行、または以下のパイプラインに記載された Gate ステップです。automation モードは問いません。guided と autonomous の違いはゲートの通過方法（自動的に次へ進むか、log_decision で記録するか）であり、ゲートであるかどうかは変わりません。そのため、以下の限定例外の条件 (3) は、どのモードでもゲートで適用されます。「フェーズゲートのみ」に制限されたエージェントは、そのポイントでのみ起動され、それ以外では起動されません。このアクティブセットの制限は以下のパイプライン全体に適用されます。アクティブセット外のエージェントを指定するフェーズでは、そのエージェントを起動せず、最も近いコアエージェント経由で対応します。

フェーズ 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 は厳密さを優先する設定であり、狭いデフォルトはトークン使用量を抑えるための設定です。 これを伝えなければ、出力を読む人は、正しく縮小された実行なのか、パイプラインの不具合なのかを区別できません。また、前述のエージェントごとの「情報メモを添えて最も近いコアエージェント経由で対応する」というルールがルーティング時に適用されるだけで、実行全体の構成は明示されません。

これは、このファイルの別の箇所にあるチェック省略の報告ルールと同じです。適用されていても、そのことが示されない制約は、出力を読む人にとって、そもそも適用されなかった場合と区別できません。

Team Composition

• game-designer — メカニクスを設計し、計算式とエッジケースを定義します
• gameplay-programmer — 中核となるゲームプレイコードを実装します
• ai-programmer — この機能における NPC／敵の AI の挙動を実装します
• technical-artist — VFX、シェーダーエフェクト、視覚的なフィードバックを作成します
• sound-designer — オーディオイベント、インパクト音、戦闘時の環境音を定義します
• engine specialist（プライマリ）— アーキテクチャと実装パターンが、そのエンジンに適した慣例に沿っているか検証します（プライマリのスペシャリストは engine.name に基づく <engine>-specialist です。Godot→godot-specialist、Unity→unity-specialist、Unreal→unreal-specialist。該当しない場合は technical-preferences.md の ## Engine Specialists にある Primary の行を使用します）
• qa-tester — テストケースを作成し、実装を検証します

How to Delegate

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

• subagent_type: game-designer — メカニクスを設計し、数式とエッジケースを定義します
• subagent_type: gameplay-programmer — コアゲームプレイのコードを実装します
• subagent_type: ai-programmer — NPC／敵の AI の挙動を実装します
• subagent_type: technical-artist — VFX、シェーダーエフェクト、視覚的なフィードバックを作成します
• subagent_type: sound-designer — オーディオイベント、インパクト音、環境音を定義します
• subagent_type: [primary engine specialist] — アーキテクチャと実装がエンジンの慣習に沿っているか検証します
• subagent_type: qa-tester — テストケースを作成し、実装を検証します

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

すべてのエージェントプロンプトの末尾に、成果物の返却条件を付けてください。「[path] に出力全文を書き込んでください。この指定パスは、以下の限定例外に基づく書き込み許可なので、別途承認を求めずに書き込んでください。返答には（1）書き込んだパス、（2）決定事項の要約（最大5項目）、（3）BLOCKED／CONCERNS の項目があれば各1行のみを記載してください。読んだドキュメントの内容を言い直さないでください。」これを付けないと、エージェントが読んだ内容をすべてこのセッションに返してしまいます。実装ファイルは例外です。 コードやアセットを作成するエージェントは、まず作成または変更するファイルを返します。返却条件にそれらのパスを記載できるのは、ファイル書き込みプロトコルに従って、対象ファイルの一覧を一度確認し、ユーザーが承認した後に限ります。書き込みを許可するのはその回答であり、限定例外ではありません。

**[path] は実際のパスに置き換えてください。**成果物を作成する各フェーズで、パスを1つ指定してください。ほとんどのパスは、すでにそれらを読み取るスキルで固定されています。

フェーズ／エージェント	書き込み先	保存先の指定元
1 game-designer（ドラフト）	production/combat/[feature]-gdd-draft.md	このスキル — 最終版の design/gdd/[feature].md はあなたが作成します（フェーズ1）
2 gameplay-programmer	docs/architecture/[feature]-sketch.md	下記の注記を参照
2 engine specialist	docs/architecture/[feature]-engine-notes.md	下記の注記を参照
3 gameplay-programmer、ai-programmer、technical-artist	コードのルートと assets/ — フェーズ3の承認で指定したファイル	限定例外の対象外：ファイル書き込みプロトコルに従い、対象ファイルの一覧を一度確認します
3 sound-designer	production/combat/[feature]-audio-events.md	このスキル
5 qa-tester（テストケース）	production/qa/test-cases/[feature]-cases.md	/team-qa フェーズ4
5 qa-tester（バグ）	production/qa/bugs/BUG-[NNNN].md	/team-qa フェーズ5

フェーズ6は口頭での進捗報告であり、成果物ではありません。パスは不要です。

**上記の各フェーズには、意図的に具体的な保存先が指定されています。**以下のエラーリカバリープロトコルでは、「指定された成果物がディスク上に存在しない場合、そのフェーズは失敗」と定めています。パスが指定されていなければ、この確認は実行できません。

docs/architecture/ の2項目は慣例ではなく、判断によるものです。このディレクトリには ADR（adr-NNNN-*.md）が格納されています。スケッチは ADR の前段階であって ADR 自体ではなく、リポジトリ内でどちらのファイルも読み取るものはありません。報告時にはその点を明示し、スケッチは後続のゲートへの入力ではなく、記録として作成されたものだと分かるようにしてください。 これがコラボレーションプロトコルに違反しない理由。 CLAUDE.md では、エージェントは Write/Edit の前に「[filepath] にこれを書き込んでもよいですか？」と確認することが求められています。ここで起動されたサブエージェントは確認せずに書き込みます。これは見落としではなく、意図的に範囲を限定した例外です。consistency-check が active.md に追記することをすでに認めた判断と同じです。この例外が適用されるのは、次の3つすべてに該当する場合に限られます。(1) パスがプロンプトであなたが指定したものであり、フェーズの承認時にユーザーが保存先も承認している。(2) production/、docs/、または tests/ 以下の新しい成果物であり、既存のソースや設定を編集するものではない。(3) その成果物を作成するフェーズの後、パイプラインが進む前に AskUserQuestion による確認がある。この3つの条件を満たさない場合、エージェントは確認しなければなりません。サブエージェントごとに確認する形に「修正」しないでください。エージェントごと、フェーズごとにプロンプトを出すとオーケストレーターが使いものにならなくなるため、この例外が設けられています。

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

パイプライン

フェーズ1：設計

game-designer に委任します。

• .claude/docs/templates/game-design-document.md を基に、design/gdd/[feature].md の設計ドキュメントを作成または更新します。## Summary と、workflow で必要とされるセクション（フェーズ0）を含めます。full の場合は、メカニクスの概要、プレイヤーの願望、詳細なルール、変数の定義を含む計算式、エッジケース、依存関係、安全な範囲を示した調整可能な値、受け入れ基準を含めます。
• 出力：完成した設計ドキュメント。production/combat/[feature]-gdd-draft.md に草案を作成します。

design/ は上記の限定的な書き込み例外の対象外です。そのため、game-designer が草案を作成し、あなたが GDD を書き込みます。これは /team-level と /team-narrative が採用しているパターンです。フェーズ1の判断時点で草案を提示し、AskUserQuestion を通じて「設計ドキュメントを design/gdd/[feature].md に書き込んでもよいですか？」と尋ねます。承認された場合に書き込みます。その回答を得る前に design/ 以下へ書き込むことはありません。

フェーズ2：アーキテクチャ

gameplay-programmer に委任します（AI が関わる場合は ai-programmer も加えます）。

• 設計ドキュメントを確認します。
• コードアーキテクチャを設計します。クラス構造、インターフェース、データフローを含めます。
• 既存システムとの統合箇所を特定します。
• 出力：ファイル一覧とインターフェース定義を含むアーキテクチャの概要。

次に、提案されたアーキテクチャを検証するため、主要エンジンスペシャリストを起動します。

• クラス／ノード／コンポーネントの構造は、指定されたエンジンに適した慣用的なものですか？（例：Godot のノード階層、Unity の MonoBehaviour と DOTS の使い分け、Unreal の Actor／Component 設計）
• 独自実装ではなく、使用すべきエンジン標準のシステムはありますか？
• 提案された API に、指定されたエンジンのバージョンで非推奨になっているものや、変更されたものはありますか？
• 出力：エンジンアーキテクチャの注記。フェーズ3の開始前にアーキテクチャへ反映します。

エンジンが設定されていない場合は、スペシャリストの起動を省略します。この実行の出力に Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`) と記録してください。 省略した確認について何も記述しないと、確認に合格した場合と区別がつきません。

AskUserQuestion を使います。

• プロンプト：「アーキテクチャの概要が完成しました。承認すると並行実装に進みます。」
• 選択肢：
  • [A] Proceed — spawn implementation agents (gameplay-programmer, ai-programmer, technical-artist, sound-designer)
  • [B] Revise the architecture first — I'll describe what needs to change
  • [C] Stop here — I'll continue later

ユーザーが [A] を選んだ場合にのみ、実装エージェントを起動します。（guided／autonomous モードでは、このアーキテクチャの確認は通常のフェーズ移行です。アーキテクチャの概要が BLOCKED でなければ実装に進みます。autonomous モードでは、log_decision を使って判断を記録します。この確認はリリースに重大な影響を与えるものでも、取り消せない判断でもないため、標準的なパイプラインのルールに従います。）

フェーズ 3：実装（可能な限り並行して実施）

並行して委任します。

• gameplay-programmer：コア戦闘メカニクスのコードを実装
• ai-programmer：AI の挙動を実装（機能に NPC の反応が含まれる場合）
• technical-artist：VFX とシェーダーエフェクトを作成
• sound-designer：オーディオイベント一覧とミキシングに関する注記を定義し、production/combat/[feature]-audio-events.md に下書きを作成

コード、VFX、シェーダーの作業は範囲限定の書き込み例外の対象外です。それぞれのエージェントは、まず作成または変更するファイルを提示し、まとめて一度だけ許可を求め、承認後にのみ書き込みます（ファイル書き込みプロトコル）。

フェーズ 4：統合

• ゲームプレイコード、AI、VFX、オーディオを連携させます
• すべての調整パラメーターが公開され、データ駆動型になっていることを確認します
• この機能が既存の戦闘システムと連携して動作することを検証します

ゲート：AskUserQuestion を使って統合結果を提示し、フェーズ 5 に進む前に確認を得ます。

フェーズ 5：検証

qa-tester に委任します。

• 受け入れ基準に基づいてテストケースを作成
• デザインに記載されたすべてのエッジケースをテスト
• パフォーマンスへの影響が予算内であることを検証
• 発見した問題についてバグ報告を作成

フェーズ 6：承認

• チームメンバー全員から結果を収集
• 機能のステータスを報告：COMPLETE / NEEDS WORK / BLOCKED
• 未解決の問題と担当者を一覧表示

エラー復旧プロトコル

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

起動したエージェントが BLOCKED、エラー、または完了不能を返した場合は、ただちに明らかにし、そのエージェントが妨げている依存作業より先に進まず、必ず部分レポートを作成してください。 スキップされたエージェントのセクションは、明示された未対応項目のままにしてください。自分で内容を補ってはいけません。手順の全文は .claude/docs/error-recovery-protocol.md にあります。

一般的なブロッカー：

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

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

デザインの下書き、実装ファイル、テストケースを含むすべてのファイル書き込みは、Agent 経由で起動したサブエージェントに委任し、次の 2 つのルールに従います。

• 下書き、スケッチ、QA 成果物 — パステーブルに記載された production/、docs/、tests/ 以下の保存先 — は、「これがコラボレーションプロトコルに違反しない理由」の項で前述した範囲限定の例外に従います。パスは指定済みで、成果物は新規であり、フェーズは AskUserQuestion による確認を経て進みます。サブエージェントは書き込みごとの許可を求めずに書き込みます。
• 実装ファイル — フェーズ 3 のコード、VFX、シェーダーファイル、およびフェーズ 4 の統合作業で編集するファイル（コードルートと assets/ 以下） — は、エージェント自身のファイルに記載されているとおり、この例外の対象外です。各実装エージェントは、まず作成または変更するファイルを、それぞれ 1 行の要約とともに提示します。対象全体について一度だけ「[エージェント名] にこれらの [N] 個のファイルを書き込ませてもよいですか？」と許可を求め、承認後にのみ書き込ませます。既存ファイルの編集は、フェーズ 3 前のゲートで暗黙に許可されるものではなく、必ずその一覧に含めます。

唯一の例外はデザインドキュメントです。オーケストレーターは、ゲームデザイナーの下書きをもとに、フェーズ 1 で自ら「…を書いてもよいですか？」と確認を求めた後、design/gdd/[feature].md を自分で作成します。それ以外のファイルは作成しません。

出力

設計の完了状況、チームメンバーごとの実装状況、テスト結果、未解決の問題をまとめたレポートです。

判定：COMPLETE — 戦闘機能の設計、実装、検証が完了しました。

エンジン検証がスキップされた場合（フェーズ 2、エンジン未設定）、判定にはその旨を記載します。単に COMPLETE としてはいけません。

判定：COMPLETE — engine validation NOT ASSESSED ([reason]) — 戦闘機能の設計、実装、検証が完了しました。エンジン担当スペシャリストによるアーキテクチャのレビューは行われていません。

判定：NEEDS WORK — すべてのフェーズが実施されましたが、フェーズ 5 の検証で失敗や未解決のバグが残りました。レポートには、それぞれの担当者とともにすべて記載します。

判定：BLOCKED — 1 つ以上のフェーズを完了できなかったか、エージェントがスキップされました（.claude/docs/error-recovery-protocol.md の手順 5）。未解決項目を記載した部分レポートを作成します。

次のステップ

• ストーリーを完了する前に、実装した戦闘コードに /code-review を実行します。
• 戦闘の計算式と調整値を検証するため、/balance-check を実行します。
• VFX、オーディオ、パフォーマンスの仕上げが必要な場合は、/team-polish を実行します。