team-ui

チーム UI

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

Usage: /team-ui [UI feature description] [--review full|lean|solo] — 作成する画面または UI 機能を説明してください（例：inventory screen、main menu、combat HUD）。ここでは AskUserQuestion を使用せず、案内を直接出力してください。

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

意思決定ポイント： 各フェーズの移行時に、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（デフォルト）：ui-programmer + ux-designer。その他のエージェントにはこの2つのエージェントを通じて相談し、個別には起動しません。
• small：+ accessibility-specialist + art-director。
• studio：+ エンジン UI スペシャリスト + 敵対的レビューのパス：フェーズ 4 のレビュアーには「仕様に合致していることを確認するのではなく、仕様から外れている箇所を見つけることがあなたの仕事です」と伝え、レポートにはそのパスを実施したことを記載します。 individual でコア以外のエージェントが必要な場合は、情報メモを添えて最も近いアクティブなコアエージェントを経由します。「フェーズゲート」とは、このパイプライン自身が列挙する AskUserQuestion の意思決定ポイントで終了するフェーズを指します。つまり、「意思決定ポイント」の上記の遷移、または以下のパイプラインに記載された Gate ステップです。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 は厳密さを優先して設計されており、狭いデフォルト設定はトークンを節約する手段です。 これを明示しなければ、読者は、正しく絞り込まれた実行と、パイプラインが壊れている状態を区別できません。また、上記のエージェントごとの「情報メモを添えて最も近いコアエージェントを経由する」ルールは、ルーティング時に適用されるだけで、実行全体の構成を示すことはありません。

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

チーム構成

• ux-designer — ユーザーフロー、ワイヤーフレーム、アクセシビリティ、入力処理
• ui-programmer — UI フレームワーク、画面、ウィジェット、データバインディング、実装
• art-director — ビジュアルスタイル、レイアウトの仕上げ、アートバイブルとの一貫性
• engine UI specialist — エンジン固有のベストプラクティスに照らして UI 実装パターンを検証します（project.yaml の specialists.ui。存在しない場合は .claude/docs/technical-preferences.md の ## Engine Specialists にある UI Specialist の行）
• accessibility-specialist — フェーズ 4 でアクセシビリティへの準拠状況を監査します

specialists.ui: null は未設定を意味します。 存在しないものとして扱い、エンジン UI スペシャリストをスキップしてください。null をエージェント名として起動しないでください。v1.0 の移行では、メンバーが 1 つでも設定されている場合、specialists ブロック全体が書き込まれるため、ここが null なのは通常の状態です。また、設定リーダーはこれを空ではない文字列 "null" として返します。

このパイプラインで使用するテンプレート：

• ux-spec.md — 標準的な画面／フローの UX 仕様
• hud-design.md — HUD 固有の UX 仕様
• interaction-pattern-library.md — 再利用可能なインタラクションパターン
• accessibility-requirements.md — 確定済みのアクセシビリティレベルと要件

委任する方法

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

• subagent_type: ux-designer — ユーザーフロー、ワイヤーフレーム、アクセシビリティ、入力処理
• subagent_type: ui-programmer — UI フレームワーク、画面、ウィジェット、データバインディング
• subagent_type: art-director — ビジュアルスタイル、レイアウトの仕上げ、アートバイブルとの一貫性
• subagent_type: [UI engine specialist] — エンジン固有の UI パターンの検証（例：unity-ui-specialist、ue-umg-specialist、godot-specialist）
• subagent_type: accessibility-specialist — アクセシビリティ準拠の監査

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

すべてのエージェントへのプロンプトの末尾に、出力に関する契約を含めてください。 「出力全体を [path] に書き込んでください。その名前付きパスは、以下の限定的な例外に基づく書き込み許可先です。別途承認を求めることなく、そこに書き込んでください。返答するのは、（1）書き込んだパス、（2）判断事項の要約（箇条書き5項目以内）、（3）BLOCKED/CONCERNS 項目（それぞれ1行）のみです。読んだドキュメントを言い直さないでください。」これがないと、エージェントは読んだ内容をすべてこのセッションに返してしまいます。実装ファイルは例外です。 コードやアセットを作成するエージェントは、まず作成・変更するファイルを返答します。その返答を受けてファイル一式を一度だけ確認し、ユーザーが承認した後に限り、出力に関する契約でそれらのファイルを指定します（ファイル書き込みプロトコル）。この承認が、それらの書き込みを許可するものであり、限定的な例外は適用されません。

[path] は実際のパスに置き換えてください。 作業成果物は、Phase 1b の design/ux/[feature-name].md で使われるスラッグに従い、production/ui/[feature-name]/ 配下に置きます。Phase 4 のレビューが同じファイルを共有しないよう、エージェントごとに1ファイルを用意します。

