twohg-guide

2HG ガイド

Dan とパートナーは、双頭巨人戦のシールド・プレリリースに参加します。そのたびに、このスキルで 2HG チートシート を作成します。これは、会場へ向かう途中やデッキ構築時に読む、短い2列のページです。『The Hobbit』（2026年8月）と『Reality Fracture』（2026年9月）のシートをスタイルの参考にしてください。Artifact action=list で確認できます。作成を始める前に、どちらか1つに目を通してください。

用語（ヘッド、×2カード、パートナーへのダメージ、ステップ誘発、ボム、山札）は CONTEXT.md に記載されています。

厳守事項

1. カードのテキストを記憶で書かない。 シートに載せるカード名、コスト、能力はすべて、twohg-scan／scryfall-lookup／ローカルの MTGJSON データから取得します。カードについて書く内容はすべて、カードのテキストと照合してください。
2. 総合ルール番号を記憶で書かない。 毎回、新たに download-rules --output-dir <scratch> を実行し、そのファイルをすべての検索に渡してください。rules-lookup --rule <n> --rules-file <scratch>/comprehensive-rules-<date>.txt を使います。--rules-file を指定しないと、現在のディレクトリにある最新のファイルを読み込みますが、リポジトリに古いものがチェックインされている場合があります。検索結果にある内容だけを引用し、説明がルール本文と一致することも確認してください。CR 810.9 が扱うのはダメージとライフのみです。「各対戦相手は両方のヘッドを意味する」は CR 102.3 です。カード固有の質問には /rules-lawyer を使ってください。
3. すべての推奨事項に矛盾がないようにする。 チームの組み合わせ、デッキ構築チェックリスト、ボムのリスト、「何が勝っているか」のセクションは、フェーズ3ですべて相互に照合します。チェックリストに「一方のデッキは青、もう一方は黒」とあるなら、すべての組み合わせがそれに従う必要があります。
4. 両方の視点を含むセクションにする。 ボムと除去には、自分たちが引くものだけでなく、相手チームが持つ脅威と回答も含めます。片方の視点だけで書かないでください。
5. ボムのセクションに載っている場合に限り、「ボム」と呼ぶ。
6. 根拠を正確に引用する。 1人のデッキはチームのデッキではありません。「3-0 (6-0)」は、敗北なしで3マッチ、6ゲームという意味であり、マッチ記録が6-0という意味ではありません。ある店舗についてのコメントは、その1店舗についてのものです。サンプル数が少ない場合は、その旨を明記してください。

ワークフロー

Phase 0 intake ─► Phase 1 gather (parallel) ─► Phase 2 draft on the spine ─► Phase 3 audits ─► Phase 4 publish

フェーズ0 — 事前確認（早い段階で一度だけ尋ねる）

次の項目を、1回の AskUserQuestion で確認してください（すでに分かっている項目は省略します）。

• セットコードと名称、イベントの日付と開始時刻（利用可能な紙のデータ量に影響します）。
• 店舗で使用する製品：Reality Fracture 以降、WPN の双頭巨人戦向け製品は、チームごとに プレリリース・パック1個＋プレイ・ブースター2個（ブースター8パック、キット1個）です。店舗によっては、今でもキットを2個（ブースター12パック）使用します。どちらを使うか尋ねてください。デッキ構築のアドバイスが変わります。
• マッチ形式（通常はベスト・オブ・ワンが最適です）。

次に、すぐに（Reddit は WebFetch、WebSearch、Chrome 拡張機能のいずれのツールでも拒否されるため、利用できません）：

ユーザーに、r/magicTCG の「Prerelease Megathread」と、プレリリース週末の r/lrcast／r/mtglimited の結果投稿を開き、各投稿を Cmd+S で ~/Downloads に保存するよう依頼してください。保存時に作成される各 _files/ フォルダーにデッキの写真が入っています。

フェーズ 1 — 収集（並行して実行）

