art-bible

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

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

アートバイブル

フェーズ 0：引数の解析とコンテキストの確認

チェックの完全なパターンについては、.claude/docs/director-gates.md を参照してください。個々のゲートの定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントは独自のゲートファイルを読み込みます。親セッションでは読み込まないでください。

すべての AskUserQuestion の呼び出しは .claude/docs/automation-modes.md に従います （共同モードでは常に質問し、ガイドモードでは主要な項目のみ質問し、自律モードでは記録して続行します。 automation_always_ask のカテゴリーでは常に質問します）。

docs.density — これはセクションごとの 詳しさ を制御し、workflow はどのセクションを含めるかを制御します。modes.rigor は両方をまとめて設定します。詳しさだけを変えるには、docs.density を明示的に設定してください。terse（デフォルト。rigor: minimal による）では、各セクションは制約と参照を箇条書きで示します。balanced では、各視覚的選択について説明する段落を設けます （rigor: standard）。thorough では、スタイルの検討、参照資料、選択の根拠を含む詳細な文章を記述します。作成するすべてのセクションに適用してください。

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

• full — アートバイブルの全 9 セクションが必須です。
• standard — プロジェクトにビジュアルアセットのストーリーがある場合にのみ必須です。 必須の場合、セクション 1～4 が最低限必要です。workflow_overrides.art_bible_strict: true を設定すると、ティアにかかわらず全 9 セクションが必須になります。
• minimal — 必須ではありません。任意で実行できます。

design/gdd/game-concept.md を読み込んでください。rigor: minimal の場合は、これに代わる 1 ページの概要である design/game-brief.md を読み込みます。セクションごとに読み込んでください。Grep ツール（パターン ^#、コンテンツモード）で必要な見出しを探し、offset と limit を指定して該当範囲を Read します。どちらのファイルも存在しない場合は、次のメッセージを表示して処理を終了します。

「ゲームコンセプトが見つかりません。まず /brainstorm を実行してください。アートバイブルはゲームコンセプトの承認後に作成されます。」

game-concept.md から、次の情報を抽出します（概要から抽出する場合は、作業タイトル、ピッチ、「対象者／感じてもらいたいこと」の行、「アートと音声の方向性」の行。概要には柱、Visual Identity Anchor、プラットフォームはありません）。

• ゲームタイトル（作業タイトル）
• 中心となるファンタジーとエレベーターピッチ
• ゲームの柱（すべて）
• Visual Identity Anchor セクションがある場合は、その内容（ブレインストーミングのフェーズ 4 におけるアートディレクターの出力）
• 対象プラットフォーム（記載されている場合）

改訂モードの検出：design/art/art-bible.md を Glob します。ファイルが存在する場合は、ドキュメントを読み込まずにステータステーブルを作成してください。これから作成するのは 未完了 のセクションのみです。完成済みのセクションを読み込むことは、まさに手を加えない部分を読み込むことになります。

Grep pattern="^## " path="design/art/art-bible.md" output_mode="content" -n
Grep pattern="\[To be designed\]|\[TBD\]|\[To be written\]|^_?TODO" path="design/art/art-bible.md" output_mode="content" -n

• 1 つ目の grep でセクションの見出しと行番号が得られます。連続する見出しの間隔が、そのセクションのサイズです。
• 2 つ目の grep でプレースホルダーマーカーとその位置が得られます。
• セクション内にプレースホルダーマーカーがなく、次の見出しまでに十分な内容がある場合、そのセクションは Complete です。マーカーが範囲内にある場合は Placeholder です。連続する見出しが隣接している場合は Empty です。
• 2 つの grep だけではセクションの状態を判断できない場合は、Read(offset, limit) で そのセクションの 行範囲を読み込みます。ファイル全体は決して読み込まないでください。
• セクションのステータステーブルを作成します。