フェーズ／エージェント	書き込み先
2 art-director	production/ui/[feature-name]/visual-design.md
3 エンジン UI スペシャリスト	production/ui/[feature-name]/engine-notes.md
3 ui-programmer	コードルート — 1回の実装依頼で指定したファイル（ファイル書き込みプロトコル）。限定的な例外の対象外です
4 ux-designer、art-director、accessibility-specialist	production/ui/[feature-name]/review-[agent].md。それぞれ別のファイル

UX 仕様書（Phase 1b）およびパターンライブラリの更新は、design/ 配下で、限定的な例外の対象外です。/ux-design またはエージェントは、書き込む前に確認を求めます。

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

パイプラインで可能な場合は、独立したエージェントを並行して起動します（例：Phase 4 のレビューエージェントは同時に実行できます）。

パイプライン

フェーズ 1a：コンテキストの収集

何かを設計する前に、内容を読み、統合してください。各 GDD をセクションごとに読みます。Grep ツール（パターン ^#、content モード）で必要な見出しを探し、offset と limit を指定して該当範囲を Read します。

• design/gdd/game-concept.md — プラットフォームの対象と想定するユーザー層（または、rigor: minimal の場合に置き換わる 1 ページの概要書 design/game-brief.md — 「Who it's for」の行にユーザー層が記載されています。プラットフォームの記載はありません）
• design/player-journey.md — プレイヤーがこの画面に到達したときの状態とコンテキスト
• この機能に関連するすべての GDD の UI 要件セクション
• design/ux/interaction-patterns.md — 再発明せずに再利用する既存のパターン
• design/accessibility-requirements.md — 確定済みのアクセシビリティレベル（Basic、Standard、Comprehensive、Exemplary）

何かを設計する前に、上記すべてのドキュメントの状態を報告してください。 フェーズ 1a では 5 つの入力を読みますが、いずれも存在しない場合があります。それぞれについて、存在するか ABSENT かを記載してください。

design/accessibility-requirements.md は、黙って通過させてはならない唯一のファイルです。 確定済みのアクセシビリティレベルが記載されており、フェーズ 3 はそれに基づいて実装し、フェーズ 4 はそれを基準に判定します（「確定済みのアクセシビリティレベルへの準拠を検証し……違反があればブロッカーとして報告する」）。このファイルが存在しない場合、レベルがないため、判定基準がなく、何も確認しないまま判定に通ってしまいます。これは、決して失敗しないアサーションと同じく、基準が欠けた判定です。ファイルが存在しない場合：

• ここでその旨を伝え、後続のフェーズにも引き継いでください。フェーズ 4 は Accessibility: NOT ASSESSED — no committed tier (design/accessibility-requirements.md absent) と報告し、アクセシビリティの判定に合格したと報告してはなりません。
• ux-designer は、設計時にどのレベルを前提としたかを明示的な仮定として示します。後から読む人が、それが確定事項ではなく仮定だったと分かるようにしてください。
• /ux-design accessibility を推奨し、レベルを確定してください。

コンセプト文書（design/gdd/game-concept.md と design/game-brief.md の両方）、design/player-journey.md、または design/ux/hud.md が存在しないことはブロッカーではありません。ただし、不足している各文書を ux-designer に渡すブリーフに記載し、コンテキストが不足していることを把握したうえで設計できるようにしてください。推測で補わせてはなりません。

design/ux/interaction-patterns.md が存在しない場合、ただちにその不足を伝えてください：

"interaction-patterns.md does not exist — no existing patterns to reuse."

次に、以下の選択肢を使って AskUserQuestion を実行してください：

• (a) まず /ux-design patterns を実行してパターンライブラリを整備してから、続行する
• (b) パターンライブラリなしで続行する — ui-programmer は、作成するすべてのパターンを新規として扱い、完了時に新しい design/ux/interaction-patterns.md にそれぞれを追加する

機能名や GDD だけからパターンを考案したり、推測したりしてはなりません。ユーザーが (b) を選んだ場合は、フェーズ 3 で ui-programmer に、すべてのパターンを新規として扱い、実装完了時に design/ux/interaction-patterns.md に記録するよう明示的に指示してください。最終サマリーレポートには、パターンライブラリの状態（作成済み／不在／更新済み）を記載してください。

ux-designer 向けのブリーフにコンテキストをまとめてください。プレイヤーが何をしているか、何を必要としているか、どのような制約が適用されるか、どの既存パターンが関連するかを記載してください。

フェーズ 1b：UX 仕様書の作成

/ux-design [feature name] スキルを呼び出すか、ux-designer に直接委任して、ux-spec.md テンプレートに従い design/ux/[feature-name].md を作成してください。

