ux-design

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,docs.density

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

UX デザイン

このスキルが呼び出されたとき：

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （collaborative は常に質問、guided は主要な項目のみ、autonomous は記録して続行、 automation_always_ask カテゴリは常に質問します）。

作成ガイダンス：以下のひな形は自己完結しているため、そこから直接作成できます。 セクションに詳しい情報（具体例、パターンカタログ、 アクセシビリティ基準）が必要な場合は、対応するガイドに記載されています。

作成物	ガイド
UX 仕様書	.claude/docs/templates/guidance/ux-spec-guide.md
HUD デザイン	.claude/docs/templates/guidance/hud-design-guide.md
インタラクションパターン	.claude/docs/templates/guidance/interaction-pattern-library-guide.md（3 つのトピックファイルへ案内）
アクセシビリティ要件	.claude/docs/templates/guidance/accessibility-requirements-guide.md

ガイドはセクションごとに読み、全体を一度に読まないでください — 各ガイドはセクションごとに構成されており、 テンプレート内の参照箇所に読むべきセクションが明記されています。

workflow（.claude/docs/workflow-modes.md を参照）：

• full — 画面ごとに UX 仕様書が必要です。
• standard — コア画面のみ（メインメニュー、HUD、主要なゲームループ）。
• minimal — 必須ではありません。任意で作成してもかまいません。

docs.density — workflow が仕様書を作成する画面を制御するのに対し、これはセクションごとの 詳細度を制御します。modes.rigor は両方をまとめて設定します。詳細度のみを変えるには docs.density を明示的に設定します：terse（デフォルト。rigor: minimal 経由）＝ワイヤーフレームの説明 + インタラクションの箇条書き、balanced ＝ワイヤーフレーム + フローの段落形式の説明 （rigor: standard）、thorough ＝ユーザー調査の要約や 代替フローの検討も含む詳細な文章。作成するすべてのセクションに適用してください。

1. 引数を解析してモードを決定する

引数に応じて、4 つの作成モードがあります。

引数	モード	出力ファイル
hud	HUD デザイン	design/ux/hud.md
patterns	インタラクションパターンライブラリ	design/ux/interaction-patterns.md
accessibility	プロジェクト全体のアクセシビリティ要件	design/accessibility-requirements.md
その他の値（例：main-menu、inventory）	画面またはフローの UX 仕様書	design/ux/[argument].md
引数なし	ユーザーに質問	（以下を参照）

accessibility だけが design/ux/ の外に書き込みます。 その出力は画面ごとの仕様書が参照する プロジェクト全体の標準であり、.claude/docs/workflow-catalog.yaml、Pre-Production と Polish のゲート、/architecture-review はすべて、 正確に同じパスにある design/accessibility-requirements.md を確認します。これを design/ux/ の下に「整理」しないでください。該当するすべてのチェックで一致しなくなり、 Technical Setup → Pre-Production ゲートを通過できなくなります。

引数が指定されていない場合は、失敗として扱わず、代わりに質問してください。AskUserQuestion を使用します：

• 「今日は何をデザインしますか？」
  • 選択肢：「特定の画面またはフロー（名前を指定します）」、「ゲーム HUD」、「インタラクションパターンライブラリ」、「プロジェクト全体のアクセシビリティ要件」、「よくわかりません — 一緒に考えてください」

ユーザーが「名前を指定します」を選ぶか画面名を入力した場合は、ファイル名に使えるよう kebab-case に正規化します（例：「Main Menu」は main-menu になります）。

---

2. コンテキストの収集（読み取りフェーズ）

今すぐ references/2-gather-context.md を読み、そこに従ってください — このフェーズの手順はここではなく、 そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読んでください。

3. ファイルのひな形を作成する

今すぐ references/3-file-skeleton.md を読み、そこに従ってください — このフェーズの手順はここではなく、 そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読んでください。

4. セクションごとの作成

今すぐ references/4-authoring.md を読み、記載された手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり、再開されたりした場合は、もう一度読み直してください。

セクションごとのガイダンス — 現在のモードに対応するファイルを1つだけ読む

セクションごとの作成ガイダンスは、モードごとに個別のファイルに記載されています。フェーズ4に進んだら、セクション1で確定したモードに対応するファイルだけを読み、ほかの2つは読み込まないでください。

モード	ガイダンスファイル
UX Spec（画面またはフロー）	references/sections-ux-spec.md
HUD Design	references/sections-hud.md
Interaction Pattern Library	references/sections-patterns.md
Accessibility Requirements	.claude/docs/templates/guidance/accessibility-requirements-guide.md

