cube-wizard

Cube Wizard

MTG キューブをゼロから作成（よく知られたリファレンスキューブをコピーしてカスタマイズ）したり、既存のキューブを調整したりできます。キューブとは、ドラフト用に厳選されたカードプールで、通常は 360～720 枚のカードで構成されます。デッキとは異なり、バランスはコレクション全体で決まります。アーキタイプのドラフト可能性、色の組み合わせごとのシグナル密度、マナ基盤の密度、プール全体のマナカーブなどです。すべての推奨は、Scryfall の実際のカードのオラクルテキストに基づいている必要があります。トレーニングデータを使ってはいけません。

このスキルには 2 つのフェーズがあります。**フェーズ 1（キューブの取得）**では、ユーザーがキューブをどのように入手するかを決定します。既存のリストを解析する（パス A）か、リファレンスキューブをコピーする（パス B）かのいずれかです。どちらのパスでも、キューブ JSON とデータを取り込んだキャッシュを作成します。**フェーズ 2（調整）**では、キューブの入手経路にかかわらず、同じ 10 ステップのパイプラインを実行します。

鉄則

カードの能力を決して推測してはいけません。 カードの能力に言及する前に、ヘルパースクリプトを使ってオラクルテキストを確認してください。トレーニングデータはオラクルテキストではありません。

例外（アーキタイプのアイデア出しに限る）： フェーズ 1 のパス B におけるカスタマイズ意図のヒアリングで、ユーザーがアーキタイプやテーマを検討しているときは、トークン、サクリファイス、+1/+1 カウンターなどのテーマ名の提案にトレーニングデータを使ってもかまいません。ただし、キューブに提案するカードはすべて、ユーザーが採用する前に Scryfall のオラクルテキストで確認する必要があります。候補名をすべて JSON リストに書き出し、1 回の呼び出しでまとめて検索してください。

scryfall-lookup --batch <candidates.json> --bulk-data <bulk-path> --cache-dir <wd>/.cache

---

対応キューブ形式

形式	デフォルトサイズ	カードプール	レアリティフィルター	統率者プール	備考
vintage	540	エターナル全体	—	いいえ	パワーあり（Power 9 使用可）
unpowered	540	エターナル全体	—	いいえ	デフォルトでは Power 9 禁止
legacy	540	レガシーで使用可能	—	いいえ	レガシーの禁止カードリストを適用
modern	540	モダンで使用可能	—	いいえ	モダンの禁止カードリストを適用
pauper	540	エターナル全体	コモンのみ	いいえ	—
peasant	540	エターナル全体	コモン + アンコモン	いいえ	—
set	360	単一セット	—	いいえ	すべてのカードが同じセットの場合、自動検出
commander	540	統率者戦で使用可能	—	はい	専用の統率者パックを別途ドラフト
pdh	540	エターナル全体	コモン（メイン）	はい	統率者：アンコモン

形式は任意のメタデータであり、厳格な制約ではありません。 「猫と犬の部族キューブ」や「予算上限付きキューブ」も問題なく作成できます。レアリティや使用可否のフィルターが合う形式を選び、その上に制約を重ねてください。キューブ JSON の designer_intent ブロックに、ユーザー固有の目標を記録します。

---

進捗管理

開始前に TaskCreate リストを作成してください。 最初の質問でパスが決まるため、それに応じてタスクを作成します。

フェーズ 1：パス A（既存キューブの解析）

• キューブを取得／読み込み
• 正規化キューブ JSON に解析
• カードデータを取り込む

フェーズ 1：パス B（リファレンスキューブのコピー）

• ヒアリング
• リファレンスキューブの選択
• 取得 + 解析 + データ取り込み
• ベースラインの確認

フェーズ 2：調整（両方のパス）

1. ベースライン指標
2. デザイナーの意図を確認
3. バランスダッシュボード
4. アーキタイプの監査
5. パワーレベルの確認
6. 自己批判
7. 変更を提案
8. パックシミュレーション
9. 最終確定／エクスポート
10. 実戦プレイテスト（任意）

各項目に着手した時点で in_progress に、完了した時点で completed に更新してください。更新をまとめて行ってはいけません。

---

セットアップ（初回実行）

uv sync --directory <skill-install-dir>
download-mtgjson

2 回目以降の実行では、.venv が存在し、バルクデータが新しい場合（24h）、uv sync を省略します。

---

ツールに関する注意事項

人間が読める標準出力 + JSON サイドカー（重要）

すべてのキューブ CLI は、人間が読める短い概要を標準出力に出力し、完全な構造化出力をサイドカー JSON ファイルに書き込みます。末尾には Full JSON: <path> が付きます。この形式にしているのは、540 枚以上のカードを含むキューブ JSON をそのまま標準出力に流すと、コンテキストを圧迫するためです。

