map-systems

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

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

システムをマッピングする

このスキルが呼び出された場合：

引数を解析する

2 つのモードがあります。

• 引数なし：/map-systems — システムインデックスを作成または更新するため、分解ワークフロー（フェーズ 1～5）全体を実行します。
• next：/map-systems next — インデックスから設計されていないシステムのうち優先度が最も高いものを選び、/design-system（フェーズ 6）に引き継ぎます。

完全なチェックパターンについては .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 により設定）では、各システムを 1 行で説明します。balanced では、各システムの簡潔な段落と依存関係の注記を記載します（rigor: standard）。thorough では、システムごとの詳細な根拠と関係性の分析を記載します。作成するすべてのセクションにこの設定を適用してください。

システムごとの説明文の記載場所。 templates/systems-index.md の Systems Enumeration は、説明列のない固定列テーブルです。そのため、balanced と thorough では、説明文は ## Overview に記載します。balanced では各システムにつき短い段落を 1 つ、thorough ではそれに加えて関係性の分析を記載します。また、## Dependency Map の各層の注記にも記載します。一覧テーブルに列を追加しないでください。これは .claude/docs/templates/systems-index.md で定められた固定の契約であり、その利用側（/design-system §6 および §7、/create-epics）は定義済みの列を前提にしています。列の拡張はフォーマット上の選択ではなく、スキーマの変更です。

利用側が実際に読み取る方法。 このテーブルを位置で解析するものはありません。systems-index.md に言及する 2 つのスクリプト（gdd-structure-check.sh:51、review-scope.sh:40）は、case 文でファイル名により一致させているだけで、列は一切解析しません。2 つのスキルは**Category 列を名前で**参照します（design-system:229、:780）。したがって、名前を変更したり削除したりしてはならない列は Category であり、すべての利用側がテンプレートで定義された列のセットを前提としているため、テーブルは固定の契約として維持されます。 terse では、テーブルと簡潔な ## Overview の段落 1 つが出力のすべてです。

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

• full / standard — /design-system の前に必須です（システムごとの GDD を作成する前に、システムをマッピングする必要があります）。
• minimal — 必須ではありません（ゲーム概要がシステムインデックスの代わりになります）。任意で実行することもできます。

---

フェーズ 1：コンセプトを読む（必須コンテキスト）

ゲームのコンセプトと、既存のデザイン資料を読みます。これらは、システムを分解するための素材になります。ドキュメントはセクションごとに読みます。Grep ツール（パターン ^#、コンテンツモード）で必要な見出しを探し、offset と limit を指定して該当範囲を Read します。

必須：

• design/gdd/game-concept.md を読みます（minimal の場合は、代わりに design/game-brief.md を読みます）。どちらも見つからない場合は、明確なメッセージを表示して失敗します：

  "No game concept found. Run /brainstorm first to create one, then come back to decompose it into systems."

任意（存在する場合に読みます）：