セッションのスクラッチパッドで作業します。次の処理を同時に開始します。

1. カードのスキャン：

   twohg-scan --set <CODE> --json > scan.json
   twohg-scan --set <CODE>             # readable version
   

   • スキャンではカードを 5 つの分類に分けます。
     • doubles：×2 のカード。
     • hits_partner：対称効果と、チームメイトにも適用される一掃効果。
     • target_player：パートナーを対象にできる効果。
     • step_triggers：CR 805.4d、per_head と once の比較。
     • removal_reach：各除去呪文がプレインズウォーカーに当たるかどうか、およびその mv_floor。マナ総量で条件が決まる除去では、Jace や他のマナ総量 0 のトークンには当たりません。
   • 各カードには [ir]（フェーズによる解析）または [text]（Oracle テキストを使った代替判定。まだフェーズで解析されていないセットに使用）というタグが付きます。[text] の行はより慎重に扱い、カードのテキストと照合してください。

2. 最新のルール：download-rules --output-dir <scratch> を実行します。以後のすべての rules-lookup では、Iron Rule 2 に従い、取得したファイルを指す --rules-file を指定します。

3. Arena の統計：

   • 無料プラン：limited-stats --set <CODE> --json > stats.json。通常の HTTP で動作しますが、ダイヤモンドとミシックのランクは含まれません。
   • プレミアム：ユーザーが Untapped Premium を利用している場合は、Chrome 経由で取得します。
     1. 1 回の ToolSearch で Chrome ツールを読み込みます。
     2. 新しいタブで https://mtga.untapped.gg/limited/draft/<set-slug>/set-guide を開きます。読み込みに約 30 秒かかることがあり、読み込みが終わるまでは chrome://newtab が表示されるため、再試行を繰り返さないでください。
     3. get_page_text でページの概要を取得します。対戦数、「Early Access」の注記、勝率 6 以上の色のティア、トップコモン、サインポスト・アンコモンを確認します。
     4. タブで次を実行します。

        const r = await fetch('https://api.mtga.untapped.gg/api/v1/analytics/query/card_stats_limited_by_set/premium?CardSetFilter=<CODE>&LimitedEventTypeFilter=PREMIER_DRAFT', {credentials: 'include'});
        const t = await r.text();
        document.getElementById('__out')?.remove();
        const pre = Object.assign(document.createElement('pre'), {id: '__out', textContent: t});
        document.querySelector('main').prepend(pre);
        t.length
        

     5. get_page_text で JSON を取得します。約 50K 文字を超える場合はツール結果ファイルに保存されるため、各部分をつなぎ合わせて premium.json にします。
     6. limited-stats --set <CODE> --premium-json premium.json --json を実行します。
   • ペイロードの形式（無料プランとプレミアムで共通のため、limited-stats はどちらも読み込めます）：
     • data は grpid ではなく Arena の titleId をキーにしています。名前は mtgajson の loc_en.json から、レアリティと色は cards.json から取得されます。
     • 各カードの内部には、アーキタイプ、その次にランクの分類（b／s／g／p／d／m）の順でキーがあります。アーキタイプのキーは色のビットマスク（W1 U2 B4 R8 G16。したがって 3 = WU、24 = RG）か、ALL です。
     • 各ランクには 3 つの配列があります。デッキ内でのゲーム数／勝利数、ドローまたは手札にある場合（「GIH」）、初手。
     • 無料プランではこれらの配列が途中で切り詰められ、ダイヤモンドとミシックが省かれます。metadata.fields に各位置の項目名が記載されています。
   • リリース前のページでは、?eventType=SEALED の表示は通常空です。推測せず、その旨を伝えてください。

4. ウェブ調査サブエージェント（汎用、バックグラウンド）。次を調査します。

   • WPN のプレリリースページ（2HG 製品）。
   • 公式リリースノートとメカニズムの記事。
   • Early Access の記事（Substack、MTG Rocks）。
   • セットレビュー：Draftsim のシールド、優良コモンとアーキタイプ、chunk.science の評価集計、Card Game Base、MTGAZone。

   Reddit はアクセスできないことを伝え、各主張に 報告済み（イベントをプレイ済み）または 予測（レビューに基づく）と明記するよう依頼します。