Section | Status
--------|--------
1. Visual Identity Statement | [Complete / Empty / Placeholder]
2. Mood & Atmosphere | ...
3. Shape Language | ...
4. Color System | ...
5. Character Design Direction | ...
6. Environment Design Language | ...
7. UI/HUD Visual Direction | ...
8. Asset Standards | ...
9. Reference Direction | ...

• 次の文言で、このテーブルをユーザーに提示します。

  「既存のアートバイブル design/art/art-bible.md が見つかりました。[N] セクションは完成済みで、[M] セクションに内容が必要です。未完了のセクションのみ作業し、既存の内容には手を加えません。」

• Status が Empty または Placeholder のセクションのみ作業します。すでに完成しているセクションは再作成しないでください。 ファイルが存在しない場合は、新規作成セッションです。最初に承認されたセクションで、.claude/docs/templates/art-bible.md からファイルを作成します。このテンプレートの9つの ## N. Name 見出しが、改修モードで読み取られる見出しです。まず、次のように確認してください。 「アートバイブルのテンプレートから design/art/art-bible.md を作成してもよいですか？」承認された各セクションでは、そのセクション固有の [To be designed] 行を Edit に置き換えます。見出しはテンプレートのまま維持してください。

セクションの承認は、そのセクションの書き込みを承認するものです。 各セクションは、承認オプションが [A] Lock this in and write it to design/art/art-bible.md となっている AskUserQuestion を通じて承認されます（Section 1 のオプション一覧は以下を参照）。このオプションを選ぶことが、そのセクションを書き込む承認になります。新規作成でも改修でも、承認なしにセクションを書き込んではいけません。

アセット標準の制約に関するパフォーマンス予算とエンジンを取得するには、project.yaml の performance.* と engine.name を読み取ります。キーが存在しないか空の場合（project.yaml に performance または engine ブロックがない場合を含む）は、.claude/docs/technical-preferences.md を参照してください。

---

Phase 1: 方針の確認

作成を始める前に、セッションの概要を提示し、2つの質問をします。

AskUserQuestion を2つのタブで使用します。

• Tab "Scope" — 「今日はどのセクションを作成しますか？」 選択肢：Full bible — all 9 sections / Visual identity core (sections 1–4 only) / Asset standards only (section 8) / Resume — fill in missing sections

  解決済みの workflow ティアで実際に必要となる選択肢に（Recommended）を付け、その理由を説明します。ティアによって必要な内容はすでに決まっているため、ユーザーがティアの表を把握している必要はありません。

  • full → Full bible — このティアでは9セクションすべてが必須です。
  • standard → Visual identity core (sections 1–4 only) — アートバイブルが必須の場合、文書で定められた最低要件はこれです。「standard で必要なのはセクション1～4です。希望する場合は、セクション5～9も作成できます」と伝えてください。
  • minimal → アートバイブルは必須ではありません。その旨を質問の前に伝え、デフォルトで9セクションを選ぶのではなく、希望する場合に役立つ選択肢としてセクション1～4を提示してください。
  • workflow_overrides.art_bible_strict: true → ティアにかかわらず Full bible です。

  このスキルで最も大きなコスト要因です。作成する各セクションには専門家の起動が伴うため、ティアで必要な4セクションではなく9セクションを作成すると、後続処理で確認されない成果物のために実行コストが2倍以上になります。

• Tab "References" — 「ビジュアルの方向性を決める参考作品（ゲーム、映画、アートなど）はありますか？」 （自由入力。具体的なタイトルを入力できるようにしてください。ここに選択肢をあらかじめ設定してはいけません。）

game-concept.md に Visual Identity Anchor セクションがある場合は、その内容に触れてください。

「ブレインストーミングからビジュアルアイデンティティのアンカーが見つかりました。'[anchor name] — [one-line rule]' です。これをアートバイブルの基盤として使用します。」

---

選択されたスコープに含まれるセクションだけを作成してください。 Phase 2～4 はその範囲内のセクションだけを実行し、Resume の場合は改修表の Empty 行と Placeholder 行のみを対象にします。それ以外のすべてのセクションと、対象がないフェーズはスキップしてください。Phase 6 では、今回作成しなかった各セクションと、その理由を示します。