スクリプト間の連携には、パイプで JSON を渡すのではなく、ファイルパスを使います。 特定のフィールドが必要な場合は、Read と offset／limit を使ってサイドカーを必要な範囲だけ読み込んでください。後続のスクリプトが標準出力に完全なペイロードを必要とする場合に限り（まれです）、--json を渡してください。

JSON ファイルの書き込み

カード名を含む JSON ファイルには、Write ツールを使用してください。アポストロフィ （例：「Ashnod's Altar」）があると、ヒアドキュメントやインライン Python のシェルクォートが壊れます。 Write ツールの権限はセッション中キャッシュされますが、python3 -c "..." は毎回再確認を求めます。

一時ファイルのパス

セッション中は、次の安定したパスを再利用してください：/tmp/cube-cuts.json、 /tmp/cube-adds.json、/tmp/cube-candidates.json、/tmp/cube-themes.json。

/tmp のファイルはセッションをまたいで保持されます。セッション開始時に、再利用する予定の一時ファイルのパスを、最初に Write する前にそれぞれ Read してください。または、Write を順番に実行し、依存する Bash 呼び出しの前に成功を確認してください。Write(/tmp/foo.json) と /tmp/foo.json を読み取る Bash を同じメッセージでまとめて実行しないでください。

パスの要件

• 絶対パスのみを使用してください。 uv は作業ディレクトリをスキルのインストール先に変更するため、相対パスは誤ったルートを基準に解決されます。
• キャッシュディレクトリ： スキルのインストール先ではなく、常に <working-dir>/.cache を使用してください。
• 再ハイドレーション： キューブを編集した後は毎回、新しいキューブ JSON に対して scryfall-lookup --batch を再実行してください。ハイドレート済みキャッシュは SHA キーで管理されており、古いキャッシュは気づかないうちに古くなります。

CubeCobra からの取得に関する注意点

CubeCobra は一部のエンドポイントで通常の Python User-Agent に 403 を返します。cubecobra-fetch は web_fetch 経由で curl にフォールバックすることで、この問題を透過的に処理します。取得の優先順位は、cubeJSON（最も情報が豊富 — メインボード／メイビーボードの区分、デザイナーのタグ、カードごとのオーバーライド）→ CSV → プレーンなカードリストです。3 つすべての取得に失敗した場合、ユーザーは CubeCobra UI から手動でエクスポートし、そのファイルを parse-cube に渡せます。

バランスチェックは参考情報であり、合否判定ではありません

cube-balance は、従来の参照範囲（例：「除去密度 22～28%」）に照らした実測値を報告します。範囲外であっても、キューブが壊れていると判定するわけではありません。青単のキューブ、コンボキューブ、猫と犬の部族キューブは、従来の想定と異なっていても問題ありません。参照範囲は「一般的な目安」であり、「必須条件」ではないと考えてください。

参照範囲は、Riptide Lab と Star City Games の合意事項に加え、Lucky Paper の「キューブに何枚の土地を入れるべきか」の数値に基づいています。

cube-balance と archetype-audit の正規表現の適用範囲に関する警告

両ツールは、mtg_utils.theme_presets にある共通のプリセットライブラリ（PRESETS dict と get_preset(name) / matches(name, card) API）を使用します。各プリセットには、既知のカードに対する動作を固定するテストフィクスチャが含まれているため、更新によって動作が気づかないうちに後退することはありません。cube-balance の除去チェックは removal プリセットに委譲され、archetype-audit --preset <name> は名前でプリセットを読み込みます。

除去の検出には removal プリセット（破壊／追放／打ち消し／ダメージ／バウンス／格闘／-X）を使用します。参考指標としての用途に合わせ、寛容な設定になっており、誤検出は許容されます。密度に違和感がある場合は、次を実行して抜き取り確認してください：

card-search --bulk-data <path> --oracle "<your regex>" --color-identity <ci>

より細分化した除去密度を確認するには、幅広い removal に加えて、タイプ別のプリセットが 6 つあります：creature-removal、 artifact-removal、enchantment-removal、land-removal、 planeswalker-removal、universal-removal（Vindicate / Beast Within / Maelstrom Pulse / Nicol Bolas 系）。タイプ別プリセットは厳密で、カード名にそのタイプが明記されているカードに一致します。universal-removal は別枠です。アーティファクトに対応できるカードをすべて数えるには、artifact-removal と universal-removal を合算してください。注：同じカードが重複して一致することは想定されています（Lightning Bolt は「any target」の火力により、creature-removal と planeswalker-removal の両方に一致します）。

archetype-audit のテーマには、--preset <name>（ライブラリのプリセット、テスト済み）または --theme name=regex（独自設定、未検証）を使用できます。独自の正規表現の精度は、ユーザーが記述した正規表現の精度にそのまま依存します。

Canonical Cube JSON Schema