5. 紙のレポート：

   • 保存したスレッドが届いたら、thread-extract ~/Downloads/<thread>.html を実行します。投稿、トップレベルのコメント、保存された画像のパスが、大きい順に表示されます。
   • デッキの写真を確認します。デッキリストは通常、テキストではなく画像です。
   • 折りたたまれた返信は保存済みページに含まれません。重要な返信が欠けている場合は、ユーザーに展開して再保存するよう依頼します。

フェーズ 2 — 背骨に沿って下書きする

• テンプレートから始めます：twohg-template <scratch>/<code>-2hg.html。
• ホビット/FRAと同じ分量を保ち、すべてのセクションを埋めます。エッセイではなく、カンニングペーパーにします。平易な英語で書きます（読者はリポジトリではなくプレイヤーです）。
• カード名には .card、{1}{B} のコストには .cost、倍になる数値には .x2、ルール番号には .cr、色マナ・シンボルには .pip を使います。

セクション	内容	出典
勝利につながる要素	Arenaと紙の大会の結果を別々のブロックにせず、ひとつのセクションにまとめます。最初に教訓（例：ボムと除去は色の組み合わせの選択に勝る、タッチする）を示します。次に、各色の組み合わせについて、Arenaの勝率と紙の大会成績を合わせて1行で記し、両者が食い違う場合はその旨も明記します。デッキリストは該当する色の組み合わせの下に置きます。2HG特有の報告だけを正確に引用し、フォーマットのゲーム速度と、期待以上の働きをするコモンも加えます。最後に、数値の出典を示す脚注を付けます。	統計、紙の大会報告、調査
チームの色分け	まず製品とプールのサイズを記載します。次に、データに基づく基本の分け方を示します。どの色に強力なコモンが最も多く、どの色に×2カードと除去が最も多いかを説明します（FRAでは、青を一方のデッキ、黒をもう一方のデッキにします）。順位付けした構成はすべて基本の分け方に従わせます。別案を使う場合は、何を犠牲にするかも明記します。「両方のデッキが単独でも機能すること」と、利用可能な色マナの補正手段も取り上げます。	スキャン、統計
×2カード	doubles に基づき、レアリティ・カード・コスト・2HGでの計算を列にした表を作ります。対戦相手を対象として誘発する能力について「ここではより強力」という一文を加え、fires: once の行（CR 805.4d）に基づいて「倍にならない」一文も加えます。	スキャン
弱体化と注意点	hits_partner と target_player に基づき、味方チームメイトにも影響する全体除去（依然として有用ですが、チームとタイミングを合わせます）、「各プレイヤー」に影響する効果、「対戦相手1人を対象とする」効果は倍にならないこと、「プレイヤー1人を対象とする」効果ではチームメイトも対象にできること、セット固有の落とし穴を説明します。	スキャン
ゲームに勝つルール	102.3 + 810.9、805.4d、805.10d（まとめて記載。威迫には自分のチームから2体のブロッカーが必要です）、805.10b、810.8a（片方のデッキがライブラリーアウトすると、両方とも敗北します）、810.6（先手のチームは両方とも最初のドローをスキップするため、通常は後手を選びます）、810.5、805.8を扱います。引用は rules-lookup の出力だけを使います。	rules-lookup
ボム	自分のカード群と相手の脅威を、色ごと、および多色の色の組み合わせごとに示します。各項目には、引いた場合の勝率（サンプルが少ない場合は括弧付き）、紙の大会での根拠、またはレビュー担当者の総意を記載し、強力なカードには対策のヒントも添えます。×2でもあるカードには印を付けます。最後に、underperformers に基づき、「話題ほどボムではない」カードを記載します。	統計の bomb_candidates + 紙の大会結果 + 調査
除去	自分の除去と相手の回答手段を、色別にコストと速度を添えて示します。どの呪文がプレインズウォーカーを対象にできるか、できないか（removal_reach）、MVの下限に関する注意点、どのタフネスなら何を回避できるかを説明します。	スキャン + カードテキスト
構築時のチェックリスト	製品を確認し、カードを仕分けます（除去 → ボム → ×2 → 色マナ補正。色はカードの仕分けに合わせます）。基本の分け方、タッチする色、約17枚の土地、2HGでの評価調整、後手を選ぶこと、ラウンドが時間切れになる場合は速くプレイすること、ゲーム中の連携も確認します。	上記すべて
出典（フッター）	使用したすべての出典を、リンク、日付、サンプルサイズとともに記載します。カード画像はScryfallと © Wizards のクレジットを表示します。	—