---

フェーズ 2：ビジュアルアイデンティティの基盤（セクション 1～4）

この 4 つのセクションで、ビジュアルの中核となる表現言語を定義します。ほかのすべてのセクションは、ここから展開されます。 各セクションを作成してファイルに書き込んでから、次に進んでください。

このフェーズの委任方針。 セクション 1 は単独で委任します。基盤となるセクションであり、ほかの内容がそれを土台にできるようにする前に、ユーザーが方向性の基準を選ぶためです。その後、セクション 2～4 は 3 回に分けず、art-director を 1 回呼び出して委任します。これらは同じ入力（Visual Identity Statement とピラー）を受け取る同じエージェントが担当するセクションであり、ムード、形状、色は相互に依存しています。アートディレクターはこれらを個別ではなく、まとめて定義します。別々に呼び出すと、エージェントは直前に書いた形状表現を把握しないまま、色について推論することになります。

これは専門家の関与を減らすものではありません。各セクションは引き続き専門家が作成します。.claude/docs/effects-map.md がアートバイブルの委任は必須だと述べているのは、そのためです。同じ 3 セクションに対する呼び出しが 3 回から 1 回になるだけです。セクションごとのユーザー承認と、即時のファイル書き込みに変更はありません。

セクション 1：ビジュアルアイデンティティステートメント

目標：ビジュアル上の曖昧さを解消する、一行のビジュアルルールと 2～3 個の補足原則を定めます。

game-concept.md にビジュアルの基準がある場合は、それを提示して次のように尋ねます。

• 「この基準をそのまま発展させますか？」
• 「発展させる前に修正しますか？」
• 「新しい選択肢で一から始めますか？」

エージェントへの委任（必須）：Agent 経由で art-director を起動します。

• 提供する情報：ゲームコンセプト（エレベーターピッチ、中核となるファンタジー）、ピラー一式、対象プラットフォーム、フェーズ 1 の方向性づけで挙げた参考ゲームやアート、存在する場合はビジュアルの基準
• 依頼内容：「このゲームの Visual Identity Statement の草案を作成してください。以下を提示してください：（1）あらゆるビジュアル判断の曖昧さを解消できる一行のビジュアルルール、（2）補足となるビジュアル原則を 2～3 個。それぞれに一文のデザインテスト（『X が曖昧な場合、この原則に従って Y を選ぶ』）を添えてください。すべての原則を明示されたピラーに直接結び付けてください。各原則は特定のピラーに役立つ必要があります。（ピラーのない 1 ページのブリーフの場合は、ピッチと「どのように感じるか」の行に結び付けてください。）」

アートディレクターの草案をユーザーに提示します。AskUserQuestion を使います。

• 選択肢：[A] これで確定し、design/art/art-bible.md に書き込む / [B] 一行のルールを修正する / [C] 補足原則を修正する / [D] 独自の方向性を説明する

承認されたセクションをすぐにファイルへ書き込みます。

セクション 2：ムードと雰囲気

目標：ゲームの状態ごとの感情的な目標。ライティングアーティストが作業できるだけの具体性を持たせます。

各主要なゲーム状態（例：探索、戦闘、勝利、敗北、メニュー。このゲームの状態に合わせて調整）について、以下を定義します。

• 主な感情／ムードの目標
• ライティングの特徴（時間帯、色温度、コントラストの強さ）
• 雰囲気を表す語句（形容詞を3～5個）
• エネルギーレベル（熱狂的／抑制的／思索的など）

セクション 2～4 のエージェントへの委任 — ここで一度だけ依頼します。 固定済みのビジュアル・アイデンティティ・ステートメントと柱のセットを添えて、Agent 経由で art-director を起動し、次の3セクションすべてを1つのブリーフで作成するよう依頼します。

