team-audio

Team Audio

引数が指定されていない場合は、使用方法を案内して、エージェントを起動せずに終了します。

使用方法：/team-audio [オーディオを設計する機能または領域] [--review full|lean|solo] — オーディオを設計する機能または領域を指定します（例：combat、main menu、forest biome、boss encounter）。ここでは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（デフォルト）：sound-designerのみ。他のエージェントにはsound-designerを介して相談します。個別には起動しません。
• small：audio-director、technical-artist、gameplay-programmerを追加します。
• studio：accessibility-specialistと主要なエンジンスペシャリストを追加します（ドキュメントに記載されたパイプライン全体）。 individualで必要となるコア以外のエージェントは、情報メモを添えて最も近い有効なコアエージェントを経由します。「フェーズゲート」とは、このパイプライン自体が列挙するAskUserQuestionによる意思決定ポイントで終わるフェーズを指します。つまり、上記の「意思決定ポイント」に記載された移行、または以下のパイプラインに記載されたゲートステップです。automationモードに関係なく該当します。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. 対象の機能または領域（例：combat、main menu、forest biome、boss encounter）の引数を読みます。

2. コンテキストを収集します。

   • 機能に関連する設計ドキュメントを、セクションごとに design/gdd/ から読みます。Grep ツール（パターン ^#、コンテンツモード）で必要な見出しを探し、offset と limit を指定して該当範囲を読みます。
   • design/audio/sound-bible.md が存在する場合は、それを読みます。以前のバージョンで配置されていた design/gdd/sound-bible.md だけが存在する場合は、それを読み、design/audio/ への移動を推奨します。design/gdd/ では、GDD のチェックで全ファイルがシステム GDD としてカウントされます。どちらも存在しない場合は、出力で不足が見えるように、1行で「design/audio/sound-bible.md にサウンドバイブルがありません。オーディオの方向性は GDD のみを基に決定します」と伝えます。不足については後続の手順でも伝え、オーディオディレクターへの Step 1 のブリーフに記載し、Next Steps でサウンドバイブルの作成を推奨します。
   • assets/audio/ にある既存のオーディオアセット一覧を読みます。
   • この領域に関する既存のサウンドデザインドキュメントを読みます。

委任方法

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

• subagent_type: audio-director — 音のアイデンティティ、感情的なトーン、オーディオパレット
• subagent_type: sound-designer — 効果音の仕様、オーディオイベント、ミキシンググループ
• subagent_type: accessibility-specialist — 重要な音声に対する視覚的な代替表現と字幕、聴覚過敏への配慮
• subagent_type: technical-artist — オーディオミドルウェア、バス構造、メモリ予算
• subagent_type: [primary engine specialist] — エンジンのオーディオ統合パターンを検証
• subagent_type: gameplay-programmer — オーディオマネージャー、ゲームプレイのトリガー、アダプティブミュージック

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

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

[path] は実際のパスに置き換えてください。作業成果物は production/audio/[feature]/ の下に保存します。[feature] は引数をスラッグ化したものです。小文字にし、スペースはハイフンに置き換えます（boss encounter → boss-encounter）。「保存先」の手順で使用するスラッグと同じものです。並行する手順でファイルが重複しないよう、エージェントごとにファイルを1つ作成します。

手順／エージェント	書き込み先
1 audio-director	production/audio/[feature]/direction.md
2 sound-designer	production/audio/[feature]/sfx-spec.md
2 accessibility-specialist	production/audio/[feature]/accessibility.md
3 technical-artist	production/audio/[feature]/integration-plan.md
3 engine specialist	production/audio/[feature]/engine-notes.md
4 gameplay-programmer	コードルートとエンジンのテストルート — 1回の実装依頼で指定されたファイル（ファイル書き込みプロトコル）。限定例外の対象外です。

これらは作業用ドラフトです。恒久的な記録となるのは、これらをもとにまとめるオーディオ設計ドキュメントです。

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

3. オーディオチームを順番にオーケストレーションします。

ステップ 1：オーディオの方向性（audio-director）

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

• この機能／領域の音響的な個性を定義する
• 感情的なトーンとオーディオのパレットを指定する
• 音楽の方向性（適応型レイヤー、ステム、トランジション）を設定する
• オーディオの優先順位とミックスの目標値を定める
• 適応型オーディオのルール（戦闘の激しさ、探索、緊張感など）を定義する

ステップ 2：サウンドデザインとオーディオアクセシビリティ（並行して実行）

サウンドデザイナー エージェントを起動し、以下を行います。

• すべてのオーディオイベントについて、詳細な SFX 仕様を作成する
• サウンドカテゴリ（環境音、UI、ゲームプレイ、音楽、ダイアログ）を定義する
• 各サウンドのパラメーター（音量範囲、ピッチの変化、減衰）を指定する
• トリガー条件を含むオーディオイベントリストを作成する
• ミキシンググループとダッキングのルールを定義する

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

• どのオーディオイベントが重要なゲームプレイ情報（ダメージを受けた、敵が近くにいる、目標を達成したなど）を伝え、聴覚に障害のあるプレイヤー向けの視覚的な代替手段が必要かを特定する
• 字幕の要件を指定する。どのオーディオイベントに字幕が必要か、テキストの形式、画面上での表示時間を定める
• ゲームプレイの状態が音声だけで伝わることがないよう確認する（すべて視覚的な代替手段が必要）
• 聴覚過敏のプレイヤーに問題を引き起こす可能性のあるオーディオイベント（高周波の警告音、突然の大音量など）がないか、オーディオイベントリストを確認する
• 出力：オーディオイベントの仕様に統合した、オーディオアクセシビリティ要件のリスト