HUD を設計する場合は、ux-spec.md ではなく hud-design.md テンプレートを使用してください。

特殊なケースに関する注意：

• HUD の設計では、argument: hud を指定して /ux-design を呼び出してください（例：/ux-design hud）。
• インタラクションパターンライブラリは、プロジェクト開始時に /ux-design patterns を実行して作成し、後続フェーズで新しいパターンが導入されるたびに更新してください。

出力：必須の仕様セクションをすべて記入した design/ux/[feature-name].md。

フェーズ 1c：UX レビュー

仕様が完成したら、/ux-review design/ux/[feature-name].md を実行します。

ゲート：判定が APPROVED になるまでフェーズ 2 に進んではなりません。判定が NEEDS REVISION の場合、ux-designer は同じ仕様内で指摘された問題に対処し、レビューを再実行する必要があります。仕様は破棄せず、維持して改訂します。ユーザーは NEEDS REVISION のリスクを明示的に受け入れて先に進むこともできますが、その判断は意識的に行う必要があります。先に進むかどうかを尋ねる前に、AskUserQuestion を通じて具体的な懸念事項を提示してください。

NOT ASSESSED の判定も同様に進行をブロックします。ユーザーは同じ方法でこれを上書きできます。その解決方法は改訂ではなく、入力を用意することです。/ux-review で評価できなかった項目と、それぞれに不足している入力（例：コミットされていないアクセシビリティ階層に対する /ux-design accessibility）を提示してください。その入力なしでレビューを再実行しても同じ判定が返されるため、まず入力を作成することを提案してください。

ユーザーが NEEDS REVISION または NOT ASSESSED の判定を超えて先に進む場合、最終レポートには上書きした判定、未解決の懸念事項または未評価の項目、およびユーザーが先に進むことを選択した旨を記録します。

フェーズ 2：ビジュアルデザイン

art-director に委任します：

• UX 仕様全体（フロー、ワイヤーフレーム、インタラクションパターン、アクセシビリティに関する注記）を確認します。ワイヤーフレーム画像だけにとどめません
• アートバイブルに基づいてビジュアルを適用します：色、タイポグラフィ、余白、アニメーションスタイル
• ビジュアルデザインがアクセシビリティへの準拠を維持していることを確認します：色のコントラスト比を検証し、状態の表示に色だけを使用していないことを確認します（形状、テキスト、またはアイコンでも補強する必要があります）
• アートパイプラインで必要となるアセット要件をすべて指定します：指定サイズのアイコン、背景テクスチャ、フォント、装飾要素など。寸法と形式の要件を正確に記載します
• 実装済みの既存 UI 画面との一貫性を確保します
• 出力：スタイルに関する注記とアセット一覧を含むビジュアルデザイン仕様

フェーズ 3：実装

実装を開始する前に、エンジン UI スペシャリスト（project.yaml の specialists.ui。存在しない場合は .claude/docs/technical-preferences.md の ## Engine Specialists にある UI Specialist の行）を起動し、エンジン固有の実装ガイダンスについて UX 仕様とビジュアルデザイン仕様を確認してもらいます：

• この画面にはどのエンジン UI フレームワークを使用すべきですか？（例：Unity の UI Toolkit と UGUI、Godot の Control ノードと CanvasLayer、Unreal の UMG と CommonUI）
• 提案されたレイアウトやインタラクションパターンに、エンジン固有の注意点はありますか？
• このエンジンで推奨されるウィジェット／ノード構成は何ですか？
• 出力：ui-programmer が作業を始める前に引き継ぐ、エンジン UI の実装に関する注記