{
  "cube_format": "vintage|unpowered|legacy|modern|pauper|peasant|set|commander|pdh",
  "target_size": 540,
  "name": "Regular Cube",
  "drafters": 12,
  "pack_size": 15,
  "packs_per_drafter": 3,
  "source": "cubecobra:<id>",
  "cloned_at": "2026-04-18T12:34:56Z",
  "designer_intent": {
    "description": "<from CubeCobra overview>",
    "tags": ["unpowered", "vintage"],
    "stated_archetypes": [
      {"name": "tokens"},
      {"name": "graveyard",
       "members": ["reanimate", "self-mill", "graveyard-cast"]},
      {"name": "Boros Equipment", "regex": "equip|attach"}
    ]
  },
  "pack_templates": {},
  "balance_targets_override": {},
  "commander_pool": [
    {"name": "Atraxa, Praetors' Voice", "quantity": 1, "scryfall_id": "..."}
  ],
  "cards": [
    {"name": "Lightning Bolt", "quantity": 1,
     "cube_color": "R", "cube_cmc": 1.0,
     "tags": ["burn"], "scryfall_id": "..."}
  ],
  "total_cards": 540
}

各エントリは、次の3つの形式のいずれかです。

• {"name": NAME} — プリセット参照です。NAME は theme_presets.PRESETS のキーである必要があります（カタログ全体は archetype-audit --list-presets を実行すると確認できます）。
• {"name": NAME, "members": [PRESET, ...]} — アーキタイプグループです。NAME は包括的なラベルで、各 members エントリは既知のプリセットである必要があります。 stated_archetypes を読み取るツールは、構成する各プリセットを追跡しながら、 グループを1つの単位として報告します。
• {"name": NAME, "regex": PATTERN} — カスタムマッチャーです（レガシーのテーマ、または プリセットライブラリではカバーされないキューブ固有のテーマ）。

すべてのキューブ CLI がこの形式を受け付けます。ハイドレート済みキャッシュは <working-dir>/.cache/<sha>.json に保存され、SHA をキーとするため、再ハイドレートは冪等です。

---

判断表

タスク	ツール
CubeCobra のキューブを取得する	cubecobra-fetch <id-or-url> --output-dir <wd>
キューブリスト／CSV／JSON を解析する	parse-cube <path> --cube-format <fmt> --output <wd>/cube.json
カードデータをハイドレートする	scryfall-lookup --batch <cube.json> --bulk-data <path> --cache-dir <wd>/.cache
キューブの主要指標	cube-stats <cube.json> <hyd.json>
バランスダッシュボード	cube-balance <cube.json> <hyd.json> [--check <name>]
フォーマット適正性 + レアリティ監査	cube-legality-audit <cube.json> <hyd.json>
アーキタイプの検証	archetype-audit <cube.json> <hyd.json> --theme name=regex
プリセットライブラリを使ったアーキタイプの検証	archetype-audit <cube.json> <hyd.json> --preset <name>（複数回指定可能。--list-presets を参照）
利用可能なプリセットテーマを一覧表示する	archetype-audit --list-presets
各テーマに一致したカードを表示する	任意の archetype-audit 呼び出しに --show-matches を追加
ブリッジカード	2つ以上のテーマが指定されている場合、archetype-audit の出力に含まれます
キューブのリビジョンを比較する	cube-diff <old.json> <new.json> [--old-hydrated <h> --new-hydrated <h> --metrics]
オープニングパックをサンプルする	pack-simulate <cube.json> <hyd.json> --seed N --pack-size 15
ドラフト適性のストレステスト	pack-simulate ... --simulate-drafts 100
候補カードを検索する	card-search --bulk-data <path> --oracle "<regex>" --color-identity <ci>
キューブの予算を確認する	price-check <cube.json> --bulk-data <path>
意図しない無限コンボを見つける	combo-search <cube.json>
CubeCobra CSV にエクスポートする	export-cube <cube.json> --format csv --output <wd>/cube.csv
MTG 総合ルールを参照する	rules-lookup --rule <n> / --term <keyword> / --grep "<regex>"
Scryfall のカード別裁定を取得する	rulings-lookup --card "<name>" --bulk-data <path>
より深いルールの質問（アーキタイプの適法性、キーワードの相互作用）	Skill ツール経由で rules-lawyer スキルを呼び出す

ルール専門家

キューブの設計では、ときおりルールに関する疑問が生じます。「このコンボは本当にこのフォーマットで機能するのか？」「この誘発型能力は強制なのか？」「この常在型能力はレイヤーシステムでどう処理されるのか？」といった疑問です。単純なキーワードや用語集に関する質問には rules-lookup --term <keyword> を実行してください。レイヤー、置換効果、複数のルールが関わる相互作用など、複雑な質問には、Skill ツール経由で rules-lawyer スキルを呼び出してください。このスキルは、関連する CR セクションを読み込んだサブエージェントへのエスカレーションを処理します。

最初の rules-lookup 呼び出しの前に、セッションごとに1回 download-rules --output-dir <working-dir> を実行してください（鮮度チェックは24時間で、download-mtgjson と同じ方式です）。