視覚的な合図や字幕がないゲームプレイ上重要なオーディオイベントには、レポートで BLOCKING のラベルを付けます。ユーザーが解決するか、ステップ 2 の判断時点で明示的に受け入れるまで、ステップ 3 は開始しません。この判断時点では、修正案（視覚的な合図、字幕、または触覚による代替手段）と停止の選択肢が提示されます。受け入れられた不足事項は、サマリーの未解決の質問に記載します。

ステップ 3：技術的な実装（並行して実行）

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

• オーディオミドルウェアの統合（Wwise/FMOD/native）を設計する
• オーディオバスの構成とルーティングを定義する
• プラットフォームごとのオーディオアセットのメモリ予算を指定する
• ストリーミングと事前読み込みを使い分けるアセット戦略を立てる
• オーディオに反応する視覚効果を設計する

technical-artist と並行して主要エンジンスペシャリスト（engine.name から導出した <engine>-specialist — Godot→godot-specialist、Unity→unity-specialist、Unreal→unreal-specialist。該当しない場合は .claude/docs/technical-preferences.md の ## Engine Specialists にある Primary 行に従います）を起動し、統合方針を検証します。

• 提案されたオーディオミドルウェアの統合は、そのエンジンに適した慣用的な方法ですか？（例：Godot の組み込み AudioStreamPlayer と FMOD、Unity の Audio Mixer と Wwise、Unreal の MetaSounds と FMOD）
• 使用すべき、エンジン固有のオーディオノード／コンポーネントのパターンはありますか？
• 固定されたエンジンバージョンにおける既知のオーディオシステムの変更で、統合計画に影響するものはありますか？
• 出力：technical-artist の計画に統合する、エンジンのオーディオ統合に関するメモ

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

ステップ 4：コード統合（gameplay-programmer）

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

• オーディオマネージャーシステムを実装するか、既存のものをレビューする
• オーディオイベントをゲームプレイのトリガーに接続する
• アダプティブミュージックシステムを実装する（指定されている場合）
• オーディオのオクルージョン／リバーブゾーンを設定する
• オーディオイベントのトリガーに関する単体テストを作成する

4. チームのすべての成果物をまとめて、オーディオ設計ドキュメントを作成します。

5. 保存先： design/audio/audio-[feature].md — ただし、最初に確認してください。 design/ は、書き込み範囲の例外が対象とする3つのディレクトリ（production/、docs/、tests/）に含まれていないため、このパスを渡されたサブエージェントは確認を求める必要があります。例外の範囲を広げて解決しようとしてはいけません。代わりに、team-level と同じ方法に従います。**すでにすべてのサブエージェントの成果物を受け取っているのはあなた自身なので、**ドキュメントを自分でまとめ、AskUserQuestion を使って「オーディオ設計を design/audio/audio-[feature].md に書き込んでもよいですか？」と直接確認し、承認を得てから書き込みます。サブエージェントの作業成果物は、例外の対象となる production/ に置きます。

   注：design/audio/ が存在しない場合、ファイルの書き込み時に作成されます。

6. 以下を含む概要を出力します。 オーディオイベント数、推定アセット数、実装タスク、チームメンバー間の未解決の質問。

判定：COMPLETE — オーディオ設計ドキュメントが作成され、チームのパイプラインが完了しました。

エンジンが設定されておらず、エンジンの検証を省略した場合は、判定にその旨を記載します。単に COMPLETE としてはいけません。

判定：COMPLETE — エンジン検証は未評価（[reason]） — オーディオ設計ドキュメントは作成されましたが、エンジンの専門家は統合計画をレビューしていません。

依存関係が未解決のためにパイプラインが停止した場合（重大なアクセシビリティ上の問題、またはユーザーによって解決されなかった GDD の不足など）：

判定：BLOCKED — [reason]

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

エージェントごとの成果物（SFX 仕様、統合計画）は、上記「これが Collaboration Protocol に違反しない理由」で説明した範囲限定の例外に従い、それを作成したサブエージェントが書き込みます。つまり、パスはあなたが指定したものであり、成果物は production/、docs/、tests/ のいずれかに新規作成され、フェーズは AskUserQuestion によって承認されています。この範囲内では、サブエージェントは書き込みごとに確認を求めません。範囲外の場合は確認が必要です。実装ファイル、つまり gameplay-programmer が作成するオーディオ統合コードや、コードルートまたは assets/ 配下のあらゆるファイルは、この範囲に含まれません。エージェントは作成または変更するファイルを提示し、あなたがその一式について一度確認し、承認後にエージェントが書き込みます。唯一の例外は、最終的にまとめたオーディオ設計ドキュメントです。 オーケストレーターはすでにすべての入力を受け取っているため、前述の「保存先」ステップで「書き込んでもよいですか？」と自ら確認した後、design/audio/audio-[feature].md を自分でまとめて書き込みます。

次のステップ

• 実装を始める前に、audio-director とオーディオ設計ドキュメントをレビューします。
• 設計が承認されたら、/dev-story を使用してオーディオマネージャーとイベントシステムを実装します。
• オーディオアセットの作成後に /asset-audit を実行し、命名規則とフォーマットへの準拠を確認します。
• サウンドバイブルがない場合は、次のオーディオ作業に進む前に作成します。audio-director エージェントに .claude/docs/templates/sound-bible.md を基に design/audio/sound-bible.md の草案を作成するよう依頼します。この実行のステップ 1 で定めた方向性を起点とし、design/ への書き込み前に確認を求めます。

エラー復旧プロトコル

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

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

よくあるブロッカー：

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