1. ムードと雰囲気 — 「このゲームの各主要なゲーム状態におけるムードと雰囲気の目標を定義してください。具体的にしてください。『暗く、不吉』だけでは不十分です。正確な感情の目標、ライティングの特徴（暖色／寒色、コントラストの強さ、時間帯の方向性）、およびムードを伝えるビジュアル要素を少なくとも1つ示してください。各ゲーム状態は、ほかの状態と視覚的に明確に異なるものにしてください。」
2. シェイプランゲージ — 「このゲームのシェイプランゲージを定義してください。各形状の原則を、ビジュアル・アイデンティティ・ステートメントと特定のゲームの柱に結び付けてください。これらの形状の選択が、プレイヤーに感情面で何を伝えるのか説明してください。」
3. カラーシステム — 「このゲームのカラーシステムを設計してください。各意味的な色の割り当てについて、すべて理由を説明してください。この世界では、なぜその色が危険／安全／報酬を意味するのでしょうか。色覚に障害のあるプレイヤーにとって見分けにくい可能性がある色の組み合わせを特定し、必要な代替手がかりを明記してください。」

3つのセクションが相互に整合していることを必須とします。パレットはムードの目標と形状の階層を支える必要があります。また、それぞれを個別に承認して書き込めるよう、3つのラベル付きブロックに分けて返すよう求めます。

続いてセクション 2をユーザーに提示し、承認を得たら、セクション 3 に移る前にすぐにファイルへ書き込みます。3つすべてを一度に提示してはいけません。まとめて依頼するのは委任時であり、レビュー時ではありません。

セクション 3：シェイプランゲージ

目標：このゲームの世界に視覚的一貫性と識別性をもたらす幾何学的な語彙。

以下を扱います。

• キャラクターのシルエットに関する方針（サムネイルサイズでどれほど判別しやすいか。アーキタイプごとの識別特性は何か）
• 環境の形状（角張った形／曲線的な形／有機的な形／幾何学的な形のうち、どれが優勢で、なぜか）
• UI の形状文法（UI は世界の美的表現を反映するのか、それとも独自の HUD 表現を持つのか）
• 主役となる形と補助的な形（視線を引くもの、背景に退くもの）

ドラフトの出典：セクション 2 のもとで依頼した、セクション 2～4 のエージェントへの委任結果を使用します。返されたシェイプランゲージのブロックを使用してください。再度起動してはいけません。

承認されたセクションは、すぐにファイルへ書き込みます。

セクション 4：カラーシステム

目標：美的ニーズと情報伝達のニーズの両方に応える、制作可能な完全なパレットシステム。

以下を扱います。

• 基本パレット（役割を持つ5～7色。16進カラーコードだけでなく、この世界で各色が何を意味するのかも示す）
• 意味に基づく色の使い方（赤は何を伝えるのか。金色は？ 青は？ 白は？ 色の語彙を確立する）
• バイオームまたはエリアごとの色温度のルール（ゲームに明確に異なるエリアがある場合）
• UI パレット（ワールドのパレットと異なっていてもかまいません。違いを明確に定義します）
• 色覚への配慮：どのような意味を持つ色に、形状／アイコン／音による代替の手がかりが必要か

ドラフトの出典：セクション 2 のもとで依頼した、セクション 2～4 のエージェントへの委任結果を使用します。返されたカラーシステムのブロックを使用してください。再度起動してはいけません。

承認されたセクションは、すぐにファイルへ書き込みます。

---

フェーズ 3：制作ガイド（セクション 5～8）

これらのセクションでは、ビジュアル・アイデンティティを具体的な制作ルールに落とし込みます。追加の説明がなくても外注チームが従えるほど具体的にしてください。

セクション 5：キャラクターデザインの方針

セクション 5〜6 のエージェントへの委任 — ここで 1 回だけ呼び出します。 どちらのセクションにも同じ入力（sections 1–4）を使って同じエージェントが必要なため、2 回目の呼び出しではビジュアルアイデンティティ全体を再送するだけになります。sections 1–4 を渡して art-director を 1 回起動し、次の両方を依頼してください。