---

フェーズ 1：キューブの取得

最初の質問：「調整したい既存のキューブリストはありますか？それとも、よく知られたリファレンスをもとに新しいキューブを作成しますか？」

パス A：既存のキューブを解析する

1. キューブのリストを取得します。 次のいずれかを使います。
   • CubeCobra ID または URL → cubecobra-fetch <id> --output-dir <wd>
   • ローカルファイル（CubeCobra CSV、プレーンテキストなど）— そのまま使用します
2. 正規形式のキューブ JSON に解析します。

   parse-cube <wd>/<cube>.json --cube-format <fmt> --output <wd>/cube.json
   

   ユーザーが形式を指定していない場合、parse-cube は set キューブ（すべてのカードが同じセットコードを共有するキューブ）を自動検出し、それ以外は vintage をデフォルトとして使用します。
3. カードデータを補完します。

   scryfall-lookup --batch <wd>/cube.json --bulk-data <wd>/default-cards.json --cache-dir <wd>/.cache
   

4. 対象範囲を確認します。 cube.json.designer_intent.description と tags を確認します。これらはフェーズ 2 のパイプラインに必要なコンテキストを提供します。キューブに指定されたアーキタイプがある場合は、archetype-audit --from-cube を実行して、プリセットの参照とグループを直接処理します。プリセットライブラリで扱われないテーマについてのみ、正規表現クエリをユーザーに尋ねます。

パス B：参照キューブを複製する

1. ヒアリングします。 次の順に確認します。
   • キューブ形式（対応キューブ形式の表を参照）
   • 目標サイズ（360 ／ 450 ／ 540 ／ 630 ／ 720。デフォルトは形式に応じて設定）
   • ドラフト参加者数 ／ パックサイズ（デフォルトは cube_config.SIZE_TO_DRAFTERS に従います）
   • 参照キューブの選択：選択した形式に対応する cube_config.REFERENCE_CUBES のハードコードされた候補に加え、ユーザーが知っている任意のキューブを指定できる「CubeCobra URL を貼り付け」を提示します。AskUserQuestion を使用します（4 件の選択肢の上限を守り、メッセージ本文にすべての候補を列挙して、ユーザーが任意のものを選べるようにします）。
   • カスタマイズの意図（自由回答）：「この参照キューブから何を変更したいですか？ アーキタイプの追加、特定カードの除外、部族テーマ、予算上限などでしょうか？ それとも基本構成を調整するだけですか？」
   • 予算（任意）：紙版カードの USD 上限
   • 制限（任意）：速攻マナなし、無限コンボなし、部族の制約、単一セット、単色など
2. 取得、解析、データ補完を行います。 パス A と同じコマンドを、参照キューブの CubeCobra ID に対して実行します。
3. ベースラインを確認します。 変更前の参照キューブに対して cube-stats と cube-balance を実行します。カスタマイズを始める前に、開始点が意図に合っているかユーザーが確認できるよう、ベースラインを提示します。

---

フェーズ 2：調整パイプライン

キューブがパス A（既存のキューブ）由来かパス B（複製した参照キューブ）由来かにかかわらず、同じ 9 つの手順を適用します。TaskCreate を使って進捗を管理します。

手順 1：ベースライン指標

cube-stats <cube.json> <hyd.json>
cube-balance <cube.json> <hyd.json>

色の分布、マナカーブ、除去の密度、マナ基盤の調整密度、および統率者プールの構成（該当する場合）を記録します。これらは、手順 7 で影響を検証する際の変更前の状態です。

手順 2：デザイナーの意図を確認する

キューブに示されている意図を要約してユーザーに伝えます。

• 形式、サイズ、ドラフト参加者数
• CubeCobra の概要にあるデザイナーの説明（またはパス B のヒアリングで確認したカスタマイズの意図）
• 指定されたアーキタイプ（ある場合）
• 明示された制限

ユーザーに確認または修正を依頼します。手順 4 で使うため、確認内容を cube.json.designer_intent.stated_archetypes の項目（プリセット、グループ、またはカスタム正規表現の形式）に保存します。

手順 3：バランスダッシュボードと適正チェック

手順 1 ですでに算出済みです。各セクションをユーザーと確認し、「一般的な範囲外」の項目で意図的なものがあれば記録します（例：「このキューブをクリーチャー中心にしたいので、除去密度は低くしています」）。

また、ルールに基づく適正チェックも実行します。

cube-legality-audit <cube.json> <hyd.json>

cube-balance とは異なり、これは厳格な制約チェックです。エラーは形式ルール違反を示すため、公開前に修正する必要があります。チェック項目は次のとおりです。

• レアリティフィルター — 例：レアカードが含まれるパウパーキューブ（利用可能な場合は Scryfall の legalities.pauper を使用し、ペザントではデフォルト印刷版のレアリティを警告として使用します）。
• 適正キー — 例：モダンで使用できないカードが含まれるモダンキューブ。
• 禁止リスト — 例：unpowered キューブに含まれる Power 9 カード。
• 統率者プールのレアリティ — 例：PDH の統率者はアンコモンである必要があります。