フェーズ 3 — 監査（両方必須）

1. ルール監査。 シート全体に /rules-lawyer を実行します。

   • すべての CR 番号は、最新の CR に対して rules-lookup を実行して取得してください。
   • 各カードについて、記述を照合します。条件付き能力（「あなたが唱えないたび…」）、忠誠度能力が1回限りか繰り返し使えるか、「土地でない」、「クリーチャー呪文または伝説の呪文」を確認します。
   • 公式裁定がまだない推測しやすい内容（このセットの裁定は通常、発売まで公開されません）には、根拠となるルールを引用したルールの解釈であると明記します。

2. 整合性監査。 シートを上から最後まで読み直し、以下を確認します。

   • すべての「爆弾」が Bombs に含まれていること。
   • 組み合わせが既定の分け方に従っており、チェックリストにも同じ内容が記載されていること。
   • 除去や爆弾を一方的なものとして説明しているセクションがないこと。
   • 単独の報告を一般化しておらず、記録が正確であること。
   • ×2 の表、注意点、ステップ・トリガーの行が scan.json と一致していること。
   • CR で扱われている内容について、CR に記載がないと主張していないこと。

   公開前にすべて修正してください。

フェーズ 4 — 公開

guide-card-hovers <scratch>/<code>-2hg.html --set <CODE> --out <scratch>/publish \
    [--alias "Prepare Spell=Card Name" ...]

• このコマンドは以下を行います。
  • 準備呪文の名前や両面の各面の名前を含め、ページ内のすべてのカード名を検索します。
  • 各カードの Scryfall 画像をダウンロードしてキャッシュし、ページのホバーマップに入力します。
  • <scratch>/publish/files.json を書き込みます。
• Artifact ツールで公開します。
  • file_path：<scratch>/publish/<code>-2hg.html
  • root：<scratch>/publish
  • files：files.json の内容
  • icon: "cards"
  • 1文の説明
• 改訂版は同じパスに再公開し、URLが変わらないようにします。後のセッション（ストアでの翌日など）から改訂する場合は、アーティファクトの url を渡す必要があります。Artifact action=list で見つけて、最初に読み込んでから url を指定して公開してください。新しいセッションで url を指定せずに公開すると、ページがもう1つ作成されます。
• ページは共有メニューから共有されるまで非公開であることをユーザーに伝え、リンクを知らせます。
• 複数のカードで共有される面の名前（例：3枚のカードにある準備呪文）は、警告を出してスキップされます。シートで意図しているカードを指定するには --alias を渡します。

改訂

Dan はたいていストアにいる間に何度も更新します。

• スレッドを追加した場合：thread-extract をもう一度実行し、結果を 勝っているもの に反映します。
• 製品を修正した場合：チームの組み合わせとチェックリストを更新します。
• 不整合に気づいた場合：修正してから、フェーズ 3 の整合性監査を再実行します。1つのセクションの修正が別のセクションと矛盾することがよくあるためです。

各ラウンドの後に再公開し、変更点を平易な英語で要約します。