1. キャラクターデザインの方針 — 「以下を網羅してください：プレイヤーキャラクターがいる場合、その視覚的な原型；キャラクターの種類ごとの識別特徴のルール（敵／NPC／味方をプレイヤーがひと目で見分ける方法）；表情／ポーズのスタイル目標（硬い／表情豊か／リアル／誇張）；LOD の考え方（ゲームのカメラ距離でどの程度のディテールを維持するか）。」
2. 環境デザインの表現方針 — 「以下を網羅してください：建築様式と世界の文化／歴史との関係；テクスチャの考え方（ペイント調／PBR／スタイライズド — このゲームでその選択をする理由）；プロップ密度のルール（まばら／高密度 — エリアの種類ごとの選択を決める要因）；環境を通じたストーリーテリングのガイドライン（テキストを使わずにストーリーを伝える視覚的なディテール）。」

キャラクターと環境が互いに対して見分けやすいようにしてください。キャラクターのシルエットは、同じブリーフで定義する環境のテクスチャ密度を背景にしても認識できる必要があります。2 つのブロックに分け、それぞれラベルを付けて返してください。

まずセクション 5を提示し、承認を得てファイルに書き込んでから、セクション 6 に進みます。

セクション 6：環境デザインの表現方針

ドラフトの出典：セクション 5 で指示したセクション 5〜6 の委任内容です。返された環境ブロックを使用してください。再度起動しないでください。

承認されたセクションをファイルに書き込みます。

セクション 7：UI/HUD のビジュアル方針

エージェントへの委任：以下を並列で起動します。

• art-director：UI のビジュアルスタイル — ダイジェティック HUD とスクリーンスペース HUD のどちらにするか、タイポグラフィの方向性（フォントの個性、ウェイト、サイズの階層）、アイコンのスタイル（フラット／アウトライン／イラスト調／フォトリアル）、UI 要素のアニメーションの雰囲気
• ux-designer：UX との整合性チェック — ビジュアルの方向性は、このゲームに必要なインタラクションパターンを支えているか。アートディレクションと可読性／アクセシビリティの要件との間に矛盾があれば指摘してください。

両方の結果を収集します。食い違いがある場合（例：art-director が凝ったダイジェティック UI を提案する一方で、ux-designer が戦闘時の視認性を損なうと指摘する場合）は、両者の見解を明示して矛盾を提示してください。黙って解決してはいけません。AskUserQuestion を使ってユーザーに判断を委ねてください。

承認されたセクションをファイルに書き込みます。

セクション 8：アセットの基準

エージェントへの委任：以下を並列で起動します。

• art-director：ファイル形式の選定、命名規則の方向性、テクスチャ解像度の段階、LOD レベルの想定、エクスポート設定の考え方
• technical-artist：エンジン固有の厳格な制約 — アセットカテゴリごとのポリゴン数予算、テクスチャメモリ上限、マテリアルスロット数、インポーターの制約、パフォーマンス予算（project.yaml の performance.*、存在しない場合は .claude/docs/technical-preferences.md）に記載された内容

アート上の希望が技術的な制約と矛盾する場合（例：art-director が 4K テクスチャを希望する一方、パフォーマンス予算ではモバイル向けに 2K が必要な場合）は、理想の基準と制約に合わせた基準、およびトレードオフの両方を明示して矛盾を提示してください。黙って解決してはいけません。AskUserQuestion を使ってユーザーに選んでもらってください（選択肢：理想の基準、制約に合わせた基準、または両方を記載してアセットごとに判断）。アセット基準の曖昧さは、制作コストが生まれる原因です。

承認されたセクションをファイルに書き込みます。

フェーズ 4：参考資料の方向性（セクション 9）

目標：各参考資料から何を取り入れ、何を避けるべきかを具体的に示した、厳選された参考資料セットを作成します。