error 重大度の違反はすべて修正が必要です（カードを入れ替えるか、キューブ形式を変更します）。warn 重大度の項目は手動で確認します（デフォルト印刷版のレアリティの差異、適正データの欠落など）。

Step 4: アーキタイプ監査

テーマがライブラリのプリセットに合致する場合は、正規表現を手書きする代わりに --preset <name> を優先してください。利用可能なカテゴリは次のとおりです。

• キーワード能力：飛行、警戒、トランプル、速攻、接死、絆魂、先制攻撃、二段攻撃、到達、威迫、防衛、瞬速、呪禁、破壊不能、護法、プロテクション、占術、諜報、続唱、フラッシュバック、キッカー、サイクリング、想起、忍術、賛美、果敢、反乱、調査、上陸、発掘、奇跡、ストーム、感染、毒性、探査、待機、不死、頑強、装備、切削。
• 除去（広義）：removal（包括的）、board-wipe。
• 種類別の除去：creature-removal、artifact-removal、 enchantment-removal、land-removal、planeswalker-removal、 universal-removal（Vindicate / Beast Within / Maelstrom Pulse）。
• 生け贄の強制（布告）：edict（包括的）、creature-edict、 artifact-edict、enchantment-edict、land-edict、 planeswalker-edict、universal-edict（対戦相手が選ぶ Vindicate 形式）。
• ターン操作：extra-turns、extra-combats、 extra-upkeeps — Obeka / Aurelia / Godo のアーキタイプの軸となる、「このステップをもう一度行う」報酬カード群です。
• 機能別：ライブラリートップ操作、セルフ切削、打ち消し呪文、バウンス、手札破壊、サーチ、トークン、生け贄手段、火力、リアニメイト、墓地からの回収、キャントリップ、ドロー、ライフ獲得、+1/+1 カウンター、ブリンク。

プリセットは既知のカードを使ってテストされており、cube-balance と共有されるため、セッション間で結果の一貫性が保たれます。archetype-audit --list-presets で全カタログを確認できます。各テーマに一致したカードを確認するには、--show-matches を追加してください。

archetype-audit <cube.json> <hyd.json> \
    --preset tokens \
    --preset reanimate \
    --preset counterspell \
    --show-matches

PDH キューブでは、--include-commanders を指定すると、メインプールのカードに加えて commander_pool のエントリーもテーマの密度に反映されます。デフォルトでは無効で、PDH 以外のキューブの既存の出力は変更されません。

一致するプリセットがないテーマには、--theme name=regex を使用してください。

• spells-matter=(instant|sorcery) you (control|cast)
• energy=gets? \{E\}
• counters=\+1/\+1 counter

archetype-audit <cube.json> <hyd.json> \
    --preset tokens \
    --theme "spells-matter=(instant|sorcery) you (control|cast)" \
    --theme "counters=\\+1/\\+1 counter"

出力には、テーマごとの密度、ギルドごとの密度、孤立したシグナル（1色にしか報酬カードがないテーマ）、ブリッジカード（複数のテーマを支えるカード — デザイン上、優先度の高い連結要素）が報告されます。

3～4枚未満のカードしかないテーマは、必ずユーザーと相談して終了してください — Lucky Paper の FAQ によると、アーキタイプをドラフト可能にするには「わずか3～4枚」のカードで足ります。このしきい値を下回る場合、それはアーキタイプではありません。

Step 5: パワーレベルのレビュー

確認項目は2つです。

1. 価格の外れ値（パワーの代替指標）：price-check <cube.json> --bulk-data <path> で、50ドル以上および100ドル以上の価格帯の外れ値カードを検出します。
2. 意図しない無限コンボ — キューブで最も注意すべきなのは、無関係なカードが2枚で無限コンボを形成し、ドラフトを歪めることです。

   combo-search <cube.json>
   

   combo-search はデッキを対象としますが、キューブの JSON でも問題なく動作します（どちらも cards[] の構造を共有しています）。検出されたコンボをユーザーと確認してください。

Step 6: 自己批評（必須ゲート）

deck-wizard の Step 8 のパターンに従い、提案役と異議を唱える役の2つの Agent 呼び出しを並行して実行します。異議を唱える役には、キューブ特有の失敗要因に焦点を当てたプロンプトを与えます。例：アーキタイプの枯渇（報酬カードを補充せずに支援カードを削る）、それによって生じる色バランスの崩れ、シグナルの希薄化（新しいカードがどのテーマも支援しない）、パワーの外れ値、マナ基盤の撹乱。

両方の Agent に次の情報を提示します。

• キューブの指定アーキタイプとデザイナーの意図
• 現在の cube-stats と cube-balance のベースライン
• 現在の archetype-audit によるテーマごとの密度
• 調整セッションで提案された削除・追加

