twohg-guide

2HG 指南

Dan 和他的搭档会参加双头巨人现开售前赛。每次比赛前，这项技能都会生成一份 2HG 速查表：一页简短的双栏内容，供他们在去店里的路上和构筑时阅读。《霍比特人》（2026 年 8 月）和《Reality Fracture》（2026 年 9 月）的速查表是风格范本：Artifact action=list 会显示这些速查表；起草前先读一份。

术语（头、×2 张牌、搭档受击、步骤触发、炸弹、牌堆）见 CONTEXT.md。

铁律

1. 不得凭记忆写牌张文本。 速查表上的每个牌名、费用和异能都必须来自 twohg-scan / scryfall-lookup / 本地 MTGJSON 数据。写下任何关于牌张的说法前，都要对照其文本核实。
2. 不得凭记忆写 CR 条文编号。 每次都要运行 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. 证据引用须准确无误。 一名玩家的套牌不等于整个队伍；“3-0 (6-0)”指三场比赛和六局比赛都未失利，而不是 6-0 的比赛记录；关于一家店的评论就只代表一家店。小样本必须标明。

工作流

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

阶段 0 — 收集信息（尽早询问一次）

与用户进行一轮 AskUserQuestion，确认以下事项（已知的跳过）：

• 系列代码和名称、比赛日期和开始时间（这会影响可获取的纸面数据量）。
• 店内产品：从 Reality Fracture 开始，WPN 的 2HG 产品为每队 1 个售前赛套装 + 2 个补充包（共 8 包，一个套装）；有些店仍使用两个套装（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
   

   • 扫描会将卡牌分为五类：
     • 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，都要传入指向该目录的 --rules-file（铁律 2）。

3. Arena 统计数据：

   • 免费版：limited-stats --set <CODE> --json > stats.json。此方式通过普通 HTTP 即可运行，但不包含钻石和秘稀段位。
   • 高级版：用户拥有 Untapped Premium 时，通过 Chrome 获取：
     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 按 Arena titleId 而非 grpid 编号。名称来自 mtgajson loc_en.json，稀有度和颜色来自 cards.json。
     • 每张卡牌内部的键依次为牌组原型和段位分组（b/s/g/p/d/m）。牌组原型键为颜色位掩码（W1 U2 B4 R8 G16，因此 3 = WU，24 = RG），或 ALL。
     • 每个段位分组包含三个数组：牌组中的对局数/胜场数、抽到或在手牌中的数据（“GIH”）以及起手牌数据。
     • 免费版会截断这些数组，并省略钻石和秘稀段位。metadata.fields 会标明各位置的名称。
   • 页面上的 ?eventType=SEALED 视图通常会在发售前显示为空；应如实说明，不要猜测。

4. 网络研究子 Agent（通用型，后台运行）。它会收集：

   • WPN 预售赛页面（双头巨人产品）；
   • 官方发售说明和机制文章；
   • Early Access 赛报（Substack、MTG Rocks）；
   • 系列评测：Draftsim 现开评测、最佳普通牌和牌组原型；chunk.science 的评级汇总；Card Game Base；MTGAZone。

   告知它 Reddit 无法访问，并要求将每条说法标注为已报道（已参加赛事）或预测（评测）。

5. 实体牌组报告：

   • 保存的帖子到达后，运行 thread-extract ~/Downloads/<thread>.html。它会输出帖子、顶层评论和已保存的图片路径，图片按文件大小从大到小排列。
   • 阅读牌组照片：牌表通常以图片形式呈现，而非文本。
   • 保存的页面不包含折叠的回复。如果缺少关键回复，请让用户展开后重新保存。

Phase 2 — 沿主线起草

• 从模板开始：twohg-template <scratch>/<code>-2hg.html。
• 填写每个部分，并控制在 Hobbit/FRA 的篇幅：做成速查表，而不是长篇文章。使用通俗的英文（读者是玩家，而不是代码仓库）。
• 卡牌名称使用 .card，{1}{B} 费用使用 .cost，加倍的数字使用 .x2，规则编号使用 .cr，颜色符号使用 .pip。