エージェントへの委任：セクション 1～8 を完成させたうえで、Agent を使って art-director を起動します。次のように依頼してください。「このゲームの参考資料の方向性をまとめてください。参考資料（ゲーム、映画、アートスタイル、特定のアーティスト）を 3～5 件挙げてください。それぞれについて、参考にする視覚的要素を正確に指定してください（『全体的な美学』ではなく、具体的な技法、色の選択、構図のルールなど）。また、『X の模倣を試みている』という印象を避けるため、明確に避ける点や、異なる方向にする点も指定してください。参考資料は相互に補完し合うものとし、同じ方向性を示すものを複数含めないでください。」

承認されたセクションをファイルに書き込みます。

---

フェーズ 5：アートディレクターの最終承認

レビューモードの確認 — AD-ART-BIBLE を起動する前に適用してください。

• solo → スキップします。次のように記録します：「AD-ART-BIBLE をスキップしました — Solo モード。」その後、下記のとおりスキップを記録して、フェーズ 6 に進みます。
• lean → スキップします（PHASE-GATE ではありません）。次のように記録します：「AD-ART-BIBLE をスキップしました — Lean モード。」その後、下記のとおりスキップを記録して、フェーズ 6 に進みます。
• full → 通常どおり起動します。

いずれかのモードでスキップする場合は、「スキップした最終承認を design/art/art-bible.md のヘッダーに記録してもよろしいですか？」と尋ね、承認されたら、ヘッダーの > **Art Director Sign-Off (AD-ART-BIBLE)**: [Not yet reviewed] を > **Art Director Sign-Off (AD-ART-BIBLE)**: SKIPPED [date] — [solo|lean] mode に置き換えます。ゲートでは、いずれの形式も最終承認の記録として受け付けます。

すべてのセクションが完了した後（またはフェーズ 1 で指定した範囲が完了した後）、ゲート AD-ART-BIBLE（.claude/docs/director-gates/ad-art-bible.md）を使用して、Agent から art-director を起動します。

アートバイブルのパス（design/art/art-bible.md）、ゲームの柱と中核となるファンタジー、プラットフォームとパフォーマンスの制約（project.yaml の platform.* と performance.*。見つからない場合は .claude/docs/technical-preferences.md を参照）、およびビジュアルアイデンティティの基準となる要素を渡します。フェーズ 0 で 1 ページのブリーフを読んだ場合は、その中のピッチと「感じてほしいこと」の一文を柱とファンタジーとして、「アートとオーディオの方向性」の一文を基準となる要素として渡します。

判定は director-gates.md の標準ルールに従って処理します。 Revise flagged items の場合、または REJECT を解決する場合は、セクションを担当する専門家（セクション 7 は ux-designer、セクション 8 は technical-artist と連携する art-director）が、指摘された各セクションを再作成します。その後、他のセクションと同様に提示して承認を得たうえで書き込み、REVISED [date] を記録します。 NOT ASSESSED は決して承認として扱いません。不足している入力を明示し、それを提示してゲートを再実行するか、NOT ASSESSED を記録します。 判定をアートバイブルのステータスヘッダーに記録します。 > **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date] / NOT ASSESSED [date] — [missing input]

---

フェーズ 6：終了

まず、この実行で作成しなかった9つのセクションをそれぞれ挙げ、その理由（選択したスコープ外、またはすでに完了済み）を説明します。例：「この実行では作成しませんでした：セクション5～9（選択したスコープ外。standardでは1～4が必要です）。」 セクション4の後に終了した実行が、完成したアートバイブルのように見えてはいけません。

次のステップを提示する前に、プロジェクトの状態を確認します。

• design/gdd/systems-index.md は存在しますか？ → map-systems は完了済みです。この選択肢はスキップします。
• エンジンは設定済みですか？ project.yaml に engine.name が存在するか、.claude/docs/technical-preferences.md の Engine フィールドが設定済み（[TO BE CONFIGURED] ではない）かを確認します。→ setup-engine は完了済みです。この選択肢はスキップします。
• design/gdd/ に *.md ファイルはありますか？ → design-system は実行済みです。この選択肢はスキップします。
• design/gdd/gdd-cross-review-*.md は存在しますか？ → review-all-gdds は完了済みです。
• GDD は存在しますか（上記を確認）？ → /consistency-check オプションを含めます。