Step 7: 変更を提案する

Write ツールを使って、カットを /tmp/cube-cuts.json に、追加を /tmp/cube-adds.json に書き込みます。カットと追加を適用してキューブ JSON を再生成し、再ハイドレートして、Phase 2 のメトリクスを再実行します。

cube-diff <old-cube.json> <new-cube.json> \
    --old-hydrated <old-hyd.json> --new-hydrated <new-hyd.json> --metrics

続行する前に、差分をユーザーと確認します。

一般的な入れ替え基準 — 診断シグナルに基づいてカットと追加を決めます：

• 除去密度が不適切（Step 3）：アーキタイプタグに基づいて、除去カードを入れ替えます。
• アーキタイプが LP の最小値を下回る（Step 4）：支援カードを追加するか、stated_archetypes グループを使って関連アーキタイプをまとめます。
• パワーの外れ値（Step 5）：ドラフトに歪みをもたらす場合は、価格フラグが付いたカードをカットします。combo-search で特定したコンボは、パーツのひとつをカットする必要がある場合があります。
• 色事故率が高い（カスタムフォーマットの Step 10 のプレイテストレポートから）：同じアーキタイプ内で、ダブルシンボルのカード（{C}{C}）をシングルシンボルの相当カードに置き換えます。card-search --oracle "<archetype pattern>" --color-identity <C> を使って候補を探し、各候補を scryfall-lookup で確認します。
• アーキタイプの成立率が 30% 未満（Step 10）：支援カードを 2～3 枚追加するか、キューブ JSON 内のアーキタイプのグループ定義を調整します。

入れ替え候補がキューブ内のカードと重複する場合（人気のある代替カードでよく発生します）、card-search により厳しいフィルターを指定して、代替候補を絞り込みます。確定する前に、すべての代替カードのマナ・コストを scryfall-lookup で確認してください。トレーニングデータのカード・コストだけを信用してはいけません。

Step 8: パックのシミュレーション

pack-simulate <new-cube.json> <new-hyd.json> --seed 1 --pack-size 15
pack-simulate <new-cube.json> <new-hyd.json> --seed 1 --pack-size 15 --simulate-drafts 100

いくつかの開封パックを目視で確認してから、100 パックの集計分布を確認します。カテゴリが著しく不足している場合や、色の分布に違和感がある場合は、Step 7 に戻ります。

Step 9: 最終調整／エクスポート

export-cube <new-cube.json> --format csv --output <wd>/<cube-id>-updated.csv

変更を反映するため、CubeCobra の 「Replace with CSV Import」 機能を使うよう案内を添えて、CSV をユーザーに渡します。

Step 10: 実地プレイテスト

実行するタイミング：

• 標準キューブ形式： 任意です。Step 1～9 の静的シグナルで大半の判断はカバーできるため、マッチアップのバランスを数値で確認したい場合は、ガントレット／ドラフトを実行します。
• 登録済みのシミュレーターモジュールがあるカスタム形式（つまり、フォーマット名が mtg_utils/_custom_format/__init__.py:FORMAT_REGISTRY のキーである場合）： 必須です。静的ツールではフォーマット固有の動きを把握できません。フォーマットの実際のルールに基づく色事故とアーキタイプの成立を診断できるのは、シミュレーターだけです。現在、レジストリにあるエントリは shared_library の 1 つです。
• シミュレーターモジュールがないカスタム形式： 続行する前に、モジュールの作成を提案します。その形式はまだシミュレーションされていないことをユーザーに伝え、フォーマットモジュールの契約（setup／run_turn／is_terminal と DEFAULT_PLAYERS／DEFAULT_TURNS／SUPPORTS_ARCHETYPES。_custom_format/shared_library.py が参考実装です）を示し、今すぐモジュールを追加するか、その制限を提案レポートに記載して Step 1～9 に基づいて進めるかを尋ねます。確認なしにモジュールを作成してはいけません。フォーマットのルールはトレーニングデータではなく、ユーザーから提示してもらう必要があります。

互いに補完する 2 つのシグナルがあります。実行する場合は両方を実行します。

ガントレット（マッチアップのバランス）：

playtest-gauntlet cube.json --hydrated cube-hydrated.json \
  --games-per-pair 100 --seed 1 --output playtest-gauntlet.json

ガントレットでテストするアーキタイプを選ぶ際の優先順位は 3 段階あります：

1. --gauntlet path/to/manifest.json — 明示的なオーバーライドファイル
2. cube.designer_intent.stated_archetypes — 値が設定されている場合、ガントレットは指定されたアーキタイプごとに1つのデッキを生成し、キューブの実際のカードプールから色と curve_target を自動推定します （アーキタイプごとのテーママッチャーが、色のアイデンティティとCMCに基づいてカードをカウントします）。特定のアーキタイプについて推定値を上書きするには、対応する stated_archetype エントリーに任意の gauntlet: ブロックを追加します。

   {
       "name": "Aristocrats",
       "members": ["sacrifice", "death-trigger"],
       "gauntlet": {"colors": ["B", "W"], "shape": "midrange",
                    "curve_target": {"2": 5, "3": 7, "4": 6}}
   }
   

   shape は aggro|midrange|control|combo のいずれかで、テーママッチに標準的なスコアリング事前分布を加えます。テーマに基づくスコアリングのみを使う場合は省略します。