アクセシビリティのガイダンスは、このスキルの references/ ではなく templates/guidance/ にあります。これは、ガイダンスの対象となるテンプレート（.claude/docs/templates/accessibility-requirements.md）が /ux-review とゲートファイルでも使用されるためです。同じルールが適用されます。作成中のセクションに該当する部分だけを読み、ファイル全体は読み込まないでください。

docs.density（セクション1）を、そのファイルで作成するよう指示された内容に適用してください。これは各セクションの詳細度を制御するものであり、セクションの有無を決めるものではありません。

5. 相互参照の確認

今すぐ references/5-crossref-handoff.md を読み、記載された手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり、再開されたりした場合は、もう一度読み直してください。

7. 復旧と再開

セッションが中断された場合（圧縮、クラッシュ、新しいセッション）：

1. production/session-state/active.md を読みます — 現在の画面と、完了したセクションが記録されています。
2. design/ux/[filename].md を読みます — 実際の内容が記載されたセクションは完了済みで、[To be designed] のままのセクションは未完了です。
3. 次の未完了セクションから再開します — 完了済みのセクションについて再度話し合う必要はありません。

これが段階的な執筆が重要である理由です。承認済みのセクションは、中断があってもすべて保持されます。

---

8. 専門エージェントへのルーティング

このスキルでは、ux-designer をプライマリエージェントとして使用します（frontmatter で設定）。特定のサブトピックについては、追加のコンテキストや調整が必要になる場合があります。

トピック	連携先
ビジュアルの美しさ、色、レイアウトの印象	art-director — UX Spec でゾーンを定義し、アートでその見た目を定義します
実装可能性（エンジンの制約）	ui-programmer — コンポーネント一覧を確定する前に確認します
ゲームプレイデータの要件	game-designer — データの所有者が不明な場合に連携します
UI に表示される物語や設定	narrative-director — フレーバーテキスト、アイテム名、ロアパネルについて連携します
アクセシビリティのティア決定	このセッションで記録します（/ux-design accessibility。ティアはユーザーが選択します）。accessibility-specialist が定義・監査する基準に基づき、要件の基準が不明確な場合は確認してください

Agent ツールを使って別のエージェントに作業を委任する場合：

• 提供する情報：画面名、ゲームコンセプトの概要、専門家の意見を必要とする具体的な質問
• エージェントは分析結果をこのセッションに返します
• このセッションはエージェントの出力をユーザーに提示します
• ユーザーが決定し、このセッションがファイルに書き込みます
• エージェントはファイルに直接書き込みません — すべてのファイル書き込みはこのセッションが担当します

コラボレーションプロトコル

collaborative モード（デフォルト）では。 guided モードと autonomous モードについては、 .claude/docs/automation-modes.md に記載されている各モードのルールを参照してください。以下の手順は collaborative モードで必要なことを説明しており、すべてのモードに共通するものではありません。

このスキルでは、すべての手順でコラボレーション設計の原則に従います。

1. 質問 -> 選択肢 -> 決定 -> 草案 -> 承認を、各セクションで実施します
2. すべての意思決定の場面で AskUserQuestion を使用します（説明 -> パターンの記録）。
   • フェーズ 2：「開始しますか、それとも追加のコンテキストが必要ですか？」
   • フェーズ 3：「骨組みを作成してもよいですか？」
   • フェーズ 4（各セクション）：設計に関する質問、アプローチの選択肢、草案の承認
   • フェーズ 5：「相互参照を確認しますか？次は何をしますか？」
3. 骨組みの作成前、および各セクションの書き込み前に、**「[filepath] に書き込んでもよいですか？」**と確認します
4. 段階的に書き込みます：承認後、各セクションをすぐにファイルへ書き込みます
5. セッション状態を更新します：各セクションの書き込み後に更新します

美的判断の尊重：レイアウトや見た目の選択が個人の好みによる場合は、 選択肢を提示して質問してください。「標準的」であることを理由にレイアウトを選ばず、必ず 確認してください。ユーザーがクリエイティブディレクターです。

競合の明示：GDD の要件と利用可能な画面領域が競合する場合は、その競合を明示し、解決策を提示してください。 要件を黙って削除してはいけません。問題を指摘せずにレイアウトを拡張してはいけません。

決して仕様全体を自動生成し、既成事実として提示してはいけません。 決してユーザーの承認なしにセクションを書き込んではいけません。 決して競合を明示せずに、既存の承認済み UX 仕様と矛盾してはいけません。 必ず決定の根拠（GDD の要件、プレイヤーの行動経路、ユーザーの選択）を示してください。

判定：完了 — UX 仕様を作成し、セクションごとに承認を得ました。

---

推奨される次のステップ

• /ux-review [filename] を実行して、この仕様を実装パイプラインに進める前に検証します
• /ux-design [next-screen] を実行して、残りの画面やフローの設計を続けます
• 主要な画面すべての UX 仕様が承認されたら、/gate-check production を実行します