部分	内容	来源
What's winning	合并为一个部分，绝不能分别写 Arena 和纸牌赛内容。先概述经验（例如：炸弹牌加去除胜过选搭配；可以溅色）。然后每种颜色组合用一行，列出 Arena 胜率及其纸牌赛战绩；两者不一致时要指出。将套牌表放在对应颜色组合下。加入仅有的 2HG 专项报告，并逐字引用；还要写明赛制速度和表现超预期的普通牌。结尾用脚注说明数据分别来自哪里。	stats、paper reports、research
Team pairing	首先记录产品和卡池大小。然后根据数据给出默认分配：哪些颜色的普通牌最充足，哪些颜色的 ×2 牌和去除牌最多（在 FRA 中，蓝色放一套牌，黑色放另一套）。所有排名靠前的构筑方式都必须遵循默认分配；备选方案可以打破这一规则，但必须说明放弃了什么。涵盖“两套牌都必须能独立运作”和可用的修色手段。	scan、stats
The ×2 cards	制作一张表格（稀有度 · 卡牌 · 费用 · 2HG 算法），内容来自 doubles。为触发条件包括对手的牌添加一行“此处更强”，并根据 step_triggers 中 fires: once 的行添加一行不会加倍（CR 805.4d）。	scan
Downgrades & gotchas	根据 hits_partner 和 target_player，说明会影响队友的清场咒语（仍然好用，只要协调好时机）；“每位玩家”效果；“目标对手”不会加倍；“目标玩家”可以是队友；以及该系列特有的陷阱。	scan
Rules that win games	102.3 + 810.9、805.4d、805.10d（合并为一段；威慑异能需要你们团队派出 2 个阻挡者）、805.10b、810.8a（其中一位玩家的牌库耗尽，双方都会输）、810.6（先手方跳过双方的第一个抽牌步骤，所以通常应先抽牌）、810.5、805.8。只能引用 rules-lookup 的输出。	rules-lookup
Bombs	按颜色和双色组合列出你们的炸弹牌以及对手的威胁。每项都要提供抽到时的胜率（样本较小时加括号标注）、纸牌赛证据或评测者共识，并为强力牌注明应对策略。标出同时也是 ×2 牌的卡牌。最后根据 underperformers 加上一行“名气很大但并非炸弹牌”。	stats bomb_candidates + paper + research
Removal	按颜色列出你们的去除牌和对手的解牌，并注明费用和速度。说明哪些咒语能或不能指定鹏洛客（removal_reach）以及法术力值下限提示，并说明哪些坚韧度能躲开什么。	scan + card text
Build hour checklist	确认产品；分出各牌堆（去除 → 炸弹牌 → ×2 → 修色牌；颜色按牌堆决定）；采用默认分配；安排溅色和约 17 张地；调整 2HG 评级；先抽牌；若轮次时间不足则加快出牌；并在对局中协调。	上述所有内容
Sources（页脚）	列出所有使用的来源，包括链接、日期和样本量。注明卡牌图片来自 Scryfall，并标注 © Wizards。	—

第 3 阶段 — 审核（两项均为必需）

1. 规则审核。 对整张表调用 /rules-lawyer。
   • 每个 CR 编号都必须通过 rules-lookup 查询最新 CR 得出。
   • 对照卡牌文本检查每项卡牌描述：有条件的异能（“每当你不施放……”）、一次性与可重复使用的忠诚异能、“非地”、“生物或传奇咒语”。
   • 对于尚无官方裁定的诱人推论（该系列的裁定通常要到发售时才会公布），应标明这是基于规则的解读，并引用其依据的规则。
2. 一致性审核。 从头到尾重读整张表并检查：
   • 每张“炸弹”卡牌都列在“炸弹”部分；
   • 搭配遵循默认拆分规则，检查清单中的说法也一致；
   • 没有任何部分把去除咒语或炸弹描述为单方面获益；
   • 不将单条报告推广为普遍情况，记录必须准确；
   • ×2 表格、易错点和步骤触发条件行都与 scan.json 一致；
   • 没有声称 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"
  • 一句话描述
• 将修订版重新发布到同一路径，以保持 URL 不变。来自较晚会话（在商店、次日）的修订必须传入 artifact 的 url：使用 Artifact action=list 查找它，先读取，再通过 url 发布。从新会话发布时若不传入 url，会创建第二个页面。
• 告知用户该页面在从“分享”菜单分享之前为私密页面，并提供链接。
• 如果某个牌面名称被多张卡牌共用（例如，三张卡牌上都有同一个准备咒语），则跳过该名称并发出警告。对于表格所指的那张卡牌，请传入 --alias。

修订

Dan 通常会在商店期间反复修改：

• 他添加了讨论串：再次运行 thread-extract，并将结果整合到“获胜之道”中。
• 他更正了产品：更新团队搭配和检查清单。
• 他发现了不一致之处：修正后，重新运行第 3 阶段的一致性审核，因为一处修改往往会与其他部分相矛盾。

每轮修改后都重新发布，并用通俗易懂的语言概述改动内容。