3. フォールバック：stated_archetypes がない、または空の場合は、フォーマットごとのデフォルト設定 mtg_utils/data/gauntlets/<format>.json を使用します（標準の4つの形 — Mono-Red Aggro、Azorius Control、Golgari Midrange、Izzet Combo。それぞれに明示的な shape フィールドがあります）。

レポートは勝率の4×4マトリックスです（stated_archetypes に N 個のエントリーがある場合は N×N）。バランス状態から10pp以上離れている、60%超または40%未満のセルに注目してください。デフォルトの M=100 では二項分布の95%信頼区間が±10ppなので、10ppの差は統計的に意味があります。それより小さい差はノイズです。

ドラフト（ドラフトのバランス調整）：

playtest-draft cube.json --hydrated cube-hydrated.json \
  --pods 4 --players 8 --seed 1 --output playtest-draft.json

レポートでは、ドラフトした32個のデッキのゴールドフィッシュ結果を集計し、色事故率の平均、T4時点の土地枚数の平均、アーキタイプの分布、構築に失敗したデッキを示します。

**マナモデルに関する注意点：**デッキごとのゴールドフィッシュでは、土地と、Scryfall の produced_mana を持つ、唱えた非土地パーマネントすべて（マナ・アーティファクト、マナ・クリーチャー、Treasure／Gold／Eldrazi-Spawn の生成カードなど）を数えます。トークン生成カードは、その誘発や生け贄をシミュレーションせず、おおよそ1マナ／ターンの供給源として扱います。そのため、トークンによるマナ加速は概算で捉えられますが、正確ではありません。ドラフト結果を報告する際は、この点に触れてください。

結果の報告： playtest-gauntlet がバランスの偏りを検出した場合は、カードの入れ替えについて話し合う際にその結果を取り上げてください。ウィザードはプレイテストの結果からカードを自動で外しません。ユーザーが両方のレポートを確認して判断します。

**カスタムフォーマット：**キューブが、モジュールが FORMAT_REGISTRY に登録されている標準外フォーマット（現時点では shared_library）を対象とする場合は、playtest-gauntlet／playtest-draft の代わりに playtest-custom-format を使用します。フォーマットがレジストリにない場合は、続行する前に上記の「シミュレーターモジュールがないカスタムフォーマット」の手順に従ってください。

キューブに designer_intent.stated_archetypes（プリセット参照、および／または {name, members} 形式のアーキタイプグループ）が設定されている場合、--from-cube が自動的に取得します。

playtest-custom-format cube.json --hydrated cube-hydrated.json \
  --format-module shared_library --from-cube \
  --turns 10 --games 1000 --seed 0 --output report.json

その場で指定するアーキタイプリストの場合（またはキューブで宣言済みのアーキタイプに追加する場合）、--preset NAME（複数回指定可能）および／または --archetype-group NAME=PRESET1,PRESET2,... を渡して、アンブレラアーキタイプをインラインで宣言します。

playtest-custom-format cube.json --hydrated cube-hydrated.json \
  --format-module shared_library \
  --preset top-manipulation --preset removal --preset cantrip \
  --archetype-group graveyard=reanimate,flashback,graveyard-return,self-mill \
  --turns 10 --games 1000 --seed 0 --output report.json

シミュレーターは N ゲーム × T ターン × P プレイヤーを実行し、マーケットプレイスの動向とアーキタイプごとの組み立て状況を追跡します。戦闘やカードの解決全体はモデル化せず、各種発生率をレポートします。v1 で提供するのは --format-module shared_library のみです。フォーマットを追加するには、フォーマットごとに Python モジュールを1つ用意します。

レポートの読み取り方 — 2段階のシグナル。

常に利用可能（すべてのカスタムフォーマットモジュールがレポート）：

1. **色事故率。**シミュレーターはマナ・シンボル数を考慮したマナモデルを使用します（{U}{U} の支払いには、プールに U が含まれる任意の2マナではなく、実際に U マナが2点必要です）。発生率が高い場合、マナ・シンボルの負担が大きいことを示します。つまり、フォーマットの色マナ供給量に対して、1色のマナを複数点必要とするカードが多すぎます。調整のポイント：
   • ダブル・シンボルのカード（{U}{U} → {1}{U}）をシングル・シンボルの同等カードに置き換えます。通常、最も効果の大きい入れ替えです。
   • 同じ色の土地の比率を増やします（各色の2色土地を増やすか、そのフォーマットで使うゾーンに単色の基本土地を増やします）。
   • 候補を見つけるには、キューブのアーキタイプパターンに対して card-search --bulk-data <path> --oracle "<pattern>" を実行し、既存のカードより必要な色マナが少ないカードを探します。