エンジンが設定されていない場合は、このステップを省略します。この実行の出力に Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`) を記録してください。 何も記載されていない省略チェックは、合格したチェックと区別がつきません。読者には、エンジンのガイダンスが求められなかったことが分からないためです。

ui-programmer に委任します：

• UX 仕様とビジュアルデザイン仕様に従って UI を実装します
• design/ux/interaction-patterns.md のパターンを使用します — すでに仕様化されたパターンを独自に作り直してはなりません。パターンがほぼ合致するものの変更が必要な場合は、逸脱を記録し、ux-designer にレビューを依頼してください
• UI がゲーム状態を所有または変更することは決してありません — 表示のみとし、プレイヤーのすべてのアクションについてイベントを発行します
• テキストはすべてローカライズシステムを通じて扱います。プレイヤーに表示する文字列をハードコードしてはなりません
• 2 種類の入力方式（キーボード／マウスとゲームパッド）を両方サポートします
• design/accessibility-requirements.md にコミットされた階層に従って、アクセシビリティ機能を実装します
• ゲーム状態へのデータバインディングを設定します
• 実装中に新しいインタラクションパターンを作成した場合（つまり、パターンライブラリにまだ存在しないパターン）、実装完了とする前に design/ux/interaction-patterns.md に追加します
• 出力：実装済みの UI 機能

フェーズ 4：レビュー（並行）

以下を並行して割り当てます。

• ux-designer：実装がワイヤーフレームとインタラクション仕様に一致していることを確認します。キーボードのみ、およびゲームパッドのみでの操作をテストします。アクセシビリティ機能が正しく動作することを確認します。
• art-director：アートバイブルとの視覚的な一貫性を確認します。サポートされる最小解像度と最大解像度で確認します。
• accessibility-specialist：design/accessibility-requirements.md に記載された確定済みのアクセシビリティティアへの準拠を確認します。違反はブロッカーとして報告します。このファイルが存在しない場合、確定済みのティアはありません。そのため、このゲートには基準がありません。「Accessibility: NOT ASSESSED — no committed tier (design/accessibility-requirements.md absent)」と報告し、ゲートを合格として報告しないでください。フェーズ 1a で前提として記録されたティアがあれば、それを引き継ぎ、前提として扱ったことを明記してください。

フェーズ 5 に進む前に、3 つのレビューすべてから報告を受ける必要があります。

フェーズ 5：仕上げ

• レビューのフィードバックにすべて対応します
• アニメーションをスキップでき、プレイヤーの視覚効果低減設定に従うことを確認します
• UI サウンドがオーディオイベントシステム経由で再生されることを確認します（オーディオを直接呼び出さないでください）
• サポートされるすべての解像度とアスペクト比でテストします
• design/ux/interaction-patterns.md が最新であることを確認します — この機能の実装中に新しいパターンが導入された場合は、ライブラリに追加されていることを確認します
• すべての HUD 要素が design/ux/hud.md で定義された視覚的な予算（要素数、画面領域の割り当て、最大不透明度）を守っていることを確認します

クイックリファレンス — 使用するスキルの選び方

• /ux-design — 画面、フロー、HUD の新しい UX 仕様をゼロから作成します
• /ux-review — 実装前に完成した UX 仕様を検証します
• /team-ui [feature] — コンセプトから仕上げまでの全工程を実行します（内部で /ux-design と /ux-review を呼び出します）
• /quick-design — 新しい UX 仕様を一式用意する必要のない小規模な UI 変更に使用します

エラー復旧プロトコル

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

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

よくあるブロッカー：

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

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

すべてのファイル書き込み（UX 仕様、インタラクションパターンライブラリの更新、実装ファイル）は、サブエージェントとサブスキルに委任されます。この2つは異なるルールに従います。

• Agent で起動するサブエージェント（例：ui-programmer）は、前述の「なぜこれはコラボレーションプロトコルに違反しないのか」に記載された限定的な例外に従います。パスはあなたが指定したもので、成果物は production/、docs/、または tests/ の下に新規作成され、フェーズは AskUserQuestion による確認を経て進みます。この範囲内では、サブエージェントは書き込みごとに確認を求めません。この範囲外では、確認を求める必要があります。 実装ファイル（コードルート配下にある ui-programmer のコード）はこの範囲外です。ui-programmer が作成または変更するファイルを提示した後、その一式について一度確認を求め、承認後に書き込みます。
• サブスキル（/ux-design）はサブエージェントではなく、この例外の対象外です。通常のコラボレーションプロトコルに従い、書き込み前に確認を求めます。

このオーケストレーターはファイルを直接書き込みません。

出力

UX 仕様の状況、UX レビューの判定、ビジュアルデザインの状況、実装状況、アクセシビリティへの準拠状況、入力方式のサポート状況、インタラクションパターンライブラリの更新状況、未解決の問題を網羅したサマリーレポート。

判定：COMPLETE — UI 機能が全工程（UX 仕様 → ビジュアル → 実装 → レビュー → 仕上げ）を経て提供されました。

アクセシビリティのゲート（コミット済みのティアがない場合）またはエンジン検証（エンジンが設定されていない場合）が未評価の場合、判定にはそれぞれの項目名を明記します。単に COMPLETE としてはいけません。

判定：COMPLETE — [accessibility | engine validation] NOT ASSESSED ([理由]) — UI 機能は提供されましたが、記載されたチェックを実行できませんでした。

判定：BLOCKED — パイプラインが停止しました。停止前にブロッカーとそのフェーズを明示してください。

次のステップ

• 最終仕様がまだ承認されていない場合は、/ux-review を実行します。
• ストーリーを完了する前に、UI 実装に対して /code-review を実行します。
• ビジュアルまたは音声の仕上げが必要な場合は、/team-polish を実行します。