次のステップには AskUserQuestion を使用します。上記の状態確認に基づき、実際に次のステップとなる選択肢のみを含めます。

workflow: minimal の場合、選択肢は /create-stories（ストーリーがまだない場合）または /dev-story [next story] と「ここで終了」です。以下の GDD／アーキテクチャの選択肢は standard／full のみです。

選択肢 — すでに完了しているものは含めません：

• [_] /map-systems を実行 — GDD を書く前に、コンセプトをシステムに分解する（systems-index.md が存在する場合はスキップ）
• [_] /setup-engine を実行 — エンジンを設定する（エンジン設定後にアセットの基準を見直す必要がある場合があります）（エンジン設定済みの場合はスキップ）
• [_] /design-system を実行 — 最初の GDD を作成する（GDD が1つでも存在する場合はスキップ）
• [_] /review-all-gdds を実行 — GDD 間の整合性を確認する（Technical Setup ゲートの前に必須）（gdd-cross-review-*.md が存在する場合はスキップ）
• [_] /asset-spec を実行 — 承認済み GDD から、アセットごとのビジュアル仕様と AI 生成プロンプトを作成する（GDD が存在する場合に含める）
• [_] /consistency-check を実行 — 既存の GDD をアートバイブルと照合し、ビジュアル方針の矛盾を確認する（GDD が存在する場合に含める）
• [_] /create-architecture を実行 — マスターアーキテクチャ文書を作成する（Technical Setup の次のステップ）
• [_] ここで終了

含める選択肢にのみ A、B、C…の文字を割り当てます。パイプラインを最も論理的に前進させる選択肢に「（推奨）」を付けます。

必ず含めてください（standard／full のみ）：アートバイブル完成後の有効な次のステップとして、/create-architecture と「ここで終了」を常に選択肢に含めます。

---

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

collaborative モード（デフォルト）に適用されます。 guided モードと autonomous モードについては、.claude/docs/automation-modes.md を参照してください。以下のルールは collaborative モードで必要な動作を定めるものであり、すべてのモードに共通する動作ではありません。

すべてのセクションで、次の順序に従います。質問 → 選択肢 → 決定 → 下書き（アートディレクターエージェントが作成）→ 承認 → ファイルに書き込む

• セクションの下書きを自分で作成してはいけません。各セクションの内容は、必ず該当する専門エージェントから取得します。1回の委任で複数のセクションを扱うことはできます（2～4は同じ呼び出し、5～6も同様）が、エージェントではなくオーケストレーター自身の判断でセクションを書いてはいけません。
• 承認後、各セクションをすぐにファイルへ書き込みます。書き込みや承認をまとめてはいけません。まとめられるのは委任呼び出しのみです。ユーザーは引き続き、1セクションずつ内容を確認し、承認し、確定します。
• エージェント間の意見の相違はすべてユーザーに提示します。アートディレクターとテクニカルアーティスト間の対立を、黙って解決してはいけません。
• アートバイブルは制約文書です。ビジュアルの一貫性と引き換えに、今後の判断を制限します。どのセクションも、解決策の範囲を有意義に絞り込むものにします。

---

次の推奨手順

アートバイブルの承認後：

• /map-systems を実行して、GDD の作成前にコンセプトをゲームシステムに分解します
• エンジンがまだ設定されていない場合は、/setup-engine を実行します（エンジンの選択後にアセットの標準を見直す必要がある場合があります）
• /design-system [first-system] を実行して、システムごとの GDD の作成を開始します
• GDD が作成されたら、/consistency-check を実行して、アートバイブルのビジュアルルールに照らして検証します
• /create-architecture を実行して、マスターアーキテクチャ文書を作成します