2. アーキタイプごとの成立率。 実際のプレイで一緒に機能することがほとんどないアーキタイプは、成立率が約30％未満です。調整のポイント：
   • イネーブラーの密度を上げます（Lucky Paperでは最低3～4枚必要です。シミュレーターのK=4というしきい値もこれと一致しています）。
   • 複数のメカニズムから成るアーキタイプ（墓地＝リアニメイト＋フラッシュバック＋墓地からの回収＋セルフミル）では、stated_archetypes に --archetype-group または {name, members} エントリーを指定し、包括的なアーキタイプの実際の密度が見えるようにします。サブメカニズムのカードが4枚だと少なく見える一方、包括的なアーキタイプなら20枚で十分な密度がある場合があります。
   • 2つ以上のアーキタイプにまたがるブリッジカードは、カード枠を増やさずに包括的なアーキタイプの成立率を高めます。archetype-audit の bridge-cards 出力で追跡します。

フォーマット固有（モジュールによって異なります）。 各フォーマットのレポートブロックには、そのフォーマットのメカニズムにのみ関係するシグナルが表示されます。追跡対象を確認するには、該当するモジュールを参照してください。例：

• shared_library ではマーケットプレイスの動向（利用率、追放・捨てられたカード、ターンごとのライブラリー効果）が報告されます。利用率が65％以上なら健全です。30％～40％の場合は、マーケットプレイスからカードを選ぶ価値がほとんどないことを示します。調整のポイント：カーブや色のカードプールを調整して、利用率を上げます。
• 将来追加されるフォーマットモジュールでは、それぞれ固有のシグナルが表示されます（例：統率者領域を使うフォーマットなら統率者を唱えたターンの分布、連続して開封するパックを使うフォーマットならパック間のシグナルの引き継ぎ）。新しいモジュールを追加する際は、ここに対応する調整項目も追加してください。

初回実行時の前提条件： ガントレットでは playtest-install-phase（約5～10分、初回のみ）が必要です（phase-rs を使用）。ドラフトとカスタムフォーマットは純粋な Python で実装されているため、インストールは不要です。

---

Step 11: プロキシの印刷（任意）

ユーザーが物理ドラフト用にキューブを印刷したい場合：

fetch-art --from-deck cube.json --by-name        # ~15s; populates art catalog
proxy-print --kind cards --deck cube.json --out cube-cards.pdf

キューブ JSON は、proxy-print での用途においてデッキ JSON と同じ形式です（統率者＋カード、サイドボードなし）。別途印刷したいトークン生成用のカードがキューブに意図的に含まれている場合を除き、--kind tokens は省略してください。レイアウトの詳細とカタログの設定については、proxy-printer/SKILL.md を参照してください。

---

キューブとデッキの違い

デッキウィザードのツールには、キューブにも使えるものと使えないものがあります。

そのまま適用可能（同じ cards[] 形式を使用）：

• card-search、scryfall-lookup、download-mtgjson、price-check
• combo-search — 偶発的な無限コンボを見つけるのに非常に役立ちます
• card-summary、mark-owned、web-fetch

適用不可（デッキ固有の前提に基づくもの）：

• mana-audit — 60枚または100枚のデッキを前提とします
• legality-audit — フォーマットのデッキ構築ルールを前提とします
• parse-deck — 代わりに parse-cube を使用してください
• cut-check — デッキ内の統率者コンボ／シナジーの検出用に設計されています
• build-deck、deck-stats、deck-diff — キューブ版があります
• export-deck — 代わりに export-cube を使用してください
• set-commander、find-commanders、edhrec-lookup、mtga-import — キューブには関係ありません

---

参考資料

ステップ 2（デザイナーの意図）またはステップ 6（セルフチェック）の際に WebFetching する価値のある、キューブに関する記事です。Lucky Paper には API がないため、会話で記事が扱うデザイン上の疑問が出てきたときに、エージェントが必要に応じて取得してください。

• Lucky Paper：キューブデザイナーが最初に考えるべき4つの質問
• Lucky Paper：キューブのシナジー — ユーザーガイド
• Lucky Paper：キューブにおける除去とシナジー
• Lucky Paper：キューブのパワーレベル
• Lucky Paper：スケーラブルな脅威への賛歌
• Lucky Paper：キューブには土地を何枚入れるべきか
• Lucky Paper：キューブに関するよくある質問
• Caleb Gannon：キューブデザインについて学んだすべて
• CubeCobra

---

クレジット

キューブ固有のロジック（ドラフトカテゴリー分類器、サイズ 9／11／15 用のパックテンプレート）は、 dan-blanchard/cube-utils から移植されています（MIT ライセンス、クレジット表記のうえ使用）。