• design/gdd/game-pillars.md を読みます。柱となる要素が優先順位とスコープを左右します。
• design/gdd/systems-index.md を読みます。存在する場合は、途中から再開します（最初から作り直さず、更新します）。
• design/gdd/*.md を Glob し、既存のシステム GDD を確認します。

システムインデックスがすでに存在する場合：

• 内容を読み、現在の状況をユーザーに提示します。
• AskUserQuestion を使って、次のように質問します： "The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?"
  • 選択肢："Update the index with new systems"、"Design the next undesigned system"、 "Review and revise priorities"

---

フェーズ 2：システムの洗い出し（協働）

ゲームに必要なシステムを抽出して特定します。これはこのスキルの創造的な中核です。コンセプトドキュメントにはすべてのシステムが明記されているとは限らないため、人間の判断が必要です。

ステップ 2a：明示されたシステムを抽出する

ゲームコンセプトを確認し、直接言及されているシステムやメカニクスを洗い出します：

• Core Mechanics セクション（最も明示的）
• Core Loop セクション（各ループ階層を動かすシステムが示唆されています）
• Technical Considerations セクション（ネットワーク、プロシージャル生成など）
• MVP Definition セクション（必須機能＝必須システム）

ステップ 2b：暗黙のシステムを特定する

明示されたシステムごとに、それが示唆する隠れたシステムを特定します。ゲームには、コンセプトドキュメントに記載されている以上のシステムが必ず必要です。次の推論パターンを使います：

• 「インベントリ」からは、アイテムデータベース、装備スロット、重量／容量ルール、インベントリ UI、セーブ／ロード用のアイテムシリアライズが示唆されます。
• 「戦闘」からは、ダメージ計算、体力システム、ヒット判定、状態異常、敵 AI、戦闘 UI（体力バー、ダメージ数値）、死亡／リスポーンが示唆されます。
• 「オープンワールド」からは、ストリーミング／チャンク化、LOD システム、ファストトラベル、マップ／ミニマップ、注目地点の追跡、ワールド状態の永続化が示唆されます。
• 「マルチプレイヤー」からは、ネットワークレイヤー、ロビー／マッチメイキング、状態同期、チート対策、ネットワーク UI（ping、プレイヤーリスト）が示唆されます。
• 「クラフト」からは、レシピデータベース、素材収集、クラフト UI、成功／失敗のメカニクス、レシピの発見／習得が示唆されます。
• 「ダイアログ」からは、ダイアログツリーシステム、ダイアログ UI、選択肢の追跡、NPC 状態管理、ローカライズ用フックが示唆されます。
• 「進行」からは、XP システム、レベルアップのメカニクス、スキルツリー、アンロック状況の追跡、進行状況 UI、進行状況のセーブデータが示唆されます。

各暗黙のシステムが必要な理由を、例を挙げて会話テキストで説明します。

ステップ 2c：ユーザーに確認する

洗い出したシステムをカテゴリ別に整理して提示します。各システムについて、次の項目を示します：

• 名前
• カテゴリ
• 簡単な説明（1 文）
• 明示的（コンセプトに記載）か、暗黙的（推論による）か

次に AskUserQuestion を使って、フィードバックを集めます：

• 「このリストに不足しているシステムはありますか？」
• 「これらの中で、統合または分割すべきものはありますか？」
• 「このゲームには不要なシステムがリストに含まれていますか？」

collaborative の場合 — ユーザーが洗い出し結果を承認するまで繰り返します。 guided の場合 — 一度だけ質問し、回答を反映して先に進みます。繰り返しません。 autonomous の場合 — 質問はしません。洗い出したシステムと、推論で特定したシステムを log_decision で記録して先に進みます。

---

フェーズ 3：依存関係のマッピング（協働）

各システムについて、依存先を特定します。あるシステムが別のシステムの存在なしには機能できない場合、そのシステムに依存していると判断します。

ステップ 3a：依存関係をマッピングする

各システムについて、依存関係を列挙します。次の依存関係の判断基準を使用します。

• 入出力の依存関係：システム A が、システム B に必要なデータを生成する
• 構造上の依存関係：システム A が、システム B の組み込み先となるフレームワークを提供する
• UI の依存関係：各ゲームプレイシステムには対応する UI システムがあり、その UI システムはゲームプレイシステムに依存する（ただし、UI はゲームプレイシステムの設計後に設計します）

ステップ 3b：依存関係の順序で並べ替える

システムを次のレイヤーに整理します。

1. 基盤：依存関係がないシステム（最初に設計・構築します）
2. コア：基盤システムのみに依存するシステム
3. 機能：コアシステムに依存するシステム
4. プレゼンテーション：ゲームプレイシステムを包む UI およびフィードバックシステム
5. 仕上げ：メタシステム、チュートリアル、分析、アクセシビリティ

ステップ 3c：循環依存関係を検出する

依存関係グラフに循環がないか確認します。見つかった場合は、次のようにします。

• ユーザーに明示する
• 解決策を提案する（インターフェースの抽象化、同時設計、2 つのシステム間に契約を定義して循環を解消する）

ステップ 3d：ユーザーに提示する

依存関係マップをレイヤーごとのリストとして表示します。次の項目を明示します。

• 循環依存関係
• 「ボトルネック」となるシステム（多くのシステムが依存するため、リスクが高い）
• 依存先がないシステム（末端ノード。リスクが低く、後から設計できます）

AskUserQuestion を使用して、次のように尋ねます：「この依存関係の順序でよさそうですか？ 不足している依存関係や、削除すべき依存関係はありますか？」

レビュー モードの確認 — TD-SYSTEM-BOUNDARY を起動する前に適用します。

• solo → スキップします。次のように記録します：「TD-SYSTEM-BOUNDARY をスキップしました — Solo モードです。」優先度の割り当てに進みます。
• lean → スキップします（PHASE-GATE ではありません）。次のように記録します：「TD-SYSTEM-BOUNDARY をスキップしました — Lean モードです。」優先度の割り当てに進みます。
• full → 通常どおり起動します。

依存関係のマッピングが承認されたら、優先度の割り当てに進む前に、ゲート TD-SYSTEM-BOUNDARY（.claude/docs/director-gates/td-system-boundary.md）を使用して、Agent 経由で technical-director を起動します。

次の内容を渡します：依存関係グラフ（各システム → 依存先）、レイヤーの割り当て、ボトルネックとなるシステム、循環依存関係がある場合はその解決策。

評価結果を提示します。REJECT の場合は、ユーザーとともにシステム境界を見直し、修正版の依存関係マップを提示してから、優先度の割り当てに進みます。CONCERNS の場合は、システム一覧にインラインで記録して続行します。NOT ASSESSED [missing input] の場合、これは APPROVE ではありません。不足しているものを明示して補い、ゲートを再実行するか、インデックスのドラフトに TD-SYSTEM-BOUNDARY: NOT ASSESSED — [input] と記録して続行します。

---

フェーズ 4：優先度の割り当て（協働）

各システムがどのマイルストーンで必要になるかに基づいて、優先度ティアを割り当てます。

ステップ 4a：コンセプトに基づく自動割り当て

初期割り当てには、次の判断基準を使用します。

• MVP：コンセプトの「MVP に必要」セクションに記載されたシステムと、それらが依存する基盤レイヤーのシステム
• 垂直スライス：1 つのエリアで完全な体験を実現するために必要なシステム
• アルファ：残りのすべてのゲームプレイシステム
• 完全版：仕上げ、メタ、あると便利なシステム

Step 4b: ユーザーによるレビュー

優先度の割り当てを表にして提示します。各ティアについて、システムをそのティアに割り当てた理由を説明します。

AskUserQuestion を使って、次のように質問します。「この優先度の割り当ては、あなたのビジョンに合っていますか？ 優先度を上げる、または下げるべきシステムはありますか？」

会話の中で理由を説明します。「[system] を MVP に含めたのは、コアループに必要だからです。[system] がなければ、30 秒のループは機能しません。」

理由の書き方 — これは、記載する列ではなく、伝える内容を規定するものです。どちらの表にも Why 列はありません。Systems Enumeration の列は # / Name / Category / Priority / Status / Design Doc / Depends On、Recommended Design Order の列は Order / System / Priority / Layer / Agent(s) / Est. Effort です。理由は前述の会話で説明し、セッション後もユーザーに見せておくべき内容は、インデックスの ## Overview 段落に記載します。理由の列を追加してはいけません。

技術的な必然性とプレイヤー体験の観点を組み合わせます。「ダメージシステムにはダメージ計算が必要です」のような技術的な説明だけでは、そのシステムがプレイヤーの感じ方に直接影響する場合、十分ではありません。適切な理由では、両方に触れ、支えるピラーを明記します。

• 「コアループに必須です。これがないと、プレイヤーの主要な選択に結果が伴いません（Pillar [N]: [pillar name]）」
• 「ここで [system] の個性が確立されます。このシステム内のステータス定義によって、[the sibling system] との違いが感じられるようになります」
• 「以降のあらゆる経済上の判断の基盤です。その上に成り立つ選択が意味を持つには、まずプレイヤーがコストを理解する必要があります」

角括弧内は、このプロジェクトの内容で埋めてください。 角括弧で示された箇所は 飾りではありません。他のゲームの実例からコピーした理由には、そのゲームの用語が含まれており、このプロジェクトのものではありません。

レビュー方式の確認 — PR-SCOPE を起動する前に適用します。

• solo → スキップします。次のように記録します。「PR-SCOPE skipped — Solo mode。」Step 4c に進みます。
• lean → スキップします（PHASE-GATE ではありません）。次のように記録します。「PR-SCOPE skipped — Lean mode。」Step 4c に進みます。
• full → 通常どおり起動します。

優先度の承認後、インデックスを作成する前に、PR-SCOPE ゲート（.claude/docs/director-gates/pr-scope.md）を使って Agent 経由で producer を起動してください。

インデックスからゲートの入力項目を渡します。ビジョンの全スコープ（インデックス内のすべてのシステム）、MVP の定義（MVP ティアのシステム）、スコープティア（マイルストーンの各ティアに含まれるシステム数と推定実装量 — システム数 × 平均複雑度）、タイムラインの見積もりとして記載されたプロジェクトのスケジュール、チーム規模を渡します。

評価結果を提示します。PR-SCOPE の回答は REALISTIC / OPTIMISTIC / UNREALISTIC です。 UNREALISTIC の場合、インデックスを作成する前に優先度のティア割り当てを見直すか、ユーザーに確認します。OPTIMISTIC の場合、producer が提案した調整内容を示し、インデックスの作成前にそれらをティアに適用するかユーザーに確認します。ユーザーが適用しない場合は、調整内容を記録して続行します。NOT ASSESSED [missing input] の場合（チーム規模やタイムラインが不足していることがよくあります）、REALISTIC とはみなさず、不足している情報を明記します。そのうえで情報を補ってゲートを再実行するか、インデックスのドラフトに PR-SCOPE: NOT ASSESSED — [input] と記録して続行します。

Step 4c: 設計順序を決定する

依存関係による並べ替えと優先度ティアを組み合わせ、最終的な設計順序を決定します。

1. MVP Foundation システムを最初に
2. MVP Core システムを次に
3. MVP Feature システムをその次に
4. Vertical Slice Foundation/Core システム
5. …以下同様

これは、チームが GDD を作成する順序です。

---

Phase 5: システムインデックスの作成（書き込み）

Step 5a: ドキュメントのドラフトを作成する

.claude/docs/templates/systems-index.md のテンプレートを使用し、Phases 2-4 のデータをすべてシステムインデックスに記入します。

• 列挙表に記入する
• 依存関係マップに記入する
• 推奨設計順序に記入する
• 高リスクのシステムに記入する
• 進捗トラッカーに記入する（GDD がすでに存在する場合を除き、最初はすべてのシステムを「Not Started」にする）

Step 5b: 承認

ドキュメントの概要を提示します。

• カテゴリ別のシステム総数
• MVP システム数
• デザイン順の最初の 3 つのシステム
• 高リスク項目

automation: collaborative の場合 — 「システムインデックスを design/gdd/systems-index.md に書き込んでもよいですか？」と尋ねます。承認を待ちます。「yes」の後にのみファイルを書き込みます。

automation: guided の場合 — .claude/docs/automation-modes.md では新規ファイルに対して guided が「書き込んでもよいですか？」と尋ねる設定になっているため、新しいインデックスについては同じ質問をします。インデックスがすでに存在する場合は、上記の概要と保存先（design/gdd/systems-index.md）を提示し、明示的な「yes」を待たずに更新を書き込みます。その後、何を書き込んだかを伝えます。

レビューモードの確認 — CD-SYSTEMS を起動する前に適用します。

• solo → スキップします。次のように記録します。「CD-SYSTEMS をスキップ — Solo モード。」Step 5c に進みます。
• lean → スキップします（PHASE-GATE ではありません）。次のように記録します。「CD-SYSTEMS をスキップ — Lean モード。」Step 5c に進みます。
• full → 通常どおり起動します。

システムインデックスを書き込んだ後、ゲート CD-SYSTEMS（.claude/docs/director-gates/cd-systems.md）を使用して Agent 経由で creative-director を起動します。

以下を渡します。システムインデックスのパス、ゲームの柱と中核となるファンタジー — design/gdd/game-concept.md から取得します。minimal の場合は、柱のない design/game-brief.md のピッチと「どのように感じるか」の行を使用します。すべての優先度ティア（MVP / Vertical Slice / Alpha / Full Vision）の割り当て、高リスクシステムと依存関係マップのボトルネックシステム。

評価結果を提示します。REJECT の場合は、GDD の作成を始める前に、ユーザーとシステム構成を見直します。CONCERNS の場合は、その内容を示し、AskUserQuestion を使って Revise the system set / Accept — record them in the index / Discuss further を選択肢として提示します。Revise の場合は、影響を受けるシステムをユーザーと再検討し、インデックスを書き直す前に改めて確認します。Accept の場合 — この選択肢名自体が編集内容を示しているため、選択された時点で確認とみなします — インデックスの ## Priority Tiers テーブルの直下に、適用されるティアを明記した > **Creative Director Note** を記録します。例：> **Creative Director Note** (MVP): …。 templates/systems-index.md には Priority Tiers の定義テーブルがあり、ティアごとのセクションはありません。そのため、書き込むべき「ティアセクションの先頭」はありません — 執筆者にその場所を指示しないでください。NOT ASSESSED [missing input] の場合は APPROVE ではありません（.claude/docs/director-gates.md）。不足していたものを明示し、それを補ってゲートを再実行するか、同じ場所に > **Creative Director Note**: CD-SYSTEMS NOT ASSESSED — [input] を記録する前に確認します。

Step 5c: セッション状態を更新

書き込み後、production/session-state/active.md が存在しない場合は作成し、以下の内容で更新します。

• Task: Systems decomposition
• Status: Systems index created
• File: design/gdd/systems-index.md
• Next: Design individual system GDDs

判定：COMPLETE — システムインデックスを design/gdd/systems-index.md に書き込みました。 ユーザーが承認しなかった場合：判定：BLOCKED — ユーザーは書き込みを承認しませんでした。

---

Phase 6: 個別システムの設計（/design-system への引き継ぎ）

このフェーズは、次の場合に開始します。

• インデックスの作成後、ユーザーがシステム設計に「yes」と答えた場合
• ユーザーが /map-systems [system-name] を実行した場合
• ユーザーが /map-systems next を実行した場合

Step 6a: システムを選択

• システム名が指定された場合は、システムインデックスから見つけます
• next が使われた場合は、デザイン順に従って、優先度が最も高い未設計のシステムを選びます
• ユーザーがインデックスの作成を終えた直後の場合は、次のように尋ねます。 「個別システムの設計を今すぐ始めますか？デザイン順で最初のシステムは [name] です。それとも、ここでいったん終了して後で再開しますか？」

「[system-name] の設計を今すぐ始める」「別のシステムを選ぶ」「ここで終了する」のどれにするかを AskUserQuestion で尋ねます。

ステップ 6b：/design-system に引き継ぐ

システムを選択したら、/design-system [system-name] スキルを呼び出します。

/design-system スキルが、GDD 作成プロセス全体を担当します。

• ゲームのコンセプト、システムインデックス、依存関係にある GDD からコンテキストを収集します
• すぐにファイルの骨組みを作成します
• 必須の 8 セクションを一度に 1 つずつ進めます（協調的かつ段階的に）
• 既存のドキュメントを相互参照して矛盾を防ぎます
• ドメインの専門知識を得るため、専門エージェントに引き継ぎます
• 承認されたセクションをその都度ファイルに書き込みます
• 完了後に /design-review を実行します
• システムインデックスを更新します

ここで /design-system のワークフローを重複して実行しないでください。 このスキルはシステムの インデックスを担当し、/design-system は個々のシステムの GDD を担当します。

ステップ 6c：続行するか終了する

/design-system の完了後、AskUserQuestion を使用します。

• 「次のシステム（[next system name]）に進みますか？」
• 「別のシステムを選びますか？」
• 「このセッションはここで終了しますか？」

続行する場合は、ステップ 6a に戻ります。

---

フェーズ 7：次のステップを提案する

システムインデックスの作成後（または一部のシステムの設計後）、AskUserQuestion を使用して次のアクションを提示します。

• 「システムインデックスを作成しました。次は何をしますか？」
  • [A] GDD の設計を開始する — /design-system [first-system-in-order] を実行
  • [B] /gate-check systems-design を実行する — Concept → Systems Design のゲート。project.stage がまだ Concept の場合にのみ提示
  • [C] /gate-check technical-setup を実行する — MVP のシステムに GDD が揃った後の、Systems Design → Technical Setup のゲート
  • [D] このセッションはここで終了する

ゲートチェックの選択肢（[C]）も覚えておく価値があります：/gate-check technical-setup は、Systems Design フェーズで必須の成果物が存在することを確認し、アーキテクチャを確定する前にフェーズゲートのディレクターを実行します。CD-SYSTEMS と TD-SYSTEM-BOUNDARY はこのスキル独自のゲートであり、ここで full レビューモードを使って実行されます。/gate-check では実行されません。

個々の GDD が完了した後：

• 「新しいセッションで /design-review design/gdd/[system].md を実行して品質を検証します」
• 「すべての MVP GDD が完成したら /gate-check technical-setup を実行します」

---

協調プロトコル

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

このスキルは、すべてのフェーズで協調的な設計原則に従います。

1. すべてのステップで 質問 -> 選択肢 -> 決定 -> 下書き -> 承認 の順に進めます
2. すべての判断ポイントで AskUserQuestion を使用します（説明 -> パターンの記録）：
   • フェーズ 2：「不足しているシステムはありますか？統合しますか、分割しますか？」
   • フェーズ 3：「依存関係の順序は正しいですか？」
   • フェーズ 4：「優先度の割り当ては、あなたのビジョンに合っていますか？」
   • フェーズ 5：「システムインデックスを書き込んでもよいですか？」
   • フェーズ 6：「設計を開始しますか、別のものを選びますか、それとも終了しますか？」と確認し、その後 /design-system に引き継ぎます
3. ファイルを書き込む前に、毎回「[filepath] に書き込んでもよいですか？」と確認します
4. 段階的な書き込み：各システムの設計後にシステムインデックスを更新します
5. 引き継ぎ：個々の GDD の作成は /design-system が担当し、段階的なセクションの書き込み、相互参照、デザインレビュー、インデックスの更新を行います
6. セッション状態の更新：各マイルストーン（インデックスの作成、システムの設計、優先度の変更）後に production/session-state/active.md に書き込みます

システムの一覧全体を自動生成し、レビューなしで書き込んではいけません。 ユーザーの確認なしにシステムの設計を開始してはいけません。 ユーザーが検証できるよう、必ず列挙結果、依存関係、優先度を提示してください。

コンテキストウィンドウへの注意

コンテキストがいずれかの時点で 70% に達するか、それを超えた場合は、次のお知らせを追加します。

コンテキストが上限に近づいています（≥70%）。 システムインデックスは design/gdd/systems-index.md に保存されています。個々の GDD の設計を続けるには、新しい Claude Code セッションを開き、 /map-systems next を実行して中断したところから再開してください。

推奨される次のステップ

• /design-system [first-system-in-order] を実行して、最初の GDD を作成します（インデックスの設計順を使用）
• /map-systems next を実行すると、未設計のシステムのうち優先度が最も高いものが常に自動的に選択されます
• 各 GDD の作成後、新しいセッションで /design-review design/gdd/[system].md を実行します
• すべての MVP GDD の作成とレビューが完了したら、/gate-check technical-setup を実行します