mcpField
D
deck-wizard

deck-wizard

github.com/dan-blanchard其他22294 次安装2 天前更新
代码仓库

关于 deck-wizard

deck-wizard 是用于从头构建或调整 MTG 套牌的技能，覆盖指挥官、Brawl 和多种构筑赛制。它要求通过 Scryfall 核实卡牌规则文本，并以统一流程分析和优化套牌。

主要功能

  1. 01支持多种 MTG 赛制
  2. 02解析现有牌表或从头构筑
  3. 03通过 Scryfall 核实规则文本
  4. 04按流程分析与调整套牌
  5. 05检查结构、法力曲线及换牌影响

适用场景

  1. 01为指定赛制创建新套牌
  2. 02调整已有牌表
  3. 03围绕组合技设计套牌
  4. 04核验卡牌能力与套牌合法性

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/dan-blanchard/mtg-skills --skill deck-wizard

安装后在 Claude Code 中输入/deck-wizard确认已加载。

附带文件pyproject.tomluv.lock

详细介绍

Deck Wizard

从零开始构建 MTG 套牌，或调整现有套牌，适用于所有支持的赛制：Commander/EDH、Brawl、Historic Brawl（带指挥官的单例赛制），以及 Standard、Alchemy、Historic、Pioneer、Timeless、Modern、PreModern、Legacy、Vintage（带备牌的 60 张构筑赛制）。每条建议都必须以 Scryfall 上实际的卡牌 Oracle 文本为依据，绝不能依据训练数据。

此技能分为两个阶段。**阶段 1（套牌获取）**决定用户如何获得套牌：解析现有牌表（路径 A），或从零开始构建（路径 B）。这两条路径都会生成套牌 JSON，并按需通过各自的 sidecar 填充数据。**阶段 2（调整）**会对套牌运行相同的 13 步流程，无论套牌来自哪条路径。

铁律

**绝不要臆测卡牌的作用。**引用任何卡牌的异能前，都必须通过辅助脚本查询其 Oracle 文本。训练数据不是 Oracle 文本。

**例外（仅限 Commander/Brawl）：**在指挥官发现阶段（向不知道该构建什么的用户推荐指挥官），可以使用训练数据生成候选名单。但在展示推荐之前，必须核验每位推荐的指挥官——将所有候选名称写入 JSON 列表，并通过一次调用批量查询：scryfall-lookup --batch <candidates.json> --bulk-data <bulk-data-path> --cache-dir <working-dir>/.cache。

对于 60 张构筑赛制：发现阶段（头脑风暴候选卡牌）可以使用训练数据；评估阶段（决定是否加入卡牌）必须使用经过核验的 Oracle 文本。

支持的赛制

赛制套牌张数同名牌数量上限备牌平台合法性键备注
commander1001（单例）否纸牌 + MTGOcommander40 点生命，多人对局
brawl601（单例）否Arenastandardbrawl25/30 点生命，Standard 牌池
historic_brawl1001（单例）否Arena（+ 纸牌）brawl25/30 点生命，所有 Arena 系列
competitive_brawl1001（单例）否仅 Arenacompetitivebrawl25 点生命，1 对 1，没有免费调度
standard60415Arena + 纸牌standard轮换制
alchemy60415仅 Arenaalchemy数字机制
historic60415仅 Arenahistoric所有 Arena 系列
timeless60415仅 Arenatimeless无禁牌
pioneer60415纸牌 + Arenapioneer从 RTR 起
modern60415纸牌 + MTGOmodern从第八版起
premodern60415纸牌 + MTGOpremodern从第四版至 Scourge
legacy60415纸牌 + MTGOlegacy永恒赛制，有禁牌表
vintage604（限制牌=1）15纸牌 + MTGOvintage限制牌最多只能使用 1 张
sealed40（最低）无（按开包所得）未使用的牌池Arena + 纸牌pool containment使用开包所得牌池和基本地构建（CR 100.2b）
draft40（最低）无（按开包所得）未使用的牌池Arena + 纸牌pool containment规则与 sealed 相同；牌池由轮抓所得牌组成

进度跟踪

**开始前，创建一个 TodoWrite 列表。**第一个问题决定所走路径；据此创建待办事项。

阶段 1：路径 A（调整现有套牌）
  • 解析牌表
  • 填充卡牌数据
阶段 1：路径 B（从零开始构建）
60 张构筑赛制
  • 访谈
  • 赛场环境研究
  • 骨架生成
  • 结构验证

**扩展骨架生成：**开始时，细分为以下子待办事项：

  • 填充生物／威胁
  • 填充去除／互动
  • 填充卡牌优势
  • 填充功能／灵活卡位
  • 填充法术力基础
  • 填充备牌（仅 Bo3）

**组合技优先变体：**如果用户想围绕组合技构建，则添加／替换以下事项：

  • 组合技／核心构思发现（替代标准研究引导）
  • 外壳构建（替代赛场环境研究）
  • 含组合技核心的骨架（替代标准骨架生成）
Commander/Brawl/Historic Brawl
  • 访谈
  • Commander 分析
  • 骨架生成
  • 结构验证

骨架生成扩展： 开始时，扩展为以下子待办事项：

  1. 填充地牌
  2. 填充加速牌
  3. 填充抽牌
  4. 填充指定去除牌与清场牌
  5. 填充保护／功能牌
  6. 填充引擎／协同组件
  7. 填充获胜条件
  8. 结构验证（deck-stats、mana-audit、price-check）

如果你一次性批量起草整个骨架，而不是按类别依次填充，仍然不得批量完成子待办事项。你必须选择以下任一方式：（a）本次完全跳过创建填充顺序子待办事项（只在顶层骨架生成开始和完成时更新状态）；或（b）起草时，每当你在脑海中完成一个类别，就单独关闭对应的子待办事项。

如果用户选择“跳出框架”工作流， 在进行到每个替代步骤时添加或替换待办事项，并保留任何已经完成的标准步骤。

请勿在任何填充步骤中创建单张卡牌的子待办事项——这是执行细节，会让列表过于冗长。

阶段 2：调优（两种路径）
  1. 步骤 1：基准指标
  2. 步骤 2：收集用户信息
  3. 步骤 3：研究
  4. 步骤 4：策略对齐
  5. 步骤 5：Commander 互动审查 （仅限 Commander/Brawl/Historic Brawl——60 张构筑赛制请跳过）
  6. 步骤 6：分析
  7. 步骤 7：预审查验证
  8. 步骤 8：自我审查
  9. 步骤 9：提出变更
  10. 步骤 10：影响验证
  11. 步骤 11：斟酌事项
  12. 步骤 12：定稿

开始每个项目时，立即将其标记为 in_progress；完成时，立即将其标记为 completed——不要批量更新。

步骤 6 和步骤 8 的工作量较大，仅更新顶层项目会让用户看到的列表一直没有变化。 进行到这两步时，再分别扩展为子待办事项（不要预先创建）：

  • 步骤 6 子待办事项：6a 法术力基础与曲线审查、6b 互动与威胁审查、6c 套牌构筑思路一致性、6d 拟定删减、6e 拟定新增、6f 备牌评估（仅限 60 张）、6g 替换平衡检查。
  • 步骤 8 子待办事项：派遣提案者与挑战者子 Agent、处理挑战者报告、修改提案。

请勿在步骤 6 中为删牌清单创建单张卡牌的子待办事项——这是执行细节，会让列表过于冗长。

路径 B 调整： 如果骨架合理，步骤 9–11 可能不会产生任何变更。如果无需变更，请跳至步骤 12。

设置（首次运行）

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

后续运行时，如果 .venv 已存在且批量数据在 24 小时内更新，则跳过。

工具说明

写入 JSON 文件

对任何包含卡牌名称的 JSON 文件，请使用 Write 工具。 名称中的撇号（例如，“Ashnod's Altar”）会导致 shell 在 heredoc 和内联 Python 中的引号处理出错。Write 工具的权限可在会话中缓存；python3 -c "..." 则每次都会重新提示授权。

请勿通过 Bash heredoc 写入 JSON（cat > /tmp/foo.json << 'JSONEOF' ... JSONEOF）。Heredoc 在功能上完全可行，但会产生无法缓存的 Bash 权限模式：Claude Code 的权限引擎会将 heredoc 正文写入允许模式，因此每次调用内容不同时，都会重新提示用户。Write 工具只会生成一个 Write(/tmp/**) 权限，可授权一次并重复使用。

同样的缓存问题也适用于 python3 -c "..."、awk '...'、jq '...'，以及任何代码正文会随调用而变化的 Bash 模式。 每个不重复的正文都会生成新的权限模式。如果你只需要从 JSON 文件中提取一个字段，请优先选择：（a）将文件直接传给已能解析该文件的脚本；（b）使用 JSON 文件的 Read 和 offset／limit；或（c）对文件使用 Grep。只有在这些选项确实无法满足需求时，才使用 python3 -c，并接受它会再次提示授权。

临时文件路径

在一个会话中重复使用以下稳定路径：/tmp/cuts.json、/tmp/adds.json、/tmp/sideboard-cuts.json、/tmp/sideboard-adds.json、/tmp/candidates.json、/tmp/pet-cards.json。

警告 — /tmp 文件会跨会话保留。 对任何已有文件，Write 工具都要求先执行 Read；因此，在新会话中首次向重复使用的 /tmp/*.json 路径执行 Write 会失败，并报错 "File has not been read yet"。如果你将该 Write 与读取同一文件的 Bash 调用并行批处理，Bash 会悄悄读取上个会话留下的过期内容——并行的 Write 错误不会阻止 Bash，因此 cut-check / scryfall-lookup --batch / price-check / build-deck 会直接使用错误数据运行。症状：工具结果中列出了你从未提出过的牌。规则：（a）在会话开始时，先对计划重复使用的每个临时路径执行 Read，再进行首次 Write；或者（b）按顺序执行 Write（不要并行），并在依赖它的 Bash 调用前确认成功。切勿在同一条消息中批处理 Write(/tmp/foo.json) + Bash(读取 /tmp/foo.json 的工具)。如果工具结果中的牌与预期输入不符，先怀疑读取了过期文件，再怀疑工具有缺陷。

炼金牌警告

炼金牌会在标准赛制牌池之外加入仅限数字版的原创牌，其机制只能在 Arena 中生效（conjure、seek、perpetually 等）。与其他牌一样，请核实它们的 oracle 文本。Arena 已于 2026-09-22 将所有重新平衡过的（A-）牌恢复为纸牌版本，且牌张数据不再包含重新平衡过的 A- 记录，因此请查询不带前缀的牌名。如果 Arena 今后再次重新平衡某张牌，带 A- 的名称才对应当前生效的 oracle 文本。

AskUserQuestion 选项上限

AskUserQuestion 最多接受 4 个选项——绝不要悄悄省略其余选项。 该工具的架构不允许每个问题包含超过 4 个选项。展示较长列表时（例如 5 个以上的难以取舍的替换选项、5 个备选指挥官等），不要只挑 4 个而隐藏其他选项。请在前面的文本消息中列出所有选项，并提供足够信息供用户判断；然后仅将 AskUserQuestion 用作轻量级选择器：可以（a）将最优的 3 个放在按钮上，再加第 4 个“其他（请在备注中注明）”，让用户从文本列表中指定任何选项；也可以（b）在这项决策中完全跳过 AskUserQuestion，让用户用纯文本回复。要避免的情况是：文本中提到了 5 个以上选项，按钮却只有 4 个，让人误以为按钮已列出全部选项。

路径要求
  • 仅使用绝对路径。 uv 会将工作目录切换到技能安装目录；相对路径会指向错误的根目录。
  • 缓存目录： 始终使用 <working-dir>/.cache，而不是技能安装目录。将缓存放在工作目录中可避免触发工作区外的权限提示。（此要求适用于对名称列表执行 scryfall-lookup --batch——候选牌、心仪牌、组合组件。）
  • 数据填充： 每个套牌 CLI 都会从套牌旁边的 sidecar 文件自行填充数据（deck.json → deck.hydrated.json），并依据套牌内容、bulk 身份和版本进行匹配——不会读取过期的 sidecar。编辑套牌后重新运行任意工具即可；无需手动重新填充数据或更改路径。

确定赛制后，务必在 parse-deck 中传入 --format <format>。 如果不传，parse-deck 默认使用 commander，导致所有下游工具都读取到错误的赛制。

竞技乱斗（Arena）

competitive_brawl 是一等格式——传入 --format competitive_brawl，工具即可处理。切勿将其当作 historic_brawl 来审计，然后对失败结果敷衍了事。

这是 Arena 的排位乱斗队列（2026 年 6 月）：100 张单例、1v1、25 点生命，没有免费调度（与普通乱斗不同）、没有指挥官伤害，鹏洛客无需明确的许可文字即可作为指挥官。

关于其牌池，有两点需要了解：

  1. 它的禁牌表与普通乱斗不同。 它禁用十张牌，无论作为指挥官还是放在其余 99 张牌中都不能使用；除此之外，所有 Arena 卡牌均合法，包括普通乱斗禁用的大多数牌（Mana Drain、Demonic Tutor、Fierce Guardianship、Ancient Tomb、Chrome Mox……）。工具读取 MTGJSON 自带的 competitivebrawl 合法性键，因此，brawl 下的 banned 在这里毫无意义；not_legal 则表示该牌根本不在 Arena 上。2026-10-10 之前批量下载的卡牌数据缺少该键，因此每张牌都会显示为 not_legal；加载器从此类批量数据构建索引时会发出警告。请运行 download-mtgjson。
  2. 重平衡卡牌已于 2026-09-22 恢复原样。 Arena 在所有格式中都将每张炼金术的 A- 重平衡牌恢复为纸质版印刷牌，卡牌数据也已同步：A- 记录已删除，纸质版卡牌带有正确的合法性信息（纸质版 Nadu 在 competitivebrawl 下禁用；Harald, King of Skemfar 合法）。任何残留的 A- 结果都应视为过期数据。

一般情况下如何判断 Arena 是否提供某张牌： 如果某张牌的 MTGJSON 记录中 games 包含 arena，就可以合成。仅检查合法性键并不够——banned 和 not_legal 都表示「在普通乱斗中不合法」，但只有后者表示「不在 Arena 上」。

禁牌表是某个时间点的快照（来源：https://mtg.wiki/page/Competitive_Brawl）。每次发布禁限牌公告后都请重新核实。

Arena 稀有度警告

牌组已填充的 sidecar 中，rarity 字段表示 Scryfall 默认印刷版本的稀有度，该值与 Arena 实际需要的外卡数量可能不一致。为 Arena 规划外卡预算时，始终使用 price-check --format <fmt> --medium digital --bulk-data <path>。决定使用外卡还是美元的是介质，而不是格式：仅限 Arena 的格式（Brawl、Historic Brawl、Alchemy、Historic、Timeless）本身就是数字版；但 Standard 和 Pioneer 默认使用纸质版，因此要为这些格式构建 Arena 牌组，需要加上 --medium digital（或在牌组 JSON 中设置 "medium": "digital"）。安装 Arena 后，工具会直接从 Arena 自身的卡牌数据库读取稀有度（ADR-0057），并采用该牌可合成印刷版本中的最低稀有度，因此与 Arena 的收费一致。未安装 Arena 时，工具会改用 MTGJSON 的印刷版本数据；对于约 35 张牌，这些数据并不正确，其中大多数是被 MTGJSON 列为秘稀的特邀嘉宾重印牌。

授权 IP 卡牌警告

某些跨界系列中的牌，在 Arena 上使用的名称与纸质版/Scryfall 中不同：Through the Omenpaths（OM1，即 Marvel's Spider-Man 的 Arena 版本）、依克黎 Godzilla 变体、依尼翠：血婚 Dracula 变体，以及《降世神通：最后的气宗》卡牌，都存在名称差异。处理 Arena 收藏时，务必将 --bulk-data 传给 mark-owned——这样会启用 printed_name 和 flavor_name 别名匹配，让 "Skittering Kitten"（Arena 名称）之类的卡牌能够正确匹配 "Masked Meower"（Scryfall 名称）。如果不传 --bulk-data，这些卡牌会悄无声息地显示为未拥有。

解析后的套牌 JSON 架构

60 张构筑套牌：

{
  "format": "pioneer",
  "deck_size": 60,
  "sideboard_size": 15,
  "commanders": [],
  "cards": [{"name": "Lightning Bolt", "quantity": 4}, ...],
  "sideboard": [{"name": "Roiling Vortex", "quantity": 3}, ...],
  "total_cards": 60,
  "total_sideboard": 15,
  "owned_cards": [{"name": "Lightning Bolt", "quantity": 4}, ...]
}

构筑赛制的 "commanders" 始终为 []。sideboard 字段用于单独存放备牌，与主牌 cards 分开。

指挥官／Brawl／Historic Brawl：

{
  "format": "commander",
  "deck_size": 100,
  "commanders": [{"name": "...", "quantity": 1}, ...],
  "cards":      [{"name": "...", "quantity": 1}, ...],
  "total_cards": 100,
  "owned_cards": [{"name": "...", "quantity": 1}, ...]
}

所有卡牌列表（commanders、cards、sideboard、owned_cards）都采用 [{name, quantity}] 结构。parse-deck 会将 owned_cards 初始化为空，之后由 mark-owned 填充。price-check 会读取该字段，从预算中扣除已拥有的卡牌副本；quantity < 1 的条目会被视为“未拥有”。

所有套牌工具的唯一输入都是解析后的套牌 JSON。 从 parse-deck 获取解析后的套牌 JSON 后，请将其直接传递给每个套牌 CLI——deck-hydrate、price-check、deck-stats、mana-audit、legality-audit、combo-search、card-summary、deck-signals、slot-budgets、deck-tune 等工具都接受 <deck.json>（以及通用可选参数 --bulk-data <path>），并通过各自的 sidecar 完成数据补全；不要另行维护单独的补全后路径。不要使用 python3 -c 或类似方法，将卡牌名称提取到单独的 /tmp/*.json 文件中。（例外情况是输入为套牌子集的脚本——cut-check --cuts <path> 和 build-deck --cuts <path> --adds <path> 接受卡牌名称字符串的 JSON 列表，而非解析后的套牌 JSON，因为调用方指定了要操作的卡牌。在这些情况下，使用 Write 工具写入小型 /tmp/cuts.json 是正确做法。）

脚本调用

所有脚本都从技能安装目录通过 uv run <script-name> 调用。为简洁起见，本文档中的示例省略了 uv run 前缀。

核验卡牌数量

手动编写或编辑套牌文本文件后，务必立即解析并核验总卡牌数量是否符合赛制要求。手动编辑时，数量多一张或少一张的错误很常见，而且不会自动提示。**预防方法：**在编写套牌文件前，先在说明文字中明确列出各类别的数量：

  • 100 张套牌（指挥官／Historic Brawl）：例如，“地牌 36 + 加速 10 + 抽牌 10 + 去除 10 + 清场 3 + 功能牌 8 + 引擎 18 + 制胜牌 4 = 99 + 1 位指挥官 = 100”
  • 60 张单例套牌（Brawl）：将各类别数量乘以 0.6 并四舍五入。例如，“地牌 22 + 加速 6 + 抽牌 6 + 去除 6 + 清场 2 + 功能牌 5 + 引擎 11 + 制胜牌 1 = 59 + 1 位指挥官 = 60”
  • 60 张构筑套牌：“生物 24 + 瞬间／法术力牌 16 + 地牌 20 = 60”
填充 owned_cards

从用户的收藏构建时，请使用专用辅助工具，而不是内联 python3 -c：

mark-owned <deck.json> <collection.json> [--bulk-data <bulk-data-path>]

Arena 收藏务必传入 --bulk-data——这会启用 printed_name 和 flavor_name 别名映射，确保联动卡牌正确匹配。该脚本具有幂等性，可安全地在每次 parse-deck / set-commander 调用后接续运行。

mark-owned 也会对 DFC / 分栏 / 历险 / 模态卡牌进行正面别名匹配：牌组中列出的 "Fable of the Mirror-Breaker"（仅正面名称，常见于 Arena / Moxfield 导出）可以匹配收藏中的 "Fable of the Mirror-Breaker // Reflection of Kiki-Jiki"（Scryfall 的规范组合形式），反之亦然。调用 mark-owned 前，无需手动规范化这些名称。

所有权规则——每当计算卡牌数量或外卡时都要遵循。 基本地（Plains、Island、Swamp、Mountain、Forest、Wastes）无论数量多少都视为已拥有。在 Arena 上没有例外（基本地样式仅为外观）。在线下，例外情况是牌组要求特定印刷版本——闪卡或蚀刻闪、全画幅、无边框、展示框或其他特殊框架、促销卡——只有收藏中包含该确切印刷版本时才算拥有（仅按名称列出基本地或完全未列出的收藏不算）；普通的系列标注，如 "Forest (M21) 274"，仍视为已拥有。雪境基本地是不同的卡牌，按其他卡牌的方式收藏。在 Arena 上，拥有一张卡的四张副本即可满足任意数量：四张 Hare Apparent 或 Rat Colony（“任意数量”）可填满所有卡位，四张 Seven Dwarves（“最多七张”）可填满七个卡位——但拥有三张就只有三张副本。除此之外，无论是哪种形式，拥有多少就算多少。工具已通过一个函数（Format.copies_short）应用此规则：price-check（线下计算美元差额，Arena 上计算外卡）、deck-tune 的预算（新增的每张副本只有在收藏能满足该副本时才免费），以及 deck-forge 的费用显示。手动判断“他们能组出这副牌吗？”或“需要多少外卡？”时，也要应用相同规则，而不要只比较已拥有数量和所需数量。

决策表
任务工具
按 Oracle 文本、牌张类别、CMC 查找符合赛制规则的牌card-search --format <fmt> --bulk-data <path>
预热/验证牌组的已填充 sidecar（检查 missing）deck-hydrate <deck.json> [--bulk-data <path>]
运行 Step-6 确定性主流程（评分卡 + 候选替换）——适用于所有赛制deck-tune <deck.json> [--bulk-data <path>] [--bracket <1-5>] [--max-swaps <N>] [--budget <usd> | --wildcards <rarity=N,…>] [--medium paper|digital] [--exclude <name>]… --output <wd>/tune.json
查看指挥官/牌组关注的内容（信号通道）——临时查询；主流程的 focus 已包含此项deck-signals <deck.json> [--bulk-data <path>] [--json]
角色密度预算（地牌/加速/抽牌/互动/清场）——临时查询；主流程的 template 已包含此项slot-budgets <deck.json> [--bulk-data <path>] [--shape <S>] [--json]（牌组大小取自牌组 JSON）
按协同作用为单独的候选列表排序——主流程的 swaps 已为新增牌排序deck-rank <deck.json> <candidates.json> [--bulk-data <path>] [--limit <N>] [--json] [--medium paper|digital] [--meta auto|off|<archetype>]（候选牌来自 card-search --json）
查询特定牌的 Oracle 文本scryfall-lookup "<Card Name>"
查看牌张表（主牌库）card-summary <deck.json> [--nonlands-only] [--lands-only] [--type <T>] [--bulk-data <path>]
查看牌张表（备牌）card-summary <deck.json> --sideboard [--bulk-data <path>]
扫描牌组，查找匹配 Oracle 模式的牌Grep '<regex>' <wd>/deck.hydrated.json——完整 Oracle 文本，不截断
统计牌张数量/验证总数是否与牌组大小相符deck-stats <deck.json> [--bulk-data <path>]
查找牌组中的组合技combo-search <deck.json> [--bulk-data <path>] [--max-near-misses <N>]
按牌张或结果查找组合技combo-discover --card "<Name>" --format <fmt>
检查拟议的移除是否会破坏一个近似组合技使用 Grep '<cut-name>' <combo-search.json> 查找这张牌作为搭档出现的近似组合技行
检查牌组是否合法legality-audit <deck.json> [--bulk-data <path>] [--cite-rules/--no-cite-rules] [--rules-file <path>]
检查法术力基础状况mana-audit <deck.json> [--bulk-data <path>]
比较调整前后的法术力mana-audit <deck.json> --compare <new-deck.json> [--bulk-data <path>]
价格检查（实体牌）price-check <deck.json> --bulk-data <path>
价格检查（Arena 通配牌）price-check <deck.json> --format <fmt> --medium digital --bulk-data <path>
根据所有机制门槛检查提案（Steps 7 + 10）proposal-check <deck.json> --cuts <c.json> --adds <a.json> [--sideboard-cuts …] [--sideboard-adds …] [--budget <usd> | --wildcards <rarity=N,…>] [--medium paper|digital] [--collection <collection>] [--allow-combo-loss] [--multiplier-low N --multiplier-high N] [--output-dir <dir>]（写入 new-deck.json、sidecar 和 proposal-check.json；如果检查失败则以状态码 1 退出）
应用主牌库 + 备牌变更build-deck <deck.json> --cuts <c.json> --adds <a.json> --sideboard-cuts <sc.json> --sideboard-adds <sa.json> [--bulk-data <path>] [--output-dir <dir>]（写入 new-deck.json 及其独立的 new-deck.hydrated.json sidecar）
比较牌组版本deck-diff <old-deck.json> <new-deck.json> [--bulk-data <path>]
导出以供导入export-deck <deck.json>（Arena 赛制会自动选择 Arena 分区标题；使用 --style moxfield|arena 强制指定）
根据收藏集标记已拥有的牌mark-owned <deck.json> <collection.csv> [--bulk-data <path>]
查看我拥有的牌组牌张及其数量mark-owned <deck.json> <collection.json> [--output PATH] [--bulk-data <path>]
规划通配牌花费/获取每张牌或汇总的 Arena 稀有度price-check <deck.json> --format <fmt> --medium digital --bulk-data <path>
获取一张牌在 Arena 中最低的稀有度price-check --format <fmt> --medium digital（绝不使用牌组已填充 sidecar 的 rarity 字段）
从收藏集中查找已拥有、合法且符合指挥官资格的牌find-commanders <collection.json> --format <fmt> --bulk-data <path> --output <working-dir>/.cache/candidates.json
研究环境/策略WebSearch + WebFetch（或 web-fetch 脚本）
运行自我审查（Step 8 硬性门槛）并行调用两次 Agent，使用 subagent_type: "general-purpose"
为裁定引用 MTG 综合规则rules-lookup --rule <n> / --term <keyword> / --grep "<regex>"
获取 Scryfall 的单牌裁定rulings-lookup --card "<name>" --bulk-data <path>
更深入的规则问题（层级/时机/堆叠）通过 Skill 工具调用 rules-lawyer 技能
只有在这些选项都无法满足需求时，才编写 python3 -c。如果确实需要编写，请将所有相关问题批量放进同一个主体中——每个不同的主体都会形成一种新的权限模式，因此一个大型脚本胜过五个小脚本。
规则顾问

对于调试过程中出现的简单规则问题（例如“践踏的规则是什么？”、“这个触发效果是强制的吗？”），直接运行 rules-lookup --term <keyword>——单次 CLI 调用即可返回术语表定义以及相关 CR 规则编号。对于涉及多条规则的复杂问题（如层效应交互、替代效应的时机、触发式与起动式异能之间的堆叠顺序），请调用 rules-lawyer 技能；它负责升级至子 Agent 的流程。

cut-check 和 legality-audit 会自动在 JSON 输出中附加 CR 引用——--cite-rules 默认开启。当工作目录中存在 CR 文件时（也就是说，你在同一个工作目录中运行过 download-rules --output-dir <wd>），每项标记出的交互／违规都会附带规则编号和摘录，无需额外标志。传入 --no-cite-rules 可在特定调用中关闭此功能；如果无法访问 CR，这些工具仍会以 0 退出，并向标准输出写入一行 WARN: rule_citations not attached。

在进行任何 Step 1 legality-audit 调用之前，每个会话运行一次 download-rules --output-dir <working-dir>（24 小时新鲜度检查，与 download-mtgjson 的模式相同）。

阶段 1：获取套牌

首先询问：“你有现成的套牌要调整，还是想从头构筑？”

如果用户提供套牌列表（粘贴内容、文件路径或 URL），请遵循路径 A。如果用户想从头构筑，请遵循路径 B。如果用户打开了补充包或参加了轮抽（限制赛），请遵循路径 C。

阶段 1，路径 A：解析并填充现有套牌

解析套牌列表
parse-deck <path> --format <format> --output <working-dir>/deck.json
  • 自动检测输入格式（Moxfield、MTGO、Arena、纯文本、CSV）
  • 将备牌牌张路由到 sideboard 字段（与 cards 分开）
  • 自动去除 Moxfield 系列代码后缀，并合并重名牌张
  • 报告：parse-deck: N cards, M sideboard -> /path/to/deck.json

**始终明确传入 --format <format>。**如果不传，parse-deck 默认采用 commander，所有下游工具（legality-audit、price-check）都会使用错误的格式。

支持的格式：commander（100 张牌）、brawl（60 张牌，标准赛制牌池）、historic_brawl（100 张牌，Historic／Arena 牌池）、standard、alchemy、historic、pioneer、timeless、modern、legacy、vintage（均为 60 张牌，带 15 张备牌）、sealed／draft（从已开启的牌池中构筑，至少 40 张牌——路径 C）。使用 --deck-size 可覆盖默认套牌大小。

如果无法从上下文明确判断格式，请询问用户。

Commander 赛制

如果 commanders 为空（常见于缺少 //Commander 标题的 Moxfield 导出文件），请询问用户谁是指挥官。不要猜——列表中的第一张牌通常是指挥官，但并非总是如此。支持搭档指挥官、永伴好友以及背景搭配。

运行 set-commander <deck.json> 'Commander Name'，将牌从 cards 列表移至 commanders 列表。set-commander 具有幂等性——如果牌已经在 commanders 区域中，再次调用时不会有任何操作，因此即使套牌文件已经包含 Moxfield 的 Commander 标题，也可以安全地在 parse-deck 后接着调用。

收藏归属（Arena）

如果用户拥有 Arena 收藏：

  1. 首先索取 Untapped.gg CSV 导出文件（这是最可靠的数据来源）
  2. 使用 mark-owned <deck.json> <collection.csv> --bulk-data <path> 填充 owned_cards（接受 CSV 和已解析的套牌 JSON）
  3. 仅使用 mtga-import 提取万能牌数量，不要用它提取收藏数据
  4. 按归属规则（工具说明）统计收藏中可覆盖的牌张数量：拥有四张即可覆盖任意数量的需求；除非纸质套牌要求特定印次，否则基本地视为已拥有

对于 Arena 收藏，始终传入 --bulk-data（别名处理详情请参阅“工具说明”>“填充 owned_cards”）。

水合牌组数据
deck-hydrate <working-dir>/deck.json [--bulk-data <path>]

返回一个包含 sidecar_path、card_count、missing、digest 的信封。此工具会在牌组 JSON 旁生成 deck.hydrated.json，将主牌、备牌、指挥官和伙伴牌中的每张牌与牌张数据关联起来；文件内的索引键由牌组内容、批量数据的标识和载荷版本共同组成。请检查 missing——牌张数据无法解析的名称只会在标准错误中警告一次，并且不会计入数量。

切勿直接读取 sidecar 文件——文件很大，会塞满上下文。针对性读取请使用 card-summary 或 scryfall-lookup "<Name>"；使用 Grep '<regex>' <working-dir>/deck.hydrated.json 扫描规则叙述文本模式则没有问题。

无需追踪缓存路径。 每个牌组 CLI 只需接收 <deck.json>（以及可选的 --bulk-data），并通过同一个 sidecar 自动完成水合。编辑牌组后重新运行任意工具即可。deck-hydrate 本身只是获取数据后立即执行的显式预热／验证步骤，这样你就能在运行分析前看到 missing。

水合完成后，继续进入阶段 2：调整。

阶段 1，路径 C：密封赛／轮抓（一个限制赛牌池）

限制赛套牌由用户开出的牌以及基本地（规则 100.2b）组成：没有同名牌数量限制，也没有备牌上限（备牌区就是未使用的牌池），至少 40 张牌，合法性检查依据是牌池包含关系。整套工具链都将其视为 limited 系列（ADR-0055）——绝不要套用 40 张牌的构筑赛格式。

parse-deck <arena-export.txt> --format sealed --output <working-dir>/deck.json
# a bare list of the opened cards (no deck yet): add --pool-only
deck-hydrate <working-dir>/deck.json

导出内容中的牌组部分会变成 cards，牌组和备牌部分会成为 pool 区域，而备牌部分仍保留为备牌。接下来，在对任意颜色组合做出判断之前：

  1. pool-colors <working-dir>/deck.json — 平等评估牌池支持的每种单色和双色组合（可用牌、生物、去除、闪避、力量为 4 以上的生物、稀有牌）。请阅读完整表格；最佳组合应是分析结果，而非预设结论。
  2. set-scan --set <CODE> — 查看该系列包含什么（按稀有度划分的去除、清场、闪避、身材最大的生物）。评估每张解答牌和威胁牌时，都要以对手可抽到的系列牌池为依据，而不是以用户开出的牌为依据。
  3. 为排名前两三个颜色组合构建最佳的 40 张牌，并进行公平比较；通常使用 17 张地（mana-audit 会读取限制赛的 16–18 张范围）。
  4. legality-audit <working-dir>/deck.json — 检查牌池包含关系（每张牌都必须在牌池中），并确认至少有 40 张牌。deck-tune 会运行限制赛模板（生物、去除、费用曲线分段），并且只在牌池范围内搜索。

步骤 8 中针对限制赛套牌的自我审查，会要求提案者和挑战者根据 pool-colors 表格为牌池中所有可行的颜色组合排序，并说明排序理由——提示词中不会点名任何候选组合，表格是输入依据，而非最终牌表。

阶段 1，路径 B：从零构筑

访谈

首先确定赛制。询问：“你想为哪种赛制构筑？”

如果用户说 Commander、Brawl 或 Historic Brawl，请遵循下方的Commander／Brawl 访谈。如果用户说出一种 60 张牌构筑赛制（Standard、Pioneer、Modern 等），请遵循60 张牌构筑赛制访谈。

如果用户提到 Arena 但未指定赛制，请澄清：

  • Standard、Alchemy、Historic 和 Timeless 都是 Arena 赛制（60 张牌构筑赛）
  • Standard Brawl（在 Arena 上称为“Standard Brawl”）属于 Brawl
  • Arena 上的“Brawl”实际指 Historic Brawl
  • Arena 上也有 Pioneer，但其牌池与实体牌相同
  • Modern、PreModern、Legacy、Vintage 仅限实体牌／MTGO
60 张牌构筑访谈

每个回答都会影响下一题的选项，因此请依次使用 AskUserQuestion 提问：

  1. 赛制 — 想玩哪种赛制？（Standard、Pioneer、Modern 等）
  2. 平台 — Arena 还是纸牌？（决定定价模式和牌池筛选；如果赛制已能确定平台，则跳过，例如，Alchemy 始终在 Arena 上进行）
  3. Best-of-One 还是 Best-of-Three？ — 仅适用于 Arena；纸牌对局跳过。Bo1 没有备牌——完全跳过备牌构筑，并构筑一套针对第一局提高韧性的主牌（选择更多用途广泛的牌，减少针对性较窄的解牌）。Bo3 按常规流程进行，包含完整的备牌。
  4. 打法风格 — 快攻、中速、控制、组合技、节奏？（如果用户不确定，可简要说明）
  5. 颜色偏好 — 有偏好的颜色吗，还是都可以？
  6. 预算 — 纸牌的美元预算，或 Arena 的万能牌预算？
  7. 套牌原型偏好 — “你想采用经验证的环境套牌原型，还是构筑一些原创或非主流的套牌？”
  8. 心头好牌 — 有哪些一定想加入的牌？（开放式文本，不使用 AskUserQuestion）

注意：问题 2–3 有时可以合并或跳过（纸牌对局始终是 Bo3；Legacy、Vintage、Modern 始终是纸牌对局）。

组合技优先路径

如果用户说“围绕组合技构筑”或说出某个特定组合技／核心牌，则切换到组合技优先变体：

组合技／核心牌探索：

  • 如果用户说出某张牌：使用 scryfall-lookup 查询，然后运行 combo-discover --card "<Name>" --format <fmt>
  • 如果用户说出想达成的结果：运行 combo-discover --result "<outcome>" --format <fmt>
  • 如果用户想探索：询问其感兴趣的机制、结果或颜色，然后进行搜索
  • 使用 WebSearch 补充： combo-discover 使用的是 Commander Spellbook，其内容主要由 Commander 玩家众包提供。在 1v1 的 60 张牌赛制中很强、但在多人 Commander 中较弱的组合技可能较少收录。搜索 "<format> combo decks" 和 "<card name> combo <format>"，以发现 API 可能遗漏的赛制专属配合。
  • 展示 3–5 个组合技，并包含：卡牌、Oracle 规则文本、结果、颜色标识、人气
  • 使用 scryfall-lookup --batch 批量查询所有组合技组件
  • 让用户选择一个组合技或核心牌
Commander／Brawl／Historic Brawl 访谈
Commander 选择

询问：“你知道想为哪位指挥官构筑套牌吗？”

如果知道：

  • 获取指挥官名称。
  • 使用 scryfall-lookup 查询，确认该牌存在。
  • 使用 Scryfall 的 is:commander 筛选器验证其是否为合法指挥官（这是指挥官合法性的权威来源——不要尝试重新实现规则）。
  • 对于 Brawl 和 Historic Brawl，还要使用 Scryfall 的 legalities 字段检查该牌在套牌所属赛制中是否合法（Brawl 对应键 standardbrawl，Historic Brawl 对应键 brawl）。
  • 检查指挥官的 Oracle 规则文本，确认是否具有 partner、friends forever 或 choose a background。若有，询问：“这位指挥官可以搭档——你有心仪的伙伴／背景吗，还是想要推荐？”以同样的方式查询并验证第二位指挥官。
  • 对于 partner／background 组合，套牌的颜色标识是两位指挥官颜色标识的合并结果。后续所有步骤都使用合并后的颜色标识。
  • 询问：“想要标准构筑，还是尝试非常规组合技，跳出常规思路？”
    • 标准： 继续回答后续共通问题。
    • 跳出常规： 继续回答后续共通问题，然后在分析指挥官后遵循“跳出常规”工作流。

如果不知道： 询问：“想探索标准套牌原型，还是尝试非常规组合技，跳出常规思路？”

  • 标准套牌原型： 继续完成下方的引导式访谈，然后使用标准工作流。
  • 跳出常规： 选择赛制并回答后续共通问题后，直接进入“跳出常规”工作流。
根据收藏选择 Commander

如果用户提供了自己拥有的牌的合集导出文件（Untapped.gg CSV、Moxfield CSV 或任何套牌列表导出文件），并希望从已有的牌中选择一位指挥官，请严格按以下步骤操作。不要临时编写 Python 来加载文件并对其调用 .get()。**注意：**合集导出文件通常包含数量为 0 的条目（用户跟踪或加入愿望清单、但并不拥有的牌）。parse-deck 会保留这些数量，而 mark-owned / find-commanders 默认会按 --min-quantity 1 筛选，因此会自动排除数量为 0 的条目。

这会缩小候选范围，但不能取代引导式访谈。仍要进行访谈——回答会影响缩小后的候选范围内的排序。

工作流程：

  1. Arena 玩家——先询问是否有合集 CSV。 如果用户提到 Arena、Brawl、Historic Brawl 或万能牌，请询问：“你有来自 Untapped.gg、Moxfield 或类似追踪工具的合集导出文件吗？包含牌名和数量的 CSV 是确认你拥有哪些牌最可靠的方式。”如果有，请继续步骤 1。如果没有合集 CSV，最后再使用 mtga-import 作为备用方案——但要提醒用户：mtga-import 会根据已保存的 Arena 套牌重建合集；由于 Arena 允许玩家用未拥有的牌组套牌，因此这种方式并不可靠。无论如何，都要始终运行 mtga-import 来提取万能牌——它会从 Player.log 中读取 InventoryInfo，以可靠地获取万能牌数量：mtga-import --bulk-data <bulk-data-path> --output-dir <working-dir>。这会写入 wildcards.json（以及它自己的 collection.json；如果工作目录中已有同名的 parse-deck 合集，mtga-import 会拒绝覆盖——请将 CSV 解析为其他文件名，例如 collection-csv.json，或者只有确实想使用根据套牌重建的合集时才传入 --force）。Linux 用户需要明确传入 --log-path。

  2. 解析合集——parse-deck <absolute-path-to-collection.csv> 会生成解析后的套牌 JSON。parse-deck 支持 Untapped.gg CSV、Moxfield CSV、Moxfield 套牌导出文件、Arena、MTGO 和纯文本。

  3. 查找指挥官候选项——find-commanders <parsed.json> --bulk-data <bulk-data-path> --format <format> --output <working-dir>/.cache/candidates.json [--color-identity <ci>] [--min-quantity 1]。务必传入 --output——默认路径位于 $TMPDIR 下，会触发工作区外的权限提示。标准输出是一个紧凑的文本表格，列包括 EDHREC 排名、颜色标识、CMC、名称、type_line、标记（PARTNER / BACKGROUND / GC），接着是 Owned pairings 列表，其中列出可共同担任指挥官的候选组合。最后一行是 Full JSON: <path>。

  4. 进行引导式访谈（颜色、玩法风格、机制、喜爱的牌、游戏群体、等级、预算），与无合集流程相同。候选范围是约束条件；访谈回答则用于区分各位指挥官。

  5. 构建包含约 5 个候选项的混合候选名单，根据访谈回答分配权重。不要只挑选 edhrec_rank 数值最低的 5 个候选项——这样给出的推荐会很乏味。目标大致如下：

    • 2 个热门候选——有充分支持（edhrec_rank 较低）、且明显符合用户所述偏好的指挥官。这些候选项是稳妥的选择。
    • 2 个非主流候选——edhrec_rank 较高或为空，但其 Oracle 文本中的机制与访谈回答相符（尤其是机制问题）。这些通常是最有趣的选项。
    • 1 个意外候选——用户可能没考虑过的选项：他们拥有的一种独特颜色组合、双方牌都已拥有的一对搭档，或能利用其合集中的牌实现连招的指挥官。
    • 控制等级筛选时，请结合 game_changer 标记和对连招密集度的判断。不要使用任何“EDHREC 等级”字段——社区等级数据由用户自行报告，可靠性较低。

  6. 根据 CLI 的回答选择搭档组合，不要凭肉眼判断。 每个候选项的 pairs_with 会列出可与其合法地共享指挥区的已拥有候选项（card_classify.can_partner：搭档与搭档、相同的搭档——[文本]组、指定的「可与……搭档」牌、背景与背景、医生的伴侣与时间领主医生；CR 702.124f——不同的搭档异能不能组合，因此幸存者牌不会与普通搭档配对）。partner_kinds 会列出每张牌的配对类别：其搭档异能（CR 702.124a），以及可与之配对的类型栏类别（背景、时间领主医生），后者本身并不是搭档异能。将有前景的配对作为万能牌或非主流选项推荐。

  7. 按照下方的“指挥官推荐”规则呈现候选名单。说明候选项已筛选为用户拥有的牌。

格式选择（指挥官／Brawl）

询问：“你要构筑什么赛制的套牌？”

  • Commander／EDH（默认）——100 张牌，40 点生命
  • Brawl——60 张牌，标准赛制牌池，25／30 点生命，没有指挥官伤害
  • Historic Brawl——100 张牌（纸牌版为 60 张），Arena／纸牌版牌池，25／30 点生命，没有指挥官伤害

**Arena 命名易混淆：**在 MTG Arena 上，“Brawl”（队列名称）实际上指 Historic Brawl，而“Standard Brawl”才是我们所说的 Brawl。如果用户说自己在 Arena 上玩 Brawl，他们几乎肯定指的是 Historic Brawl。请确认他们指的是哪种赛制。

如果是 Brawl 或 Historic Brawl：询问“你是在 Arena 上玩，还是玩纸牌版？”

  • Arena 会自动锁定套牌张数：Standard Brawl 始终为 60 张，Historic Brawl（在 Arena 上称为“Brawl”）始终为 100 张。Arena Brawl 队列始终为 1 对 1。 这会从根本上改变套牌构筑：优先考虑速度和节奏，而非政治博弈；使用更多低费的指定目标反击咒语（只需要与 1 名对手互动）、减少扫场咒语，并采用更快的费用曲线。
  • 仅限纸牌版 Historic Brawl：询问他们想用 100 张还是 60 张。纸牌版 Brawl 可以是多人游戏——使用标准的互动数量调整表。

如果是 Brawl：任何传奇鹏洛客都可以作为指挥官（不只是规则文字中写明“可以作为你的指挥官”的鹏洛客）。具有力量／防御力的载具和太空船在所有赛制中也符合资格。

**Brawl 中的无色指挥官：**如果所选指挥官的颜色标识中没有颜色，请说明套牌可以加入任意数量的一种所选基本地类别的基本地。

搭档机制适用于所有赛制。

引导式访谈（Commander/Brawl，每次一个问题）

  1. 颜色 —“你喜欢使用哪些颜色？（可任意组合，也可以回答‘没有偏好’）”

  2. 玩法风格 —“你偏好的玩法风格是什么？”列出选项，并用简短易懂的语言解释，方便新玩家理解：

    • Aggro（快速而猛烈地进攻）
    • Combo（组合卡牌，赢得游戏）
    • Control（应对威胁，在后期获胜）
    • Voltron（强化你的指挥官，造成致命伤害）
    • Tokens（铺开大量生物衍生物）
    • Tribal（围绕一种生物类别构筑）
    • Midrange/Value（持续积累优势）
    • Group Hug/Politics（结交盟友、共享资源、影响牌桌局势）

  3. 机制 —“你喜欢哪些特定机制？”提供一些带有说明的例子：“+1/+1 指示物（让你的生物逐渐成长）、偷取（偷走对手的牌）、闪现（让生物闪烁以重复使用其效果）、法术连发（施放大量瞬间和法术力）、神器主题、地落（因使用地而获得奖励）。”允许开放式回答。如果回答可能对应多个不同的子类型，请追问一个问题以进一步确认。

  4. 喜爱的牌/系列 —“有没有你喜欢的牌或让你感到兴奋的新系列？这有助于我寻找设计思路相似的指挥官。”

  5. 游戏小组的风格 —“你们的游戏小组通常如何进行游戏？（休闲/竞技、连招为主、生物为主、互动较多）”

  6. 强度等级 —“你希望达到哪个强度等级？（1-4，或休闲/中等/高/最高）”

  7. 预算 —“这副牌的总预算是多少？（金额，或 Arena 的外卡数量）”

指挥官推荐

完成引导式访谈后，推荐 3-5 个符合要求的指挥官。搭档组合以及指挥官 + 背景组合均可作为推荐；请将每组搭档作为一个选项展示，并标明其组合后的颜色标识。你可以使用训练数据生成候选列表——这是在发现指挥官，而不是评估卡牌，因此此阶段不适用铁律。不过，展示前必须通过 scryfall-lookup 验证每位推荐的指挥官。

每项推荐应包含：

  • 牌名和颜色标识
  • 简要说明其符合用户偏好的原因
  • EDHREC 牌组数量（如有），以体现社区支持度
  • 值得注意的预算影响

让用户选择。

通用问题（Commander/Brawl）

询问以下所有问题（已在引导式访谈中回答的可跳过）：

  • 强度等级：“你希望达到哪个强度等级？（1-4，或休闲/中等/高/最高）”
  • 预算：“这副牌的总预算是多少？（金额，或 Arena 的外卡数量）”
  • 经验水平：“你的 Commander 经验水平如何？（初级/中级/高级）”
  • 必带牌：“有没有你一定想加入的牌？”（个人偏爱的牌、想围绕其构筑的连招）

对于必带牌：将所有牌名写入一个 JSON 列表，并在一次调用中批量查询：scryfall-lookup --batch <pet-cards.json> --bulk-data <bulk-data-path> --cache-dir <working-dir>/.cache。验证每张牌都存在，且符合指挥官的颜色标识。将必带牌放入相应的模板类别——它们会占用这些类别的配额。如果必带牌超过约 10 张，请提醒用户，这会限制构筑均衡框架的空间。

搭档检查（仅限 60 张牌）

采访结束后，检查牌组的限制是否天然适合某个搭档。搭档很强大（可保证多一张牌），应主动考虑：

  1. 使用 card-search --format <fmt> --bulk-data <path> --oracle "Companion" --type "Creature" 查找符合赛制规则的搭档
  2. 对每个搭档，检查用户的玩法风格／颜色／曲线是否天然符合其构筑限制（例如，Lurrus 要求牌组中不能有法术力值大于 2 的永久物——这很适合低曲线快攻）
  3. 如果某个搭档合适，向用户建议：“你的牌组天然符合 Lurrus 的限制——你想让它担任搭档吗？它能保证多一张牌。”
  4. 如果用户接受，在骨架生成时将搭档的限制记为硬性约束
  5. 搭档占用 15 个备牌栏位中的 1 个
  6. Yorion 要求牌组为 80 张——若选择 Yorion，请使用 parse-deck --deck-size 80
经验水平判断

根据回答推断。如果不明确，直接询问：初级、中级还是高级？

水平访谈深度讲解风格
初级讲解赛制基础，定义套牌类型使用完整句子和类比
中级假设了解赛制简洁说明关键互动
高级假设具备深入知识使用表格和简写，聚焦新颖思路
宠爱牌验证

如果用户提供了宠爱牌：

  1. 使用 scryfall-lookup --batch 验证牌是否存在及其 Oracle 文本
  2. 检查赛制合法性（legalities.<format> 字段）
  3. 对于 Commander／Brawl：验证牌是否符合指挥官的颜色特征
  4. 记录它们的作用（威胁、去除、引擎等），以便分配到骨架栏位
研究（路径 B）
60 张牌：环境研究
已验证套牌类型路径
  1. WebSearch 搜索 "<format> metagame 2026" 或 "<format> tier list"，查找当前主流套牌类型
  2. 使用 WebFetch（或在网站阻止机器人时使用 web-fetch）获取排名靠前的结果，了解套牌类型名称及环境占比
  3. 展示排名前 5-8 的套牌类型及其大致环境占比
  4. 如果用户偏好某种颜色／玩法风格，突出显示匹配的套牌类型
  5. 让用户选择套牌类型
  6. WebSearch 搜索 "<archetype name> <format> decklist 2026"，查找示例牌表
  7. 使用 WebFetch 获取示例牌表——它将作为骨架基础。如果 WebFetch 受阻，则使用 web-fetch 脚本作为后备方案（浏览器标头 + curl 后备方案）。
  8. 如果找到示例牌表，将其解析为：parse-deck --format <fmt> <path> --output <working-dir>/deck.json
  9. 补全数据：deck-hydrate <working-dir>/deck.json [--bulk-data <path>]

如果无法获取示例牌表，则采用后备方案：

  • 请用户直接粘贴牌表——大多数玩家都能从 MTGGoldfish、Moxfield 或类似网站复制牌表
  • 如果用户无法提供牌表，则转到下方的原创／非主流路径，并以套牌类型名称为线索，从头开始构筑 card-search 查询
原创／非主流路径
  1. 以用户的玩法风格、颜色和宠爱牌作为起始约束
  2. 使用 card-search --format <fmt> --bulk-data <path> --oracle "<keyword>" --color-identity <colors> 查找构筑核心牌
  3. 使用 combo-discover 查找这些颜色下的组合技框架
  4. WebSearch 搜索 "<format> <archetype/mechanic> deck" 获取灵感
  5. 不使用示例牌表作为基础，直接进行骨架生成
组合技优先路径
  1. 根据组合技／构筑核心发现中选定的组合技，确定最小框架：
    • 组合技组件（必需牌）
    • 能找到组合技组件的导师牌（通过 card-search 查找符合赛制规则的导师牌）
    • 保护组合技组装的牌（反击咒语、弃牌、辟邪）
  2. 确定最佳颜色（组合技颜色 + 支援牌的可用性）
  3. 继续进行组合技优先的骨架生成
指挥官：指挥官分析

  1. Scryfall 查询 — 运行：scryfall-lookup "<Commander Name>"

    阅读完整的 Oracle 文本、颜色标识、CMC 和类别。对于伙伴／背景组合，查询两位指挥官，并记录他们之间的配合方式。

  2. EDHREC 调研 — 运行：edhrec-lookup "<Commander Name>"

    对于伙伴指挥官：edhrec-lookup "<Commander 1>" "<Commander 2>"

    查看热门牌、高协同牌和主题。**Brawl／Arena 注意事项：**EDHREC 数据来自 Commander／EDH 套牌。对于 Brawl／Historic Brawl，在加入推荐牌之前，必须根据套牌赛制检查其合法性。对于 Arena 套牌，还需确认这些牌存在于 Arena 上。

  3. 网络调研 — 使用 WebSearch 搜索指挥官名称以及 "deck tech"、"strategy"、"guide"。使用 WebFetch 或辅助脚本阅读策略文章：

    运行：web-fetch "<url>" --max-length 10000

  4. 策略综合 — 总结指挥官的核心机制、主要策略和协同方向。对于伙伴／背景组合，说明两位指挥官分别如何助力策略，以及他们的机制在哪些方面重叠或互补。向用户展示结果以供确认。如果用户暂不决定或没有偏好，则默认采用 EDHREC 上最受欢迎的指挥官主题并继续。

目标是充分了解情况，以便合理填充各类别，而非进行深入分析（第二阶段会处理）。

EDHREC 回退方案

如果 EDHREC 中没有该指挥官的数据（例如新牌或冷门牌），则改用：

  1. 本地海量卡牌数据搜索 — 使用 card-search，在指挥官的颜色标识范围内查找与其关键词／Oracle 文本有机制协同的牌。对于 Arena 套牌，使用 --arena-only。对于纸牌版 Brawl，使用 --paper-only 排除仅限 Arena 的数字牌。
  2. EDHREC 主题／原型数据 — 查询该指挥官所属原型，而非特定指挥官。对于 Brawl／Historic Brawl，根据套牌赛制检查推荐牌的合法性。
  3. 赛制常用牌 — 用该颜色标识和等级的知名常用牌填充剩余位置。
跳出常规路线（仅限 Commander）
机制／结果访谈（尚未确定指挥官）

提问（接受其中一项或多项回答）：

  • “哪些机制让你感兴趣？”（开放式问题——对应到 card-search 的 Oracle 文本模式和 combo-discover --card 查询）
  • “你想要什么样的结果？”（对应到 combo-discover --result 查询，例如“无限衍生物”“无限法术力”“磨掉整个牌库”）
  • “对颜色有偏好吗？”（或“没有偏好”）
  • “你想尝试多冷门的组合？”（有点特别／非常冷门／能找到的最疯狂组合）
  • “你的组合最多能用多少张牌？”（精简的 2-3 张牌组合／允许更大的组合／完整的鲁布·戈德堡式组合）

根据用户输入采用两种发现策略：

  1. **机制优先：**使用 card-search 根据 Oracle 文本查找符合机制的牌，然后将牌名传给 combo-discover --card "X" --card "Y"
  2. **结果优先：**直接使用 combo-discover --result "Infinite X"
  3. **两者结合：**组合使用 --result 和 --card 筛选条件

冷门程度与受欢迎程度的对应关系：

  • 有点特别：--sort -popularity，跳过排名最靠前的结果，受欢迎程度为 1000-10000
  • 非常冷门：--sort popularity，跳过 0，受欢迎程度为 100-1000
  • 能找到的最疯狂组合：--sort popularity，受欢迎程度为 0-100

Jank 程度与组合最大规模：

  • 精简：筛选出 3 张牌或更少的组合
  • 允许更大的组合：4-5 张牌
  • 完整的鲁布·戈德堡式组合：不设限制
组合技发现（两种路径）

对于指挥官已知 + 跳出常规思路：使用 combo-discover --color-identity <commander-CI>，将搜索范围限制在指挥官的颜色身份内。

展示前，将所有组合技中的组件名称写入一个 JSON 列表，并通过一次调用批量查询：scryfall-lookup --batch <combo-pieces.json> --bulk-data <bulk-data-path> --cache-dir <working-dir>/.cache。

展示 3-5 个有趣的组合技，并包含：

  • 涉及的卡牌及其 Oracle 文本（来自批量查询结果）
  • 组合技的产出
  • 颜色身份
  • 热门度评分（数值越低越冷门）
  • 卡牌数量（衡量偏门程度的指标）
  • 对每个组合技组件：说明其单独使用时的作用。脱离组合技后毫无用处的组件存在风险——请标记出来。

询问：“想围绕其中一个构筑，还是组合多个？”如果要组合多个，请确认颜色身份兼容。

指挥官适配（若已知指挥官则跳过）

对每个选定的组合技进行两轮搜索：

  1. 机制适配： card-search --is-commander --color-identity <combo-CI> --oracle "<combo-keyword>" — 搜索 Oracle 文本中提及组合技机制的指挥官
  2. 策略适配： 使用训练数据，筛选出在组合技颜色身份内能提供搜寻、抓牌、返场或保护的指挥官。将所有入围名称写入一个 JSON 列表，并进行批量查询：scryfall-lookup --batch <fit-candidates.json> --bulk-data <bulk-data-path> --cache-dir <working-dir>/.cache（适用铁律）。

还要检查是否有组合技组件本身就是可以担任指挥官的传奇生物。

展示 2-3 个指挥官选项，并说明：

  • 指挥官在机制上如何支持组合技
  • 指挥官是否带来次要策略方向
  • EDHREC 数据（如果有；冷门指挥官的数据可能较少）

用户选择组合技 + 指挥官的搭配。

骨架生成（路径 B）
60 张构筑赛
起点
  • 成熟的套牌原型及示例牌表： 根据用户的偏好、预算和心仪卡牌定制示例牌表。这属于修改，而不是从零开始构筑。
  • 原创／非主流或优先考虑组合技： 使用下方模板从零开始构筑。
类别模板（主牌 60 张）
类别典型数量说明
威胁／生物12-28因套牌原型而差异很大（快攻：28，控制：4-8）
去除／互动4-12取决于赛制；较慢的赛制中数量更多
卡牌优势4-8抓牌咒语、鹏洛客、筛选
实用／灵活卡位2-8套牌原型专属支援
地20-27构筑赛地牌公式（见下文）

这些数量仅供参考，并非规则。 快攻套牌更偏重威胁；控制套牌更偏重互动和卡牌优势。数量平衡由套牌原型决定。

地牌数量公式

使用构筑赛地牌目标公式：

  • 基准： 60 张套牌使用 24 张地
  • 加速调整： 每 2 张加速／法术力加速牌减少 1 张地
  • 曲线调整： 曲线较低（平均法术力值 < 2.5）-> 减少地牌；曲线较高（平均法术力值 > 3.5）-> 增加地牌
  • 上下限： 不得少于 20 张，也不得多于 27 张

构筑完成后运行 mana-audit 进行验证。

地牌基础构成
地牌类型预算型中端高端
基本地10-166-102-6
双色地（震地、速攻、检视）4-88-128-12
搜地00-48-12
功能地0-22-42-4

对于 Arena 赛制：可使用 Khans 搜地（Pioneer 及更高阶赛制），但不能使用 Zendikar/Onslaught 搜地。使用 Arena 可用的法术力基础（震地、速攻地、路径地、三色地，以及 Pioneer/Historic/Timeless 可用的 Khans 搜地）。

颜色配置指南（60 张牌）

地牌数量公式给出的是总数，但颜色配比同样重要。使用 mana-audit 输出（法术力符号需求百分比 vs. 地牌产出百分比）进行验证，并遵循以下经验法则：

  • 单色： 全部使用基本地（加上 2-4 张功能地）。这是最简单的法术力基础。
  • 双颜色： 让地牌产出与法术力符号需求相匹配。如果套牌中 60% 的法术力符号是红色、40% 是白色，就以大约 60/40 的红色/白色来源为目标。使用约 8 张双地加上主色基本地，通常就够了。
  • 三色及以上： 仅靠基本地无法可靠地支持 3 种颜色。双地几乎必不可少。在预算允许的情况下，优先选择能进场未横置并产出 2 种或更多套牌颜色的地（震地、快地、三色地）。常见误区是在三色套牌中使用过多基本地——如果 mana-audit 标记某种颜色的来源不足超过 5%，就用能产出该颜色的双地替换基本地。
  • 辅助色（5-8 个法术力符号）： 通常需要 4-6 个辅助色来源。路径地或也能产出主色的双地是理想选择。
  • 关键回合的未横置来源： 快攻套牌在第 1-3 回合几乎需要所有地牌都未横置进场。控制套牌可以容忍更多横置进场的地，因为它们会在法术力值较高时运作。
填充流程（60 张牌）

对于每个类别：

  1. 如果从示例牌表开始，评估其中已有的牌
  2. 使用 card-search --format <fmt> --bulk-data <path> --oracle "<pattern>" --color-identity <colors> 搜索候选牌
  3. 使用 scryfall-lookup --batch 验证所有候选牌的 Oracle 文本
  4. 根据预算筛选（实体牌：价格；Arena：万能牌稀有度）
  5. 将个人偏爱的牌纳入合适的类别
  6. 优先选择赛制常用牌和已验证的强牌
4 张还是更少
  • 4 张： 希望每局都能抽到、且对策略至关重要的牌
  • 3 张： 强力牌，希望大多数对局都能抽到，但不需要多张
  • 2 张： 情境牌、传奇永久物、曲线顶端牌
  • 1 张： 针对特定威胁的牌、导师目标、高影响力单张牌
构建备牌（仅限 Bo3）

备牌由 15 张牌组成，旨在提升第一局之后的对局表现。

流程：

  1. 确定当前环境中的 3-5 个主流原型（通过研究）
  2. 对于每个劣势对局，分配 2-4 个备牌位置：
    • 针对快攻：生命回复、低费去除、扫场
    • 针对控制：低费威胁、反击咒语、卡牌优势
    • 针对组合技：干扰、反击咒语、坟场针对牌
    • 针对坟场：card-search --format <fmt> --bulk-data <path> --oracle "exile.*graveyard"
    • 针对神器/结界：card-search --format <fmt> --bulk-data <path> --oracle "destroy.*artifact"
  3. 优先选择能应对多种对局的灵活牌
  4. 通过 scryfall-lookup 验证所有备牌都符合赛制规则

备牌数量：

  • 2-3 张狭隘针对牌（坟场针对牌、神器去除）
  • 3-4 张灵活解牌（额外去除、反击咒语）
  • 1-2 张替代胜利条件或变身牌
组合技优先的框架（60 张牌）
  • 先放入组合技组件（必备牌）
  • 使用 card-search 查找：能找到组合技组件的导师、保护组合技组装的牌、冗余效果
  • 围绕组合技核心填充其余类别（威胁、去除、卡牌优势、地牌）
  • 适用标准结构验证
指挥官/Brawl/Historic Brawl
默认模板

卡牌数量会随套牌规模调整。以下基准数量适用于 100 张牌的套牌；对于 60 张牌的套牌，将每项数量乘以 0.6 并四舍五入到最接近的整数。

类别100 张牌60 张牌说明
指挥官1-21-2已选定
地36-3822-23按比例缩放 Burgess 公式：round((31 + colors + effective_commander_cost) * deck_size / 100) — 从 mana-audit 的 land_band 中读取，不要手动计算（ADR-0044：对于会自我减费的指挥官，例如 The Lord of the Eagles 或 Ghalta，该工具使用指挥官的有效费用，即套牌预计能支付该费用的最早回合，而不是印刷的法术力值）
加速106法术力石、法术力小生物、找地咒语
抽牌106优先选择符合策略的抽牌方式
定向去除／干扰5-123-7根据套牌的定位调整 — 从 deck-tune 的 template 中读取范围
清场2-51-3根据套牌的定位调整 — 从 deck-tune 的 template 中读取范围
获胜手段3-52-3能结束对局的牌
引擎／协同组件15-209-12能配合指挥官的牌
保护／功能牌8-105-6反击咒语、辟邪、返场
模板灵活性

以上各类别的数量是默认值 — 在策略验证后，根据用户确认的方向进行调整。示例：

  • 武装指挥官： 增加保护／功能牌，将引擎栏位转向装备／灵气
  • 连招： 增加抽牌和获胜手段，加入导师栏位
  • 快攻／衍生物： 减少清场（它们也会伤到你），增加引擎组件
  • 控制： 全面增加互动，减少引擎组件
  • 群体增益／政治： 减少定向去除，增加政治工具作为功能牌

不可调整的硬性要求： 无论策略如何，地和加速都必须达到 Burgess 公式的最低数量。总牌数必须符合套牌的预期规模（指挥官／Historic Brawl 为 100 张，Brawl 为 60 张，或用户指定的数量）。

地基构成（指挥官／Brawl）

地的数量由 Burgess 公式决定，但构成同样重要。指南：

  • 基本地： 数量应足以供加速咒语（Cultivate、Kodama's Reach 等）寻找，并避免受到 Blood Moon／Back to Basics 的惩罚。单色／双色套牌应更多采用基本地。
  • 修色： 根据预算和颜色数量调整：
    • 预算（$25-75）： 增益地、神殿（占卜地）、三色地、检视地、痛地
    • 中等（$75-200）： 加入滤色地、战场地、通路地、护符
    • 高（$200+）： 若预算允许，加入震地、找地地、原版双色地
  • Arena 万智牌替代卡牌等级： 对于 Arena 套牌，忽略美元预算等级，按替代卡牌稀有度规划：
    • 替代卡牌紧缺： 多采用非普通地（增益地、检视地、侦察地、三色地）。接受部分横置进场的地。
    • 替代卡牌适量： 为最重要的颜色组合加入稀有的非横置双色地（震地、快地、羁绊地）。
    • 替代卡牌充足／高强度等级： 配齐稀有的非横置双色地；部族套牌可加入 Cavern of Souls，若赛制允许，也可加入找地地。
  • 功能地（2-4）： 与策略协同的地。不要加入过多 — 横置进场或产无色法术力的功能地会损害稳定性。单色和双色套牌应避免只产无色的功能地，除非其功能直接支持指挥官的策略。
  • Command Tower： 双色及以上套牌自动加入。单色套牌中，Command Tower 严格劣于基本地 — 它不能被加速咒语寻找，也没有基本地类别。请改用基本地。
  • Sol Ring： 纸牌版指挥官／EDH 自动加入。Brawl 或 Historic Brawl 中不合法。

填入卡牌后运行 mana-audit，以验证颜色平衡。

互动密度

牌组需要多少互动牌取决于其形态（激进／中速／控制／组合技），而非强度档位（ADR-0024）。请从 slot-budgets 或 deck-tune 的 template 行（interaction、board_wipe）读取各档位。“干扰”——反击咒语、弃牌、税效组件——与生物／神器去除牌一样，都计入互动牌。额外的互动牌位应从引擎／协同预算中扣除。档位决定的是许可范围（强力牌、广泛土地破坏、额外回合、双牌组合技），而不是密度。

填充流程（Commander/Brawl）

受外卡限制的路径（Arena，稀有 + 秘稀外卡总数不足 10 张）： 当用户的稀有 + 秘稀外卡预算总数少于 10 张时，反转填充策略。不要先拟定理想牌张再检查持有情况，而应先在用户的收藏中搜索符合各类别的已有牌。外卡只用于补齐关键缺口的普通和非普通牌。

类别填充顺序很重要。 先填充基础类别：

  1. 地
  2. 加速
  3. 抽牌
  4. 指定去除和扫场
  5. 保护／功能牌
  6. 引擎／协同组件
  7. 制胜条件

各类别的处理方式：

  1. 从 EDHREC 上该指挥官的高协同牌和热门牌中提取候选牌。再用 card-search 搜索 EDHREC 可能未展示的协同牌。Arena 牌组使用 --arena-only，并省略 --price-max。纸牌 Brawl 使用 --paper-only，以排除仅限 Arena 的数字牌。
  2. 批量查询所有候选牌的 oracle 文本——将候选牌名称写入 JSON 列表，然后运行：scryfall-lookup --batch <candidates.json> --bulk-data <bulk-data-path> --cache-dir <working-dir>/.cache。运行 card-summary <cache_path> 查看精简表格。只对实际需要比较的约 3–5 张候选牌，使用 offset／limit 读取完整缓存文件。
  3. 按预算筛选（选择最便宜的印次，并跟踪累计价格）。对于 Arena，则改为跟踪外卡稀有度数量。
  4. 按档位筛选（目标档位以上避免使用强力牌）。
  5. 根据访谈中了解的偏好调整权重。
  6. 根据指挥官协同度（来自分析步骤）调整权重。
  7. 加入用户要求的任何心头好牌。
  8. 用符合颜色标识和预算的赛制常用牌填满剩余牌位。
组合技优先骨架（Commander）
  • 优先放入组合技组件（它们是这副牌存在的理由）
  • 使用 card-search 查找辅助牌：能找到组合技组件的导师牌、保护组合技组件的牌，以及效果冗余的牌
  • 记录哪些组合技组件兼具其他用途，哪些脱离组合技后毫无作用
  • 填充其余类别（加速、抽牌、去除、地），优先选择与组合技机制相契合的牌
  • 仍需执行标准结构验证
结构验证（路径 B）

按顺序运行全部四项检查。如果有任何一项未通过，请修正后从头复查——每个 CLI 都会自动根据编辑后的牌组重新载入数据。

1. 合法性审计（必须通过）
legality-audit <deck.json> [--bulk-data <path>]

检查内容：赛制合法性、复制数量限制（Commander/Brawl 为单例规则；构筑赛制为 4 张规则 + Vintage 限制牌规则）、备牌数量（构筑赛制最多 15 张）、牌组最低数量。继续之前，修复所有违规项。

Commander/Brawl 注意事项： Historic Brawl 禁用许多 Commander 常用牌（Sol Ring、Skullclamp、Hour of Reckoning、Triumph of the Hordes 等）——如果按 Commander 的思路构筑，这些牌看起来显然应该加入——此项检查会将其检出。颜色标识违规通常意味着有牌绕过了指挥官的颜色标识检查。

2. 价格检查（必须符合预算）
# Paper
price-check <deck.json> --budget <budget> --bulk-data <path>

# Arena
price-check <deck.json> --format <fmt> --medium digital --bulk-data <path>

如果超出预算，请用预算替代牌替换昂贵牌。更改后重新运行。对于 Arena，“最贵”指稀有度最高——将稀有牌换成非普通牌。留意 illegal_or_missing 警告行，检查有哪些牌漏过了合法性审计。

3. 牌组统计（核对数量）
deck-stats <deck.json> [--bulk-data <path>]

核对：卡牌总数是否符合预期大小，地牌数量是否符合公式目标，类别分布是否合理，备牌数量是否为构筑赛制的 0-15 张。

4. 法术力审查（必须通过或警告）
mana-audit <deck.json> [--bulk-data <path>]

指挥官／Brawl 使用 Burgess/Karsten 公式，60 张牌赛制使用构筑赛制地牌公式。检查地牌数量和颜色平衡。失败意味着必须先修正法术力基础才能继续。

这是一个关卡——如果未通过任何一项检查，就不要提交牌组骨架。 如果任何检查未通过，而你编辑牌组进行了修正，请从头重新解析并重新运行所有检查——每个工具都会自动基于编辑后的牌组重新加载数据，因此无需单独刷新缓存。

提交牌组骨架（路径 B）
60 张构筑赛制的展示方式

按类别列出，并附上简短的协同说明：

## Creatures (24)
4 Monastery Swiftspear — hasty one-drop, prowess triggers off spells
4 Eidolon of the Great Revel — punishes low-curve opponents
...

## Instants/Sorceries (16)
4 Lightning Bolt — premium removal + face damage
...

## Lands (20)
8 Mountain
4 Inspiring Vantage — untapped on turns 1-3
...

备牌（仅 Bo3）：

## Sideboard (15)
3 Roiling Vortex — vs. free spells, lifegain decks
2 Rampaging Ferocidon — vs. token/lifegain strategies
3 Smash to Smithereens — vs. artifact-heavy decks
...
指挥官／Brawl 的展示方式

按构筑器的类别组织内容（地牌、加速、抓牌、去除、清场、获胜手段、引擎／协同、防护／功能牌）。简要说明为何加入了关键协同卡牌。

摘要区块
Mainboard: 60 cards | Lands: 20 | Avg CMC: 1.85
Sideboard: 15 cards
Budget: $45.20 / $50.00 (paper) or 2M/4R/8U/12C (Arena wildcards)

对于指挥官／Brawl，显示：

  • 卡牌总数
  • 地牌数量和 Burgess 公式目标
  • 预计总费用与预算的对比（纸牌使用 USD，Arena 使用外卡表格）
  • 类别明细

对于 Arena 牌组，提供外卡费用表：

稀有度骨架费用预算剩余
秘稀XYZ
稀有XYZ
非普通XYZ
普通XYZ
询问是否需要调整

提交牌组骨架并询问：“在继续调优之前，你想做任何调整吗？”

如果用户要求更改，请应用更改，重新运行结构验证，然后再次提交。

写入输出文件（路径 B）
  1. 牌组 JSON：<working-dir>/<deck-name>.json
  2. 导入文本：export-deck <deck.json> -> <working-dir>/<deck-name>-export.txt（Arena 格式会自动添加 Commander / Deck 标题；Moxfield 可读取这两种布局）
  3. 已在 <working-dir>/<deck-name>.hydrated.json 中生成 hydrated sidecar，由最先运行的 CLI 构建（或通过 deck-hydrate 显式构建）

提交后并获得用户批准，即可进入 阶段 2：调优。

阶段 2：调优

两条路径在此汇合。牌组 JSON 已就绪；每个工具都会根据需要通过 sidecar 自行加载数据。

步骤 1：基线指标

按以下顺序运行（先运行成本最低、最容易发现问题的检查）：

1. 合法性审查
legality-audit <deck.json> [--bulk-data <path>]

检查：赛制合法性、同名牌数量限制（指挥官赛制为单卡限制，60 张牌赛制为 4 张上限 + Vintage 限制牌）、备牌大小、牌组最低张数、颜色标识（指挥官赛制）。必须通过才能继续。如果失败，请列出违规项并询问用户如何修正。

2. 牌组统计
deck-stats <deck.json> [--bulk-data <path>]

检查：卡牌总数、地牌数量、生物数量、加速数量、平均 CMC、费用曲线分布、备牌总数（60 张牌赛制）。注意任何明显的问题。如果卡牌总数与牌组预期大小不符，请立即标记。

检查 alternative_cost_cards 部分。对于任何具有替代费用的卡牌（延缓、历险、预兆等），请注明这副牌组中最可能使用的费用。不要仅根据这些卡牌的 CMC 进行评估。每一行的 cost_kind 都会说明支付方式：alternative（代替法术力费用支付——诸如呼魂、返照、扭曲，以及变身牌的背面朝下 {3}）、additional（在原费用之外支付——诸如返场、回返的弃地费用）、alternative_characteristics（原型的较低法术力费用和身材）、special_action（延缓和计划需要先将其放逐，之后才能免费施放；将变身牌翻回正面）、ability（忍术无需施放即可将其置于战场上），或 other_face（历险牌或双面牌的另一面）。

3. 卡牌摘要
card-summary <deck.json> --nonlands-only
card-summary <deck.json> --lands-only
card-summary <deck.json> --sideboard   # 60-card only

扫描主牌（60 张牌赛制还需扫描备牌）的 Oracle 规则文本。标记具有替代费用的卡牌，以便调整 CMC 评估。

4. 法术力审计
mana-audit <deck.json> [--bulk-data <path>]

记录地牌数量状态（PASS/WARN/FAIL）和颜色平衡。指挥官赛制使用 Burgess/Karsten 公式，60 张牌赛制使用构筑赛公式。

5. 伙伴检查（仅限 60 张牌）

检查备牌中是否有伙伴牌（card-summary <deck.json> --sideboard，并查找 Companion 关键词）。如果有，记录其套牌构筑限制——所有建议的更改都必须继续满足该限制。

如果没有伙伴，则检查套牌是否自然满足某个伙伴的限制。伙伴足够强力，因此如果套牌意外满足某个伙伴的条件（例如，低曲线快攻套牌满足 Lurrus 的“不能有法术力值大于 2 的永久物”限制），就应该积极考虑加入它。使用 card-search --format <fmt> --bulk-data <path> --oracle "Companion" --type "Creature" 查找候选牌，然后根据当前套牌检查其限制。如果有合适的牌，在步骤 6 中建议加入（会占用 1 个备牌位）。

第 2 步：了解用户需求

路径 A（调整现有套牌）

通过 AskUserQuestion 提问：

通用问题
  1. 经验水平——初级 / 中级 / 高级
  2. 升级预算——用于调整的美元预算或外卡预算
  3. 最多调整数量——你愿意更换多少张牌？
  4. 痛点——哪些对局感觉不理想？你注意到哪些问题？或者只是“整体优化”？
60 张牌构筑赛
  1. 一局定胜负还是三局两胜？——仅限 Arena；纸牌对局跳过。如果是 Bo1，备牌调整无关紧要——完全专注于主牌。跳过步骤 6f（备牌评估）和步骤 12 中的备牌指南。
  2. 目标——竞技天梯、FNM 还是锦标赛？
指挥官/Brawl/Historic Brawl
  1. 强度档位——1-5，或休闲/核心/升级/优化/cEDH
  2. Arena 还是纸牌对局？——如果不清楚，对于 Brawl/Historic Brawl，询问是在 Arena 上还是进行纸牌对局。

相关时应提及的赛制特定背景：

  • **Brawl/Historic Brawl：**没有指挥官伤害（Voltron 策略较弱），起始生命为 25（双人对局）或 30（多人对局），而非 40；首次调度免费
  • **Brawl：**使用标准赛牌池——许多指挥官赛制常用牌不合法。无色指挥官可以加入任意数量、但仅限所选类型的基本地牌。
  • **Historic Brawl：**使用 Arena Brawl 牌池——比标准赛更广，但禁牌表与指挥官赛制不同
  • **Arena Brawl 队列始终是 1v1。**优先考虑速度和节奏，而非政治博弈；按 1v1 战斗（而非多人桌对局动态）评估卡牌；预计会遇到更多反击咒语和针对性去除，以及更少的清场咒语。纸牌 Brawl 可能是多人对局——使用常规的缩放方式。
Arena 外卡预算

对于 Arena，使用简洁记法：NM/NR/NU/NC（例如，2M/4R/8U/12C = 2 张秘稀、4 张稀有、8 张非普通、12 张普通外卡）。

如果用户运行过 mtga-import，在询问预算前先检查工作目录中是否有 wildcards.json。

路径 B（从头构筑）

确认从阶段 1 延续的背景信息：赛制、平台、Bo1/Bo3（60 张牌）或强度档位（指挥官）、预算（总额/已花费/剩余）、经验水平、原型、伙伴（如有）以及最多调整数量。不要重复询问已回答的问题。

从路径 B 进入时，记录总预算和升级预算（总预算减去骨架牌组成本）。分析期间的换牌决策使用升级预算。单独跟踪用户已拥有的牌——它们不计入上述任一预算。

**路径 B 默认值：**对于新搭建的骨架牌组，建议最多调整 15-20 张牌（用户可调整）。除非用户在阶段 1 提出具体问题，否则痛点默认为“整体优化”。

第 3 步：调研

竞技场天梯套牌：优先使用 arena-meta

对于为竞技场队列（Standard、Pioneer、Historic、Timeless、Alchemy、Historic Brawl 或 Competitive Brawl 的数字版）构建的套牌，天梯本身就是研究资料。先运行它，再进行任何网络搜索：

arena-meta --deck <deck.json> [--bo3] --collection <collection> --wildcards <allowance>

它会读取 Untapped.gg 针对该套牌队列的 Premium 元环境数据（默认从 Platinum 及以上段位获取；使用 --ranks 更改），数据来自与 deck-tune 共享的 24 小时缓存（ADR-0059）：

  • 环境分布：各元环境套牌原型在对局中的占比，即这套牌会遇到什么对手；
  • 排名：根据胜率的 Wilson 下界对元环境套牌原型排序，并附有 Mythic 列；
  • 这套牌的元环境套牌原型（Brawl 天梯按指挥官判定，60 张牌套牌按非地牌重合度判定）及其核心：大多数同原型套牌都会使用的卡牌及其平均张数；
  • 在通配符数量范围内，依照你的收藏可构建的套牌列表。

会话中首次运行时，可能会提示需要登录。请让用户运行 arena-meta --login（! uv run arena-meta --login），这会打开浏览器，让他们登录 Untapped 账户一次。

随后，deck-tune 默认读取同一缓存（--meta auto）。某张牌出现在该元环境套牌原型的套牌列表中的比例低于 5%，则是价值较低的候选移除牌；缺少核心卡牌会产生 meta_core_missing 添加问题；评分卡的 meta 部分会同时列出这两类信息。网络搜索仍是纸牌游戏路径，也是了解数据所示内容背后“原因”的来源。

60 张牌构筑赛制
路径 A：完整研究
元环境背景
  1. 使用 WebSearch 搜索 "<format> metagame 2026" 或 "<format> tier list"
  2. 使用 WebFetch 获取排名靠前的结果，了解当前元环境概况
  3. 确定：排名前 5 的套牌原型有哪些？这套牌属于哪种？预期的优势和劣势对局是什么？
特定套牌原型研究
  1. 使用 WebSearch 搜索 "<deck archetype> <format> sideboard guide" 和 "<deck archetype> <format> matchup guide"
  2. 使用 WebFetch 获取策略文章，了解备牌计划和对局分析
  3. 将用户的套牌列表与该套牌原型的常见／优化版本进行比较
路径 B：验证检查

第一阶段已完成研究。验证其与元环境的契合度，而不是重复研究：

  1. 确认第一阶段的元环境背景仍是分析依据
  2. 记录影响调整优先级的套牌原型专项研究发现
  3. 除非用户提出了新的疑虑，否则跳过重复的 WebSearch/WebFetch
Commander/Brawl/Historic Brawl
路径 A：完整研究
EDHREC + 网络策略

运行：edhrec-lookup "<Commander Name>"

双指挥官：edhrec-lookup "<Commander 1>" "<Commander 2>"

另外，使用 WebSearch 搜索指挥官名称加上 "deck tech"、"strategy"、"guide"，查找 Command Zone、MTGGoldfish 以及其他内容创作者的分析。

获取策略文章： 首先使用 WebFetch。如果返回空的 JS 外壳或只有导航内容，则改用辅助脚本：

运行：web-fetch "<url>" --max-length 10000

重要原则： 研究提供参考，但不应成为定论。EDHREC 上的高人气并不代表某张牌就一定合适，不受欢迎也不代表它不合适。

组合技探索（可选）： 如需深入探索 combo-search 所展示的内容之外的组合技，可使用 combo-discover 查找套牌能够实现的组合技路线。可按套牌中已有的卡牌搜索（--card "Key Card"），也可按期望的结果搜索（--result "Infinite X"）。

Brawl 赛制说明： EDHREC 数据来源于 Commander/EDH 套牌。调整 Brawl 套牌时，推荐的 EDHREC 卡牌必须先根据套牌赛制检查合法性，再进行推荐。使用 card-search --format <format> --bulk-data <path> 验证候选牌是否合法。对于 Arena 套牌，还要使用 --arena-only。

路径 B：验证检查

第一阶段已完成指挥官分析。验证契合度，而不是重复分析：

  1. 确认第一阶段的 EDHREC 发现和策略综合结论
  2. 记录影响调整优先级的关键协同方向
  3. 除非用户提出了新的疑虑，否则跳过重复的 EDHREC/WebSearch
组合认知（所有赛制）
combo-search <deck.json> [--bulk-data <path>]

展示已有的组合技和差一点成型的组合技。指出哪些差一点成型的组合技可以通过加入 1 张牌来完成。

在推荐任何差一点成型的组合技作为新增牌之前，先从组合技搜索 JSON 中使用 offset/limit，Read 该组合技完整的 description 字段。精简文本报告只显示牌张列表和结果；JSON 中的 description 会说明启动顺序，并且经常会提到牌张列表中没有列出的其他必需组件。未阅读其描述就推荐差一点成型的组合技，违反铁律。

使用 WebSearch 补充（60 张构筑）： combo-search 使用 Commander Spellbook，该数据库主要由 Commander 玩家通过众包贡献。对于 1v1 的 60 张赛制来说很强、但在多人 Commander 中较弱的组合技，可能收录不足或缺失。搜索 "<archetype> combo <format>" 和 "<key card> combo <format>"，以发现 API 可能遗漏的赛制专属互动。

遵守等级要求（Commander）： 根据用户目标等级检查组合技结果：

  • 等级 1-2： 禁止有意构成的双牌无限组合技。将已有的无限组合技标记为等级违规。不要建议新增差一点成型的无限组合技。
  • 等级 3： 允许无限组合技，但不应在第 6 回合之前稳定启动。
  • 等级 4： 对组合技没有限制。

第 4 步：策略一致性

说明你对牌组以下方面的理解：

  • 游戏计划： 这套牌如何获胜？
  • 关键牌： 策略中最重要的牌有哪些？
60 张构筑
  • 预期对局： 根据当前环境，哪些对局有利／不利？
  • 角色灵活性： 在每种对局中，这套牌是进攻方还是防守方？
Commander／Brawl／Historic Brawl
  • Commander 机制： 指挥官带来的关键机制互动
  • 触发倍数范围： 如适用，请给出你的倍数估算（例如：“根据 Obeka 的 3 点基础力量以及常见的力量加成，我估计每次命中会额外获得 3-7 个维持阶段。”）。请用户确认此范围。 该范围会影响 cut-check，并决定如何评估触发的价值。

请用户确认或纠正。这种策略一致性检查可以避免在与牌组定位相悖的换牌分析上浪费精力。

第 5 步：Commander 互动审查（仅适用于 Commander／Brawl／Historic Brawl）

对于 60 张构筑赛制，完全跳过此步骤。 立即标记为 completed，然后进入第 6 步。

评估单张牌之前，系统地检查指挥官与牌组中每张牌之间的机制互动。此步骤可以发现单独阅读牌张时不易察觉的协同作用。

关键词组合

列出指挥官拥有的关键词，以及牌组中各牌赋予的关键词。检查每一对关键词是否会产生额外效果：

  • 叠加躲避能力： 威慑＋“不能被多于一个生物阻挡”＝无法被阻挡。任何阻挡限制与相冲突的阻挡要求结合，都可能让生物无法被阻挡。
  • 伤害倍增： 连击＋战斗伤害触发＝触发两次。连击＋系命＝获得双倍生命。践踏＋死触＝造成 1 点伤害即可杀死阻挡生物，其余伤害践踏过来。
  • 叠加保护： 守护＋辟邪、不灭＋再生——指出哪些效果重复，哪些互为补充。

此检查适用于所有牌，而不只是指挥官。赋予指挥官关键词的武具和灵气尤其重要。

触发倍增

确定指挥官的核心倍增机制（额外维持阶段、额外战斗阶段、额外回合、额外阶段、复制触发、令衍生物数量翻倍等）。对于牌组中在倍增窗口内触发的每个触发式异能，计算其在基础频率的 1 倍、3 倍和 5 倍下的产出。展示并评估倍增后的数值，而非基础数值。

“对每位对手造成 1 点伤害”这种触发在 1 倍时看似微不足道。但在有 3 位对手时，5 倍就意味着造成 15 点伤害 + 15 点生命——足以成为正当的胜利条件。请据此评估。

对于触发效果随所造成的战斗伤害而增强的指挥官，请明确将加力量列为核心策略之一。每 +1 力量带来的不只是 +1 点伤害，还会让倍增窗口内的每种效果各多触发 1 次。

反馈循环

对于每张牌，都要问：“这张牌的产出会反过来影响它自身的输入或指挥官的触发条件吗？”例如：

  • 在指挥官触发效果随力量增强的牌组中提供 +1/+1 指示物的牌
  • 能制造衍生物、从而增加另一张牌的数量加成式异能所用计数的牌
  • 使被窃取的永久物改变类别，以匹配部族数量的窃取效果
  • 在手牌数量有影响的牌组中抓牌的牌

有反馈循环的牌几乎总是比单独来看更强。在分析阶段开始前，请将其标出。

可重复使用的牌

找出所有能让自身回到可用区域的牌：重新延缓（“将其放逐，并在其上放置时间指示物”）、返照、追溯、脱逃、闪回及其他可从坟墓场施放的关键字异能、让牌本身从坟墓场回到场上的效果（Bloodghast、Vengevine），以及让牌本身回到手牌的牌（Arcanis the Omnipotent、Grinning Ignus）。评估时应计算其每局游戏的价值（典型对局中免费施放的总次数），而不是每次施放的价值。一张 6 点法术力费用、能够重新延缓并每 1–2 个回合免费施放一次的咒语，实际上是一个具有触发式异能的永久物，而非一次性咒语。cut-check 的 self-recurring 标记正是据此判断；让另一张牌回来的效果（Eternal Witness），或弹回其他东西的牌（Man-o'-War）不属于自身循环，而单独的延缓只会带来一次延迟施放。

指挥官增效

找出能放大指挥官影响力的牌，分为两类：

指挥官复制牌 — 生成指挥官的衍生复制品，或变成指挥官的复制品的牌（Helm of the Host、Spark Double、Clone 效果、Mirror March、Followed Footsteps）。非传奇复制品不受传奇规则限制，并保留所有触发式和起动式异能。

异能复制牌和触发加倍牌 — 复制或加倍指挥官的触发式／起动式异能的牌（Strionic Resonator、Rings of Brighthearth、适用于 ETB 指挥官的 Panharmonicon、适用于死亡触发的 Teysa Karlov、适用于攻击触发的 Isshin、提供额外起动机会的 Seedborn Muse）。

cut-check 的 commander_multiplication 字段会根据你的指挥官来核对这些牌，调校器也会以同样的方式保护切牌：只有能复制指挥官时，复制牌才算数（Kiki-Jiki 和 Cytoshape 只复制非传奇生物，Brudiclad 和 Esika's Chariot 复制衍生物，Mirrormade 复制神器或结界）；只有当其触发原因能触发指挥官的某个触发式异能时，触发加倍牌才算数（对于没有进战场触发的指挥官，Panharmonicon 毫无作用）。每个条目都会列出类型（create_token_copy、becomes_copy、copy_commander_spell、copy_triggered_ability、copy_activated_ability、copy_activated_or_triggered、trigger_doubler）以及实现该效果的牌张异能（clause）。该字段读取 phase 对牌的解析结果，因此，phase 尚无法解析的牌，或被其宽松解析的效果，可能会被漏掉——仍需亲自阅读每张拟切牌的文本。**这些牌能倍增战力。**拟定切牌时，凡是你标记出的牌都应视为不可动：没有明确理由时，不应将其列入切牌清单。

请注意，该输出中 commander_activated_abilities 的适用范围：只有当拟切牌能够复制指挥官时，此字段才会填充，并列出指挥官自身会被加倍的非法术力起动式异能（包括忠诚异能）。它不涉及拟切牌自身的异能。不要将空列表解读为“这张拟切牌可以放心移除”。

区域授予的异能

一些指挥官会读取战场以外的区域。精灵王 Thranduil“拥有你坟墓场中所有精灵牌的所有起动式异能”；Agatha's Soul Cauldron 对已放逐的生物也有同样效果。这会颠覆你评估一整类牌的方式：即使牌从未被施放，其起动式异能也能生效，因此牌身、法术力费用和能否施放都不再是重要的衡量标准。

在规划任何删牌方案之前，先检查指挥官的 oracle 文本是否符合这种模式。如果符合：

  1. 确认被授予的类别和区域（例如：精灵／坟墓场）。
  2. 列出牌组中所有属于该类别且具有起动式异能的牌——这份清单就是指挥官的工具箱，也是牌组实际围绕其构建的核心。
  3. 将“把这些牌放进该区域的方式”视为一个独立角色，并单独统计数量（自铣牌、滤牌、弃牌出口、导师找牌至坟墓场）。供给和输送是两个独立维度——牌组可以有丰富的工具箱，却没有办法把牌放进去；这是输送问题，不是供给问题。在断定任一方面不足之前，先分别统计两者。
  4. 注意反协同：会放逐你自己坟墓场的效应，或将那些牌移回手上的效应，都会缩小工具箱。这是需要权衡的实际代价，并非自动排除的理由——此类效应大多是可选的，而且目标可以是任意坟墓场。

cut-check 会将符合条件的删牌标记为 ZONE_GRANTED，并打印一条注明授予效果的 NOTE:。化形牌视为具有每一种生物类别（CR 702.73a）；这里只列出能在战场上运作的异能：循环、忍术和坟墓场异能都不能由指挥官起动。请查阅每张牌的裁定（rulings-lookup）——这类授予效果有一些不明显的边缘情况。例如，Thranduil 的效果规定：“如果你坟墓场中的精灵牌的起动式异能以名称提及其印制所在的牌，则视为 Thranduil 所拥有的该异能提及的是 Thranduil。”（参见 CR 201.5），因此像 Devoted Druid 的自指异能就能让指挥官重置。

连招检测

运行：combo-search <parsed-deck-json> --output /tmp/combo-search.json

检查已有的连招和未完成的连招。区分：

  • 致胜连招（结果包含“infinite”或“win the game”）：重点标出，分析期间必须谨慎保留。
  • 价值互动（非无限协同）：作为背景信息记录，但不会阻止删牌。

第 6 步：分析

所有赛制——先运行确定性核心流程。 一次 deck-tune 调用即可取代本步骤过去需要手动完成的机械统计和初步选牌。它运行与 deck-forge 相同的确定性调校器（ADR-0023/0029/0054），并返回一份评分卡和候选换牌方案；模板和所有下限均取自该牌组所属的家族（指挥官牌组使用 Command Zone 档位；60 张牌组使用互动／抓牌以及供参考的生物数量），而仅适用于指挥官牌组的维度（commander_fit、bracket）对于 60 张牌组为 null：

deck-tune <deck.json> [--bulk-data <path>] \
    --bracket <1-5> --max-swaps <N> [--budget <usd> | --wildcards rare=4,uncommon=8] [--medium paper|digital] [--shape <aggro|midrange|control|combo>] [--exclude <name>]... \
    --output <working-dir>/tune.json

媒介决定使用哪种预算单位：纸牌牌组使用 --budget，单位为美元；数字版（Arena）牌组使用 --wildcards（按稀有度分别指定，例如 mythic=1,rare=4,uncommon=8,common=8），并忽略 --budget。如果只检查已拥有的牌，则两者都省略。媒介也决定候选牌池——纸牌牌组使用纸质印刷版本，数字版牌组使用 Arena 牌池。 计分卡各部分及其涵盖的内容：

  • shape / efficiency — 套牌速度和曲线／节奏健康度（6a 曲线分析）。每张牌都按套牌沿曲线施放它所付出的费用来评估：无条件的替代费用若更低（warp、evoke、dash、blitz、prototype、impending），就以该费用取代牌面法术力值（_analysis.costs.effective_mana_value，根据阶段的关键字读取；计分卡的 curve 和平均值都使用它，而 deck-stats 仍报告牌面法术力值，并将替代费用列在旁边）。Suspend 和 plot 保留牌面费用：费用现在支付，数回合后才施放，因此应根据手牌来评估（见下文的替代费用检查）。
  • template — 各角色数量是否符合该套牌类型的区间（Commander：地、加速、抓牌、互动、清场；60 张牌：地、互动（含扫场）、抓牌，另附建议性的生物数量——旧版 slot-budgets 流程；统计 6a + 6b）。advisory 行是与结论并列的事实，不代表偏差。根据套牌指挥官评估加速（ADR-0051 修订）：对指挥官无效的法术力石不计入加速栏，也绝不会被推荐——无色指挥官使用 Arcane Signet、Mox Amber 和 Chrome Mox；生物指挥官使用 The Mightstone and Weakstone 仅限神器的法术力。
  • focus — 指挥官的信号方向，以及套牌是否围绕这些方向集中构筑（旧版 deck-signals 流程；6c）。
  • mana — 完整的法术力审计：颜色平衡、Burgess 地牌目标、未横置质量。
  • curve — 按 CMC 划分的数量直方图。
  • combos — 组合技及未完成的组合技；组合技组件会自动受到保护，不会被列入建议移除的牌。只差一张指定牌的未完成组合技会成为 near_miss_combo 问题，其替换建议会加入那张牌（能赢下游戏的路线优先于无用牌；目标分档低于 3 时，绝不推荐能赢下游戏的未完成组合技）。
  • commander_multipliers — 复制指挥官、使指挥官实际拥有的异能额外触发次数或复制该异能（CR 603.2d、707.10——根据阶段的树结构读取，因此 Panharmonicon 只会在指挥官具有匹配的进场触发式异能时计入），或从其他区域赋予指挥官起动式异能的牌，并附上原因。它们和组合技组件一样受到保护，不会被列入建议移除的牌。
  • meta（带有 arena-meta 缓存的数字版 Arena 天梯套牌；否则为 null）。它包含该套牌在 Untapped 天梯上的环境构筑类型、战绩和 core，missing_core 卡牌（包括地牌），以及几乎没有任何该类型套牌会使用的 low_share 卡牌。这些信息会取代 EDHREC 使用率，参与移除牌的排序。排名靠前的缺失非地牌核心卡还会显示为 meta_core_missing 问题（ADR-0059）。--meta off 会跳过此项；--meta "<name>" 会选择该环境构筑类型。
  • bracket — 使用 --bracket 时的限制检查（Game Changers／大规模土地破坏／额外回合／二张牌组合技，与目标分档的官方许可范围对比；ADR-0030）。在一对一游戏中（所有 Arena 套牌、Competitive Brawl），此项会以 not_applicable 原因通过——分档系统适用于多人 Commander。
  • swaps — 按预算筛选出的（移除、加入）候选组合，并按协同作用排序（旧版 deck-rank 流程）。在一对一游戏中（所有 Arena 套牌），EDHREC 使用率绝不会将某张牌标记为低价值——EDHREC 面向多人纸牌 Commander——但在加入候选牌得分相同时仍会用于决胜。

你的工作是判断，而不是计数。 阅读计分卡的 top_issues，然后对 deck-tune 找出的候选替换组合运行逐张牌的移除检查清单（6d）——在接受任何替换前，核实 Oracle 文本、与指挥官的互动、触发次数倍增的价值（步骤 7 cut-check），以及组合技路线。自我盘问（步骤 8）仍是最终提案的把关环节，并且每项最终决定都由你和用户共同做出（由用户决定选用哪些牌）。 明确保持在主干流程之外的内容：

  • mana-audit <deck.json> --compare <new-deck.json> 用于 6g / Step 10 中的前后对比检查（评分卡记录的是当前法术力情况；对比是单独调用的）。
  • archetype-audit 现在是可选项——focus 可以回答指挥官与套牌是否协调的问题。只有在测试某个具体的命名主题的密度或寻找桥接牌时，才使用 archetype-audit（这些功能不在 focus 的能力范围内）。

60 张构筑赛制：deck-tune 运行相同的主干流程（其 size 会报告距离 60 张的 shortfall，绝不会报告超额；交换操作的 add 会带有 copy——“加到 4 张”也是一种普通交换；备牌永远不会计入，也不会作为建议提出）。下文由 Agent 驱动的分析——环境中的套牌原型、核心牌评估、备牌——仍是在此基础上的判断层。

6a：法术力基础与曲线审计
  • 地牌数量和加速组件（法术力石、精怪、搜地咒语）
  • 非地牌的平均 CMC
  • 曲线分布
  • 使用 mana-audit 进行定量检查
  • 颜色平衡：符号需求与地牌产出的对比
  • 法术力基础质量：关键回合能否使用未横置的法术力来源、颜色调整能力
  • 标记：地牌过少或过多、颜色不足、横置地过多

角色密度预算（确定性）。 *Commander 系列：*主干流程评分卡的 template 部分已包含各角色（地牌 / 加速 / 抽牌 / 互动 / 清场）的数量，以及与 Command-Zone 范围的对比——直接在此查看，无需重新单独检查。标记为 (under) / (over) 的角色，是可验证的增减牌信号。（独立的 slot-budgets <deck.json> [--bulk-data <path>] [--shape ...] CLI 仍可用于临时检查，例如 60 张构筑赛制——套牌张数取自套牌 JSON，而非标志——但其使用的预算计算器与评分卡相同。）

Commander 赛制：地牌数量是硬性约束。读取 mana-audit 的范围（land_band.floor / land_band.top / land_band.flood / land_band.status，ADR-0041），并将上限视为目标；切勿手动计算 Burgess。status 为 PASS、FAIL（低于下限——唯一会阻止通过的值）或 FLOOD（高于 top + 2，仅作提示：地牌过多，可考虑削减）。commander_cmc 项表示有效指挥官费用（ADR-0044）：对于自身异能可根据场上某项数量降低费用的指挥官（The Lord of the Eagles、Ghalta），它是套牌预期能够支付指挥官费用的最早回合数，基于套牌自身的牌在未受干扰的曲线下计算；JSON 的 commander_cost 块会显示逐回合表格及 status——当异能的结构（坟场计数、条件效果）或缺少 IR 导致必须使用印制数值时，状态为 modelled、none 或 unmodelled (<why>)。如果返回 FAIL，必须增加地牌或减少地牌削减量。若建议的地牌数量低于下限，则 mana-audit 必须返回 PASS 或 WARN（不能是 FAIL）。对于没有建模折扣的指挥官，建议地牌数量低于 36 几乎总会导致 FAIL。

**60 张构筑赛制：**使用构筑赛制的地牌公式。与该赛制的具体预期进行比较。

6b：互动与威胁审计
Commander/Brawl/Historic Brawl

查看评分卡中 interaction 和 board_wipe 的 template 行：其中列出与套牌 Shape 对应范围的数量（ADR-0024——密度随 Shape 而非强度档位变化）。标记为 (under) 的行表示需要增加互动的可验证信号。“干扰”包括反击咒语、弃牌和税效组件。然后根据用户的痛点和对局环境判断互动的类型：瞬间时机还是法术时机，以及应对该环境中实际出现威胁的答案。

60 张构筑赛制
  • 统计去除牌数量（指定目标的去除牌 + 清场）
  • 统计威胁数量（生物 + 旅法师 + 其他获胜手段）
  • 与该赛制的预期进行比较（快攻赛制需要的解牌较少；控制环境需要更多）
  • 标记：针对当前环境的互动不足、去除牌冗余、缺少特定类型的威胁
6c：构筑主题一致性

指挥官信号分析（Commander/Brawl/Historic Brawl——确定性）。 核心流程的评分卡 focus 部分已提取指挥官 ORACLE TEXT 关注的内容（部族、衍生物、牺牲、坟场、+1/+1 指示物、进场触发等），并将其作为带标签的方向列出，同时报告套牌的引擎牌是否集中在这些方向上。查看 focus，了解套牌的实际路线——它会读取指挥官本身（感知指挥官），因此是下文角色分组的确定性起点，也能部分弥补下文提到的指挥官变化盲点。（独立的 deck-signals <deck.json> [--bulk-data <path>] CLI 也会提供相同路线，供临时使用。）

机制主题分析（可选——适用于所有赛制）。 focus 回答的是 Commander 系列的指挥官协同问题。只有在需要 focus 不具备的能力时，才使用 archetype-audit：用你自己的正则表达式测试特定命名主题的密度，或查找桥接牌（匹配 ≥2 个主题的牌）。运行时，数量按牌张数计算，因此 4 张 Lightning Bolt 会为 burn 贡献 4，而非 1——非单例赛制的数值会更大。对于 60 张构筑（无核心流程），这仍然是主要的机制密度基准。

已知盲点。 archetype-audit 会孤立地评估牌张。它不会识别指挥官导致的主题变化——即使你的指挥官会在精灵进场时削弱对手，工具也不会把普通精灵视为生物去除牌。“每当一个 X 进场时，执行 Y”／“由你操控的生物具有 Z”／减费和收益型指挥官，都会产生机制分析无法发现的新兴分类。请在后续的逐牌分析中记录这些重新分类。（第 5 步「指挥官互动审计」是进行指挥官视角推理的指定环节。）

套牌中值得关注的输出字段：每个主题的总数（该主题的数量是否足以产生实际影响？）、桥接牌（匹配 ≥2 个主题的牌——协同纽带，应避免将其删减），以及 --show-matches 牌张列表。by_guild 明细和 orphan signal 备注是针对限制牌池规模的诊断信息——分析单套牌时可忽略。

运行 archetype-audit --list-presets 浏览目录（关键词异能、按类型划分的去除、逼从、回合操控、闪现，以及宽泛的功能类别）。

Commander/Brawl/Historic Brawl

先进行机制分析：

archetype-audit <deck.json> <deck.hydrated.json> \
    --include-commanders \
    --preset tokens \
    --preset sacrifice-outlet \
    --preset reanimate \
    --min-density 8 --warn-density 10 \
    --show-matches

这些赛制务必传入 --include-commanders。 否则指挥官本身会被静默排除在计数之外，而指挥官通常是套牌中最重要的主题组件。对于没有匹配预设的主题，请使用 --theme "name=regex"。--min-density 8 --warn-density 10 的值针对 100 张牌牌表中约 65 张非地牌进行了调整；少于 8 张的主题通常薄弱到不足以成为战略支柱，少于 10 张则按惯例偏薄。

然后根据感知指挥官的角色对牌张分组——角色由它们与这位指挥官的协同方式定义，而非通用类别。将每组作为一个整体进行分析。

对每张牌，都要回答：“这张牌具体如何与这位指挥官互动？”请引用 oracle 文本。机制分析会告诉你原始密度；逐牌分析则会告诉你每张牌是否值得占据一个卡位。

分析维度：

  • 与指挥官及其他牌的协同
  • 法力曲线分布
  • 牌张类型平衡（生物、互动、加速、抓牌）
  • 获胜条件
  • 法术力基础质量
  • 规则区间合规性（统计 Game Changers 数量，并与目标规则区间比较）
  • 痛点聚焦（根据用户指出的问题调整权重）
  • 组合技认知（结合上下文评估组合技组件，将差一点的牌作为候选添加牌）
60 张构筑套牌

与指挥官套牌（以指挥官为核心）不同，构筑套牌必须在 60 张牌中展现出一致的游戏计划。

步骤 1 — 找出构筑核心牌。 每副竞技套牌都有 1–3 张牌定义其原型（例如，灼烧套牌的 Monastery Swiftspear、伊捷凤凰套牌的 Arclight Phoenix、Amulet Titan 套牌的 Amulet of Vigor）。这些牌相当于构筑套牌中的指挥官——套牌围绕它们构建，以最大限度地发挥它们的作用。

步骤 2 — 依据构筑核心评估其余每张牌。 每张非地牌都应至少符合以下一项：

  • 启用构筑核心（导师、铺垫、法术力加速）
  • 保护构筑核心（反击咒语、去除、冗余）
  • 配合构筑核心（能从相同游戏状态中获益的牌）
  • 在构筑核心发挥作用后终结比赛（胜利条件）

明显不属于这些角色的牌都是可考虑删减的对象。

步骤 3 — 检查孤立的“备用计划”牌。 常见的套牌构筑错误，是加入 2–3 张来自次要策略的牌，而套牌并没有足以支持该策略的基础。

步骤 4 — 检查机械原型。 使用声明的主题运行 archetype-audit：

archetype-audit <deck.json> <deck.hydrated.json> \
    --preset burn --preset counterspell \
    --min-density 6 --warn-density 8 \
    --show-matches

数量以牌的张数计算（4x Lightning Bolt 会为 burn 贡献 4）。--min-density 6 --warn-density 8 的值针对约 40 张非地牌的 60 张牌套牌进行了调整。未出现在任何主题下的牌，是步骤 3 中“孤立的备用计划”候选牌——请将 --show-matches 列表与完整牌表交叉核对。对于没有匹配预设的主题，可改用 --theme "name=regex"；自由浏览 oracle 文本仍可使用 card-summary <deck.json> --nonlands-only。

步骤 5 — 验证结构的一致性：

  • 威胁密度： 套牌是否有足够的压力来终结比赛？
  • 曲线协调性： 法术力曲线是否符合预期速度？
  • 无用牌： 是否有牌对主要游戏计划毫无贡献？
  • 不匹配的牌： 是否有牌属于其他原型？
6d：删减牌张
指挥官／争斗／史迹争斗：删牌检查清单

在建议删掉任何牌之前，必须对每张候选牌逐项完成此检查清单。跳过任何项目都可能导致误判。

  1. 完整核实 oracle 文本。 从套牌已填充数据的侧车文件（<deck>.hydrated.json）中重新阅读该牌完整的 oracle 文本。card-summary 表格会截断 oracle 文本，仅供快速浏览。

    必须针对每张牌，根据该牌的文本单独运行此检查清单。 为所有候选牌生成一份批量 oracle 文本转储，再统一分析，不属于此步骤——这种做法会退化成按牌名匹配模式（“那是强化咒语”“那是法术力岩石”），并且第一条之后的每个子句都不再被阅读。如果为方便起见生成了转储，仍须逐张检查每个候选牌。

    任何转储都必须呈现 card_faces。 DFC、分离牌、历险牌和预兆牌的文本位于牌面上，而非 oracle_text 中。直接使用 card["oracle_text"] 会将它们显示为空白，导致牌在没有报错的情况下被依据空白内容评估。请使用 mtg_utils.card_classify.get_oracle_text，它已包含回退至拼接牌面的逻辑；在信任转储前，还要仔细查看是否有空白条目。

0.5. 替代费用检查。 如果该牌具有延缓、预示、历险、呼魂、返照、脱逃或其他替代施放费用，请依据此套牌中最可能使用的费用进行评估，而非印制的 CMC。

  1. 逐条分析 oracle 文本。 单独阅读每个句子。请问自己：“这一特定子句如何与我的指挥官及套牌策略互动？”常见的遗漏子句包括：

    • 攻击／阻挡限制
    • 改变类别的效应
    • 自我回归机制
    • 对其他永久物生效的静止式效应

  2. 检查防御价值。 这张牌能减少受到的伤害或攻击吗？能保护其他永久物吗？能在政治层面上威慑对手吗？

  3. 反馈循环检查。 移除这张牌会打破自我强化循环吗？（参见步骤 5。）如果会，就需要更充分的理由才能删掉它。

  4. 痛点回归检查。 删除这张牌会让用户陈述的问题变得更糟吗？

  5. 倍增价值计算。 按指挥官预期的触发倍数计算这张牌的输出（参见步骤 5）。如果某个触发效果在 1 倍时看起来不强，但在 5 倍时能击败玩家，那它就是获胜条件，而非普通角色牌。

  6. 组合组件检查。 这张牌是否属于已有的组合路线（通过步骤 5 的组合搜索找到）？

    • 制胜组合： 很难证明应该删掉。合理的理由包括“对该赛制级别来说太慢”或“违反赛制级别限制”。
    • 价值互动： 仅作为软性考量，而非硬性门槛。

  7. 区域赋予能力检查。 如果指挥官会读取非战场区域（参见步骤 5 > 区域赋予的能力），这张牌的起动式异能在该区域中是否仍然有效？cut-check 会将这些标记为 ZONE_GRANTED。一张本身并不起眼的牌仍可能是关键组件——Thranduil, the Elvenking 能让坟墓场中的 Priest of Titania 在一个 5/6 指挥官的套牌里变成“{T}：每有一个 Elf，便加 {G}”。这张牌完全不必施放，所以把它当作你会打出的生物来评估，会低估它的作用。删掉其中一张，就等于从指挥官那里移除一个工具。

  8. 反协同影响范围评估。 当某个条款会影响你自己的部分牌张（“玩家不能支付生命……”“不能从牌库施放咒语”、对称清场或仇恨组件）时，先说出受影响的牌并统计数量，再根据反协同做决定。新增牌也同样适用。

    • 影响一两张牌只是小问题。 这值得作为使用提示（“自己的法术力石还在场时，不要启动 Sylex”），但不足以构成删牌或拒绝新增的理由。
    • 将同一条款对比其对对手的影响。 对称效果通常会更严重地打击依赖该效果的套牌。Karn's Sylex 会让无色 Omnath 套牌中的两张牌失效，却会让对手的每一张找地地和 Phyrexian 法术力牌都失效。
    • 只有影响范围很大时才构成决定性因素。 这意味着影响到指挥官、组合组件、套牌引擎，或套牌中相当一部分牌（大约五张或更多）。

删牌——务必谨慎。 在建议删掉任何牌之前，重新阅读该牌和指挥官的 Oracle 规则文本。具体说明这张牌为何在这套牌中表现不佳。

60 张构筑：草拟删牌

对于每张建议删除的牌，请评估：

  1. Oracle 规则文本核实——阅读套牌已填充 sidecar 中的完整 Oracle 规则文本
  2. 替代费用检查——Suspend、foretell 等机制会改变有效 CMC
  3. 套牌中的作用——这张牌承担什么作用？是否有冗余？
  4. 对局影响——删掉这张牌会伤害某些特定对局吗？
  5. 组合路线检查——这张牌是否属于已有组合？（来自步骤 3）
  6. 当前环境相关性——这张牌在当前环境中是否特别强或弱？
  7. 反协同影响范围评估——统计自损条款实际影响的牌张，并像指挥官检查清单第 8 项那样，将其与对手受到的影响进行权衡。影响一两张牌只是使用提示，不足以构成删牌理由。

删牌务必谨慎。 重新阅读该牌及其协同牌张的 Oracle 规则文本。具体说明其表现不佳之处。

路径 B 调整：草拟删牌

对于路径 B（新构建的骨架），删掉的牌是经过自检后确认表现不佳的骨架牌。上述检查清单仍然适用。如果骨架合理，也可能无需删牌。

6e：拟议新增牌

来源候选牌：

  • **60 张牌：**元游戏研究（主流牌表差异）、card-search、险些成立的组合技、使用 WebSearch 搜索特定构筑的技术牌
  • **指挥官：**EDHREC 高协同牌、网络研究、使用 card-search 查找 EDHREC 可能未收录的协同牌

运行：card-search --bulk-data <path> --format <fmt> [--color-identity <ci>] [--oracle "<keyword>"] [--price-max <budget-per-card>] --json > candidates.json

按协同度对候选牌排序（确定性）。 指挥官系列：核心流程已经会提出按协同度排序的 swaps（替换牌组，包含一张移出牌和一张加入牌）——从这些候选新增牌开始；组合技组件已预先受到保护，不会被配对移出的牌影响。如果你想对自己搜集的独立候选牌列表排序（例如不在替换牌组中的 EDHREC 高协同牌），请将该列表的 card-search --json 输出传给 deck-rank <deck.json> candidates.json [--bulk-data <path>]——使用与核心流程相同的协同度 → 价格 → 曲线评分，绝不按 EDHREC 热度评分。无论哪种方式，你和用户都要对每张牌做最终决定（由用户决定选牌）。

对于每张拟议新增牌：

  1. 验证赛制合法性和 Oracle 文本
  2. 检查价格（是否在预算内？）
  3. 确定它填补的作用
  4. 与它要替换的牌进行比较

将任何牌加入拟议新增牌列表前，都要验证其颜色标识（指挥官赛制）或赛制合法性（所有赛制）。绝不能依赖牌名或记忆。像 Pest Infestation 这样的牌（实际上是黑绿，尽管看起来像绿牌）如果不验证就很容易漏掉。

推荐最便宜的可用印刷版本。持续跟踪累计费用与预算的对比。

6f：备牌评估（仅限 60 张牌）

**指挥官、Brawl 和 Historic Brawl 均跳过。**Bo1 也跳过（参见第 2 步信息收集）。

根据元游戏评估当前备牌：

  • 是否能应对排名前 3–5 的构筑？
  • 是否有无用的备牌栏位（针对不存在的对局的牌）？
  • 是否缺少应对手段（常见构筑没有备牌计划）？
  • 备牌计划是否清晰？（每种对局分别换入／换出哪些牌？）

起草备牌调整，并与主牌调整一并提交。

6g：替换平衡检查

起草完所有调整后（如适用，包含主牌和备牌）：

  • 验证主牌总数仍符合预期（60 或 100）
  • 验证备牌不超过 15 张（仅限 60 张牌）
  • 检查地牌数量是否发生偏移
  • 检查曲线是否过高
  • 运行 mana-audit <deck.json> --compare <new-deck.json>，验证颜色平衡得到维持
  • 验证预算：对拟议新增牌运行 price-check
  • **加速牌数量必须保持稳定。**除非套牌中的加速牌过多，或你加入了同等数量的加速牌，否则不要移出加速牌。

如果替换会损害法术力基础，请在提交前修订。少做几次替换，也好过破坏套牌施放咒语的能力。

第 7 步：预先自我盘问验证

自我盘问前，先进行机械验证。proposal-check 一次运行即可检查以下所有关卡——它会构建预览套牌并报告找到的移出牌、牌数、合法性、地牌数量范围、预算、失去的组合技／消除的险些成立组合技（无法访问 Commander Spellbook 时发出 WARN），以及复制或增殖指挥官的移出牌（发出 WARN）；每项均标记为 PASS／WARN／FAIL，并附上每位指挥官的 cut-check 完整报告：

proposal-check <deck.json> --cuts /tmp/cuts.json --adds /tmp/adds.json [--budget <usd> | --wildcards <rarity=N,…>] [--medium digital] [--collection <collection>] --output-dir <wd>

在 Arena 上运行（或任何新增牌可能已在收藏中的情况）时，传入 --collection：牌表的 owned_cards 只涵盖其当前所含的牌。失去能赢得比赛的组合技会导致 FAIL；只有在记录移出理由后，才能传入 --allow-combo-loss。将其 proposal-check.json 交给第 8 步的 Agent，作为机械验证记录。以下各节将说明每个关卡，以及失败时的处理方式。

新增卡牌的合法性检查（硬性门槛）

绝不要向自我审查环节提交包含禁牌或违反颜色身份规则的卡牌的提案。 Agent 无法可靠地从训练数据中回忆禁牌名单的历史版本；运行审计的成本很低。

根据当前提案构建预览套牌并进行审计：

build-deck <deck.json> --cuts /tmp/cuts.json --adds /tmp/adds.json --bulk-data <path> --output-dir <wd>
legality-audit <wd>/new-deck.json --bulk-data <path>

默认情况下，legality-audit 会启用 --cite-rules；因此，如果 <wd> 中存在 CR 文件，每项违规都会在 JSON 中附带 CR 规则引用。

如果审计结果为 FAIL，请修改 /tmp/adds.json 或 /tmp/cuts.json，然后重新预览，再进入第 8 步。自我审查子 Agent 绝不能根据训练数据断言卡牌是否合法——如果提案者或质疑者认为某张牌合法，唯一有效的证明就是此前运行过 legality-audit，并且他们能够引用其 JSON 结果。

本检查旨在防止的具体疏漏（会话 0a340f10）：提案者推荐了 Dockside Extortionist。质疑者指出这可能违反 Bracket 政策。双方都没有运行 legality-audit，却都断言它符合 Commander 赛制规则。事实上，Dockside 已被禁用。只有构建完成后的审计才发现了问题，浪费了一轮构建。在第 8 步之前运行此检查，就能在正确的环节发现问题。

新增卡牌的价格检查
price-check /tmp/adds.json --bulk-data <path> [--format <fmt>] [--medium digital] [--budget <budget>]

对于 Arena 赛制，使用 --format <fmt> 获取万能牌花费。如果任何单张牌或总花费超出预算，请先寻找更便宜的替代牌。不要向自我审查环节提交用户买不起的卡牌。

Commander/Brawl/Historic Brawl：机械性删牌检查

对每张拟删卡牌运行 cut-check：

cut-check <deck.json> --cuts <cuts.json> --multiplier-low <low> --multiplier-high <high> --opponents <N> [--bulk-data <path>]

默认从套牌的 commanders 区域读取指挥官（取第一张）；传入 --commander "<Name>" 可指定其他指挥官，例如检查伙伴组合中的另一半。

标准输出是一份精简的文本报告，每张拟删卡牌占一行，汇总各项标记（COMMANDER_MULTIPLICATION、triggers=N (type=value-range)、self-recurring=yes/no、keyword-interactions=N），并附带一行 Flags: 统计。--trigger-type 可选 upkeep、attack、combat-damage、death、etb 或 endstep。JSON 中每个触发效果都包含其异能的 text、触发时机的所有类型（types——Sun Titan 的“进场或攻击”同时属于 etb 和 attack），以及仅在异能产生固定数值时才包含的 base_value（对每位对手造成伤害按每位对手计算一次；“获得等同于……的生命”无法解析）。如果暂时无法解析某张牌的牌面，则不会报告触发效果。

对每张拟删卡牌，写出以下内容（仅内部记录，不向用户展示）：

  1. 放大后的价值：［依据 cut-check 输出，或填写“没有匹配的触发效果”］
  2. **痛点恶化情况：**删掉这张牌会让用户提出的问题更严重吗？
  3. **防御价值：**这张牌能阻止、威慑或防护什么？
  4. **替换理由：**新增卡牌中的哪张具体卡牌能替代它的作用？
  5. **组合技路线：**这张牌是否属于第 5 步中的现有组合技？如果能赢得对局，请说明为何可以接受删掉它。
  6. **接近成套的伙伴检查：**这张牌能与第 5 步中哪些接近成套的结果配合？如果有，请说明为何仍可完成替代，或修改删牌方案。

如果无法填写全部六项，就说明你还没有评估这张牌。不要继续进入自我审查环节。

60 张构筑赛制：内部评估

对每张拟删卡牌，写出以下内容（仅内部记录，不向用户展示）：

  • 在套牌中的作用
  • 对不同对局的影响
  • 会影响组合技路线吗？
  • 替换理由
  • 对当前环境的意义

如果说不清为何应该删掉某张具体卡牌，就说明你还没有完成评估——不要继续。

步骤 8：自我审查（双 Agent 辩论）

**受限（路径 C）变体：**给两个 Agent 的提示词是 “对池中的所有可行颜色组合进行排序，并说明排序理由”——不指定任何候选组合；pool-colors 表（以及 set-scan）是输入，而不是已完成的牌组列表。若给挑战者一个预先确定的组合，它只会针对一种构筑进行优化。

**硬性门槛。**必须使用两个并行的 Agent 工具调用（subagent_type: "general-purpose"）：一个提案者、一个挑战者，并且至少进行一轮修订。不得用机械检查（mana-audit、price-check）替代此环节——这些检查可以发现定量错误；自我审查可以发现策略错误（错误评估原型、遗漏协同、论证薄弱、误判环境）。

数据交付

向两个 Agent 提供文件路径（它们可以选择性地调用 Read），以及一段总结要点的文字：

必需文件路径：

  • 套牌 JSON 路径（Agent 可以自行载入并针对其重新运行任何 CLI）
  • mana-audit 输出
  • price-check 输出
  • combo-search 输出
  • 拟议的移出牌张 JSON
  • 拟议的加入牌张 JSON
  • 备牌移出/加入牌张 JSON（如有，仅限 60 张牌制）
  • cut-check 输出（仅限指挥官赛制）

要点总结示例（60 张牌）： “为先锋赛红色快攻套牌拟议了 8 张主牌替换 + 4 张备牌替换。mana-audit PASS；price-check 为 $12.50，预算为 $20；combo-search 检测到 0 个组合技（快攻套牌）。核心思路：从偏重烧牌转向偏重生物，以改善对阵 Sheoldred 的表现。”

要点总结示例（指挥官）： “cut-check 标记了被移出牌张中的 N 个 commander_multiplication + M 个触发；mana-audit 返回 PASS/WARN/FAIL；price-check 总价为 $X，预算为 $Y，其中有 Z 张牌超出限额；combo-search 在套牌中发现 N 个制胜组合，其中 K 个会受拟议移出牌张的影响。”

**Read 不可用时的备用方案。**如果被分派的子 Agent 报告无法 Read 提供的路径，父 Agent 必须在后续消息中将相关文件摘录粘贴给该子 Agent——绝不能倾倒整个文件。

提案者须知

为提案辩护。除非挑战者提出以下内容，否则应反驳其异议：

  • 你遗漏的具体 Oracle 文本交互
  • 定量论据（法术力计算、对局胜率）
  • 与你的判断相矛盾的环境数据

**绝不要依据训练数据断言合法性。**如果你声称某张牌合法／被禁用／受限制，唯一有效的证明是之前运行过的 legality-audit——请引用 JSON 输出路径。禁牌表会变更（通常每年多次）；6 个月前的训练数据快照并非权威依据。步骤 7 会在分派前对加入牌张进行合法性检查这一硬性门槛；如果辩论过程中对任何牌的合法性不确定，请让父 Agent 针对更新后的加入牌张重新运行 legality-audit。

挑战者检查清单

挑战者必须核实：

  • 独立阅读每张移出牌的 Oracle 文本（不要轻信转述）
  • 核实每张移出牌的作用——替换牌在这个卡位上是否真的更好？
  • 量化每项反协同主张（无论是你还是提案者提出）：列出受影响的牌并统计数量。某个效果只影响我方一两张牌时，这只是出牌提示，而不是移出或否决的理由（步骤 6d 第 8 项）。还要权衡同一条款对对手的影响。
  • 检查是否失去了关键对局所需的应对能力
  • 核实是否针对提案运行了 legality-audit（而不只是针对当前套牌）——请引用 JSON 输出路径。绝不接受基于训练数据的禁牌表断言。
  • 核实 mana-audit 为 PASS
  • 核实 price-check 符合预算
  • 核实没有未经说明地破坏任何组合技线路
  • 核实替换平衡（地牌数量、曲线、总张数）
  • 原型一致性测试：“这些替换之后，这套牌是否仍有明确的游戏计划？”
额外的 60 张牌检查
  • 确认备牌方案仍覆盖顶尖环境套牌
  • 伙伴限制： 如果套牌有伙伴，确认每张加入的牌仍符合其套牌构筑限制
  • 备牌合理性测试：“对于排名前三的对局，会换入和换出哪些牌？这个方案合理吗？”
额外的指挥官检查
  • 检查每张被移除牌的 Oracle 文本中的每个条款——防御限制、类型变更效果、自我返场机制、静态效果
  • 确认指挥官与每张被移除牌之间的关键词互动（涌现式组合）
  • 计算被移除的任意触发效果的倍增价值
  • Read 被移除牌检查 JSON，并确认提议者已处理其中的每个标记
  • 检查 color_balance_flags 和各颜色指标
  • 对于 Brawl 赛制，格外严格地审查武斗策略（没有指挥官伤害）。将较低的生命总值和免费调度考虑在内。
  • 指挥官适配度检查——应用指挥官身份测试：“如果隐藏这副套牌的指挥官，你能从牌中猜出它是谁吗？”如果指挥官可能表现不佳，列出 1-2 个备选方案，并在步骤 11 中作为难以取舍的选择提出。
路径 B 适配：骨架审查

对于路径 B（新构建的骨架），自我审视要围绕整个骨架展开，而不只是拟议的改动。挑战者的检查清单还包括：

  • 流派一致性： 骨架是否有清晰、一致的游戏计划？
  • 遗漏的协同： 是否遗漏了适用于这位指挥官/此流派的明显协同牌？
  • 预算浪费： 是否有昂贵的牌表现不如更便宜的替代牌？
  • 无用牌： 是否有牌对主要策略毫无帮助？
  • 法术力基础适配度： 法术力基础是否支持法术力曲线和颜色需求？

经过辩论后，可能得出无需改动的结论。对于构筑良好的骨架，这是合理的结果。

至少进行 2-3 轮。 如果双方立即达成一致，说明挑战者施压还不够。

步骤 9：提出改动

严格门槛： 在任何 AskUserQuestion 之前，先将完整提案作为一个完整回合写出。不要将工具调用与提案 Markdown 打包——工具会在文本定稿前执行，用户只能盲目批准。

提交前

运行 build-deck 构建新套牌，然后对结果运行 mana-audit。如果失败，就修改直到通过。

首选路径：build-deck + export-deck。 这两者在构建过程中会生成尺寸正确的套牌 JSON，因此无需手动计算牌数。

用户尚未看到辩论内容。 将辩论后的提案作为完整、独立的建议呈现，并充分说明每项换牌的理由。不要提及辩论。

路径 B：无需改动

如果自我审视得出的结论是骨架合理且无需改动，请跳过步骤 9-11，直接进入步骤 12。

提案格式

以成对换牌的形式呈现，并说明理由。根据经验水平调整细节。

主牌改动：

## Mainboard Changes (8 swaps)

**OUT: Shock (4) -> IN: Play with Fire (4)**
Shock deals 2 to any target; Play with Fire deals 2 to any target OR scrys 1 when it
deals damage to a player. Strictly better in this deck since we point burn at face.
Cost: $0.50 per copy.

**OUT: Viashino Pyromancer (2) -> IN: Eidolon of the Great Revel (2)**
Viashino is a one-shot 2 damage on ETB. Eidolon punishes the opponent for every spell
they cast, often dealing 6-10 damage per game in faster matchups.
Cost: $3.00 per copy.
...

备牌改动（仅限 60 张牌）：

## Sideboard Changes (4 swaps)

**OUT: Magma Spray (2) -> IN: Roiling Vortex (2)**
Magma Spray is narrow graveyard removal. Roiling Vortex hits free spells (Fury, Force),
lifegain (Sheoldred), and deals 1/turn. Better coverage across more matchups.
Cost: $1.00 per copy.
...

指挥官赛制换牌： 说明被移除的牌为何不适合这位指挥官（引用 Oracle 文本），以及加入的牌为何更适合该策略（引用 Oracle 文本）。

预算摘要：

## Budget
Total additions: $14.50 / $20.00 budget
Remaining: $5.50

对于 Arena 万智牌套牌，按稀有度展示用量明细。

步骤 10：影响验证

严格门槛。 在提出难以取舍的选择之前，对新套牌运行这两项检查。此步骤用于发现涌现式回归问题——只有在所有改动一并应用后才能看到的跨换牌互动。重新运行 proposal-check 检查最终提案即可覆盖两项检查（其 diff 是 deck-diff，其 combos 门槛会比较 combo-search 变更前后的结果）。

检查 1：牌组差异
deck-diff <old-deck.json> <new-deck.json> [--bulk-data <path>]

验证：

  • 总张数不变（主牌仍为 60/100 张，适用时备牌为 15 张）
  • 地数量合理
  • 平均 CMC 没有飙升
  • 加速牌数量稳定
  • 备牌改动符合提案（60 张牌组）
检查 2：组合技搜索（构建后）
combo-search <new-deck.json>

与步骤 3/5 的结果比较：

  • 有组合技被移除吗？如果有，是否是有意为之（已在步骤 6d/7 中记录）？
  • 有新增组合技吗？
  • 险些成型的组合技有变化吗？

**不可替代步骤 7 的组合技检查。**步骤 7 会发现那些关闭了险些成型路线的删牌（构建前）。步骤 10 会发现那些破坏了现有组合技路线的删牌（构建后）。两者互不可替代。

如果出现任何非预期的退化，请修改提案。

步骤 11：有争议的选择

从自我审视讨论中列出真正有争议的替换。这些牌需要满足以下条件：

  • 提案者和质疑者意见不一
  • 决策取决于本地元环境或个人打法偏好
  • 两种选择都有合理依据

作为需要用户决定的选项呈现：

## Close Call: Eidolon of the Great Revel vs. Harsh Mentor

**Case for Eidolon:** Hits every spell, higher floor, proven format staple.
**Case for Harsh Mentor:** Cheaper at 2 mana, punishes activated abilities (fetchlands,
planeswalker activations), but doesn't hit spells.

Which do you prefer, or would you like to test both?

不要把显而易见的决定列为有争议的选择。只列出真正存在分歧的选项。

考虑更换指挥官（仅限指挥官赛制／争斗／历史争斗）

如果质疑者在自我审视时提出了指挥官问题，就将其作为有争议的选择呈现——绝不要作为确定的建议：

“有一点值得考虑：[具体说明该指挥官为何不适合这副牌的构成]。同色的[替代指挥官]具有[具体的 Oracle 文本互动]，与这副牌实际的运作方式更契合。不过这会是一次重大改动——值得探索一下吗？还是你想保留[当前指挥官]？”

**这始终是一个有争议的选择。**用户选择这位指挥官自有原因。

步骤 12：完成

导出
export-deck <new-deck.json>

输出包含备牌部分的 Moxfield/Arena 导入格式。

最终价格检查
price-check <new-deck.json> --bulk-data <path>

对于 Arena：

price-check <new-deck.json> --format <fmt> --medium digital --bulk-data <path>
最终预算汇总

实体牌：

| | Cost |
|---|---|
| Skeleton (from builder) | $X |
| Upgrades (this session) | $Y |
| **Total deck cost** | **$Z** |
| Owned cards (not counted) | card1, card2, ... |
| Total budget | $B |
| **Remaining** | **$R** |

如果是路径 A（不含构建阶段的独立调优环节），只显示升级费用和牌组总费用。

Arena：

| Rarity   | Used | Available | Remaining |
|----------|------|-----------|-----------|
| Mythic   | 1    | 2         | 1         |
| Rare     | 3    | 4         | 1         |
| Uncommon | 4    | 8         | 4         |
| Common   | 6    | 12        | 6         |
备牌指南（仅限 60 张牌组）

针对步骤 3 中确定的排名前 3–5 的元环境套牌，逐一制作对局备牌方案。这是已有分析的自然输出——不要跳过。

## Sideboard Guide

### vs. Mono-Red Aggro (IN: 5, OUT: 5)
IN: 2 Surge of Salvation, 3 Temporary Lockdown
OUT: 2 Disdainful Stroke, 1 Negate, 2 Memory Deluge
Rationale: Trade slow counterspells for cheap answers that stabilize before turn 4.

### vs. Azorius Control (IN: 4, OUT: 4)
IN: 3 Mystical Dispute, 1 Negate
OUT: 3 Temporary Lockdown, 1 Surge of Salvation
Rationale: Sweepers are dead; load up on cheap countermagic for the permission war.

### vs. Graveyard Combo (IN: 3, OUT: 3)
IN: 3 Rest in Peace
OUT: 1 Memory Deluge, 2 Absorb
Rationale: Rest in Peace shuts down the entire strategy; trim expensive interaction.

每项都必须列明具体的加入牌和移出牌，并用一句话说明理由。加入和移出的牌数必须相等（主牌总数保持 60 张）。

提供选项（不要强迫）
  • 比较调整前后的法力曲线
  • 比较分类明细
  • 面向未来预算的“下一步升级”清单

步骤 13：实测对局（可选）

在用户提出要求时运行，或者当牌组在两个合理的删牌／加牌方案之间难以抉择、希望通过实测获得参考时运行。

构筑赛（60 张）： 使用 playtest-match 对阵标准基准牌组。 对于 Modern，phase 仓库提供了基准对决牌组，位于 crates/phase-ai/duel_decks/modern/{affinity,amulet-titan,boros-energy}.json。 转换调优后的牌组并运行：

playtest-match my-deck.json affinity.json --games 100 --seed 1 \
  --output playtest-match.json

指挥官／Brawl： 运行 playtest-goldfish（没有广泛认可的单一对手基准）。默认运行 1,000 局 × 8 回合，并报告调度率、每回合平均地牌数、每回合平均施放数，以及颜色受阻率。

playtest-goldfish my-deck.json --bulk-data <bulk-data-path> \
  --games 1000 --turns 8 --output playtest-goldfish.json

法术力模型近似——展示金鱼测试结果时请说明。 金鱼测试会将地牌，以及每张被施放且被 Scryfall 标记为能产出法术力的非地永久物，都计入法术力。这包括真正的法术力石／法术力生物（Sol Ring、Signet、Birds），也包括产出法术力衍生物的牌（Treas​​ure：Pitiless Plunderer、Deadly Dispute；Gold；Eldrazi Spawn：Awakening Zone），因为 Scryfall 会为它们填入 produced_mana。产出衍生物的牌会近似视为稳定的 每回合约 1 点法术力来源——模拟器不会模拟它们实际的触发条件（死亡／攻击／维持），也不会模拟一次性的牺牲；多色的 produced_mana 也会按每回合 1 点任意颜色的法术力计算，而不是 5 点。因此，衍生物加速只会被粗略而非精确地纳入计算（不会模拟时机和条件）。请告知用户，对于衍生物较多的牌组，曲线／施放数只是近似值。

会模拟找地效果（此前没有模拟——这一遗漏会导致颜色受阻结果颠倒：牌组修正能力越强，报告的颜色受阻反而越多）。找地地会产出该牌组所含基本地的颜色，而不是不产出法术力；具有进场触发效果的找地牌（Wood Elves、Sakura-Tribe Elder）会将一张地牌从牌库移至战场；两者都会遵守“进场时横置”的条件，将产出延后一回合。带有起动费用的找地效果——Knight of the Reliquary 的 {T}, Sacrifice a Forest、Burnished Hart 的 {3}, {T}, Sacrifice——会刻意不予计入，因为该费用没有被建模，错误地免费提供法术力会造成更大偏差。（原因是费用，而不是召唤失调：CR 302.6 的适用范围仅限于生物，因此神器找地牌在进场的回合可以合法横置。） “搜索……并将其置入你手上”的效果不会立即提供法术力，只能在之后作为地牌使用。

向用户反馈： 原样呈现标准输出中的 Markdown 报告。不要根据结果自动建议删牌——由用户阅读报告并自行决定。如果用户提出后续问题（“我该删掉什么？”），则将其视为常规的删牌与加牌迭代，并将实测数据作为新的上下文。

首次运行的先决条件： 如果 playtest-match 报错“phase binary not found”，只需告知用户一次：playtest-install-phase（约 5–10 分钟，仅需运行一次）。

步骤 14：打印代理牌（可选）

当用户想要进行实体牌实测时：

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

proxy-print 会为牌组中的牌生成一个 PDF，并为牌组产出的每种衍生物各生成一个 PDF。--by-name 可让多种名称相似的牌（例如 Karplusan Forest 与 Sacred Foundry）使用不同的牌面图。布局详情和目录设置请参阅 proxy-printer/SKILL.md。

危险信号

想法现实
“我知道这张牌的作用”你不知道。查一下。训练数据不是权威文本。
“这是该赛制的必备牌，自动加入”核实赛制是否合法、oracle 文本和价格。
“EDHREC 推荐了它，所以它在这里肯定好用”EDHREC 是汇总数据，不是分析。要针对这个构筑进行评估。
“这是该赛制的必备牌，不可能被剔除”结合实际情况评估。必备牌在特定构筑中也可能表现不佳。
“这张牌在 Commander 中通常很好用”通用必备牌并非总是合适。检查它与这位指挥官的协同。
“这张牌通常很弱”通常很弱 ≠ 配合这位指挥官也弱。阅读双方的 oracle 文本。
“备牌可以以后再说”备牌是竞争优势的一半。现在就构建。（60 张牌）
“备牌没问题，先专注主牌”备牌能赢下比赛。评估它。（60 张牌）
“用户说要快攻，所以放 20 张地”按公式计算。用 mana-audit 核实。
“我就照搬示例牌表”根据预算、心头好和用户偏好进行调整。
“跳过结构验证吧，看起来没问题”工具能发现人会漏掉的错误。运行它们。
“这张牌的纸牌价格很低，所以在 Arena 上没问题”纸牌价格 ≠ Arena 稀有度。使用 price-check。
“我们超预算了，但这张牌太强了，不能不带”预算是硬性限制。找更便宜的替代品。
“我就用必备牌把剩下的位置填满”每张牌都应有加入的理由。必备牌是最后手段，不是捷径。
“法术力基础大概没问题”运行 mana-audit。不要凭感觉判断法术力基础。
“这一步对这副套牌好像没必要”遵循每一步流程。这个流程存在，就是因为走捷径会导致错误。
“知名牌可以跳过 oracle 文本核实”不行。每张牌都要查。即使是 Sol Ring，也值得阅读它的 oracle 文本。
“那只是一个强化光环／法术力石／没用的神器”你说的是类别，不是这张牌。类别不是评判结论。在决定前，引用你要据以剔除的规则条款，也引用你不会据以剔除的规则条款。
“我把所有候选牌的 oracle 文本都导出来了，所以我读过了”批量导出只是为了方便，不等于执行剔除检查清单。逐张牌运行清单。并确认导出内容能显示 card_faces——DFC 会悄无声息地变成空白。
“工具什么都没返回，所以没有问题”对指挥官核心机制没有任何反馈，说明工具出了问题，而不是一切正常。把空列表当作通过之前，先确认这个字段实际测量的是什么。
“这副套牌的 X 数量不足”先测量。对当前套牌和提案使用相同的计数方式，并报告两者的结果。未经测量就说“你缺少 X”，可能会成为剔除会破坏 X 的牌的理由。
“这张牌最弱，显然该剔除”如果理由四个词就说完了，你还没完成第 1 项。为了腾出位置而剔牌时，最容易轻率剔牌——就在这里放慢速度。
“跳过自我拷问吧，分析已经很全面了”自我拷问正是为了发现这种过度自信。每次都要执行。
“我运行了 cut-check + mana-audit + price-check，涵盖第 8 步了”不对。这些是第 7 步的机械性关卡。第 8 步是策略性关卡，需要调用两次 Agent 工具。
“这副套牌刚由构筑器生成，自我拷问有点小题大做”构筑器不会进行对抗性审查。新生成的骨架是最适合进行挑战者审查的时机。
“我下回合／等用户确认后再派遣 Agent”不行。第 8 步必须在第 9 步之前完成。
“我会在同一条消息里打包第 9 步提案和第 11 步 AskUserQuestion”不行。AskUserQuestion 会在周围的 Markdown 内容提交之前渲染选项按钮，所以打包在一起意味着用户会在看不到完整内容的情况下批准。先在第 9 步单独一轮写出提案。
“我会相信牌组已填充 sidecar 中的 rarity 字段来制定 Arena 预算”不行。该字段是 Scryfall“default”印刷版本的稀有度。Arena 稀有度要用 price-check --format <fmt> --medium digital。
“我会检查套牌中的组合技，但提剔牌建议时跳过差一点成套的搭档扫描”不行。差一点成套的组合技是 <missing> + <partner1> + <partner2> = <result>。你的剔牌清单可能会悄悄选中一个 partner。针对第 5 步中所有差一点成套的搭档位置，检查每张拟剔除的牌。
“我直接覆盖 /tmp/cuts.json，然后在同一条消息里运行 cut-check”不行。从之前会话遗留的现有 /tmp 路径执行第一次 Write 会失败，但并行的 Bash 调用会基于过期内容运行。
“我用 python3 -c 快速计数／筛选／提取”先查决策表。几乎所有常见任务都有现成脚本覆盖。
“跳过影响验证吧，这些替换看起来很稳妥”只有构筑完成后才能看出的跨替换涌现效应。运行检查。
“这张牌太贵了，不能剔除”沉没成本。依据牌的价值评估，而不是价格。
“这张牌会让我的一张牌失效，所以必须剔除”统计它会影响多少张牌。99 张中只有一两张的话，这只是打牌时需要留意的事项。剔除或否决它之前，权衡同一规则条款对对手的影响。
“在同一条消息里提出修改并征求批准”第 9 步要单独一轮。AskUserQuestion 在第 11 步提出。
“法术力基础已经够接近了”运行 mana-audit。“够接近”正是你因颜色卡手而输掉比赛的原因。
“用非地牌替换这张地没问题，地已经够多了”数一数地。数一数加速牌。算清楚。不要凭感觉判断法术力基础。
“我还能再少放一张地，加速牌能弥补”运行 mana-audit。如果结果是 FAIL，就不行。加速牌不能替代地。
“我明白这位指挥官需要什么”说出你的策略判断并询问用户。玩这副套牌的是他们，不是你。
“这张牌只有和套牌里另外 N 张牌配合才有用”检查这张牌能否创造自己的触发条件。
“这个触发效果太小，没什么影响”乘以预期的额外触发次数，再乘以对手数量。算清楚。
“这是重复的闪避／保护效果”剔除前，检查它是否有其他牌无法复现的独特机制互动。

经验水平适配

方面初级中级高级
面试解释所有术语并举例使用术语并简要说明背景使用简写
术语定义术语（卡差、节奏等）自由使用术语使用简写
环境解析定义套牌类型并解释对局说出套牌类型并指出关键牌默认读者了解相关知识，专注于新颖角度
推荐解释每张牌为何重要突出协同作用分类列出并简要说明
换牌理由用完整句子解释旧牌为何较差指出具体互动简洁说明：“Bolt > Shock（占卜 1 的额外收益）”
策略解释策略的运作方式及原因解释关键互动说出套牌类型和关键牌
备牌指南解释换备牌的含义针对每种对局给出换入／换出方案简写换备牌表
法术力基础解释地牌类型和理想曲线指出法术力基础的取舍专注于细微优化
呈现方式结合示例进行叙述式讲解分组分析并附说明使用简洁的表格

脚本参考

核心脚本
  • parse-deck <path> [--format FORMAT] [--deck-size N] [--output PATH] — 解析牌表。将 JSON 写入标准输出或 --output 指定的 PATH。支持 Moxfield、Arena、MTGO、纯文本和 CSV。<path> 必须是绝对路径。
  • set-commander <deck.json> "Name" ["Name2"] — 将牌移至指挥官列表。可重复执行，结果不变。
  • deck-hydrate <deck.json> [--bulk-data <path>] — 预热／验证牌表已填充数据的 sidecar（deck.json → deck.hydrated.json，以牌表内容、批量数据身份和版本为键）。标准输出为 JSON 封装 {sidecar_path, card_count, missing, digest}。其他所有牌表 CLI 都会以相同方式自行填充数据，因此只有在获取数据后需要显式检查点时才需使用此命令（检查 missing）。
  • scryfall-lookup --batch <names.json> --bulk-data <path> --cache-dir <dir> — 填充名称列表（候选牌、个人偏爱牌、组合技组件）的数据，而非牌表。标准输出为 JSON 封装 {cache_path, card_count, missing, digest}。
  • scryfall-lookup "<Card Name>" --bulk-data <path> — 查询单张牌
  • card-summary <deck.json> [--nonlands-only] [--lands-only] [--type <T>] [--sideboard] [--bulk-data <path>] — 显示牌表卡牌表格（默认显示主牌）。也接受 JSON 卡牌记录列表（例如 scryfall-lookup --batch 的 cache_path），并根据结构自动识别。
  • card-search --bulk-data <path> [--format FORMAT] [--color-identity CI] [--oracle REGEX] [--type TYPE] [--cmc-min N] [--cmc-max N] [--price-min N] [--price-max N] [--sort price-desc] [--limit 25] [--json] [--fields F1,F2,...] [--arena-only] [--paper-only] [--is-commander] — 搜索本地批量数据
  • combo-search <deck.json> [--bulk-data <path>] [--max-near-misses N] [--output PATH] — 查找已有组合技及差一点达成的组合技
  • combo-discover [--card "<name>"] [--result "<outcome>"] [--color-identity CI] [--format FORMAT] [--arena-only] [--paper-only] [--bulk-data PATH] [--output PATH] — 按结果或卡牌发现组合技
  • legality-audit <deck.json> [--bulk-data <path>] [--output PATH] [--cite-rules/--no-cite-rules] [--rules-file <path>] — 检查合法性、卡牌数量限制、备牌数量、牌表最低张数和颜色标识
  • mana-audit <deck.json> [--compare <new-deck.json>] [--bulk-data <path>] [--output PATH] — 审核法术力基础（指挥官赛制采用 Burgess／Karsten 方法，构筑赛制采用 60 张牌公式）
  • price-check <deck.json> [--format <fmt>] [--medium paper|digital] --bulk-data <path> [--budget <N>] [--output PATH] — 检查预算。medium 用于选择模式：digital（Arena）按稀有度报告替代牌费用，paper 报告美元价格。默认值：使用牌表 JSON 中的 medium，否则使用赛制对应的值（Standard 和 Pioneer 默认使用 paper）。
  • deck-stats <deck.json> [--bulk-data <path>] [--output PATH] — 统计牌表
  • deck-signals <deck.json> [--bulk-data <path>] [--json] — 通过 deck-forge 检测器获取牌表的信号类别（指挥官的 oracle 文本所关注的内容）。结果确定。
  • slot-budgets <deck.json> [--bulk-data <path>] [--shape aggro|midrange|control|combo] [--json] — 查看相对于模板的角色密度区间（land/ramp/card_draw/interaction/board_wipe）。牌表张数取自牌表 JSON。结果确定。
  • deck-rank <deck.json> <candidates.json> [--bulk-data <path>] [--limit N] [--json] [--medium paper|digital] [--meta auto|off|<archetype>] — 按候选记录（来自 card-search --json）与牌表信号类别的协同度排序，其次按价格排序，最后按曲线排序。绝不使用 EDHREC 热度。在已缓存 arena-meta 原型的 digital 构筑中，会优先依据卡牌占比打破协同度平局（--json 中的 meta_share；ADR-0059）。
  • build-deck <deck.json> --cuts <c.json> --adds <a.json> [--sideboard-cuts <sc.json>] [--sideboard-adds <sa.json>] [--bulk-data <path>] [--output-dir <dir>] — 应用更改。cuts/adds 接受 [{name, quantity}] 字典或纯名称字符串。写入 new-deck.json 及其自身的 new-deck.hydrated.json sidecar。
  • deck-diff <old.json> <new.json> [--bulk-data <path>] — 比较牌表版本
  • export-deck <deck.json> [--style auto|moxfield|arena] — 导出包含备牌／搭档分区的导入文本。auto（默认）会为 Arena 赛制输出 Arena 的 Commander / Deck 分区标题，其他情况则输出不带标题的 Moxfield 行。
  • mark-owned <deck.json> <collection.csv> [--bulk-data <path>] [--output PATH] — 标记已拥有的卡牌。用于 Arena 时务必传入 --bulk-data。
  • `download-mtgjson — 下载 MTGJSON 卡牌数据
  • cut-check <deck.json> --cuts <path> --multiplier-low N --multiplier-high N [--commander "<Name>"] [--trigger-type TYPE ...] [--opponents N] [--bulk-data <path>] [--output PATH] — 机械式预审分析（仅限指挥官赛制）。默认从牌表的 commanders 区域读取指挥官；--commander 可覆盖此设置。
  • edhrec-lookup "<Commander Name>" ["<Partner>"] — 获取 EDHREC 推荐（仅限指挥官赛制）
  • web-fetch "<url>" --max-length 10000 — 使用浏览器标头和 curl 回退机制获取网页
  • find-commanders <parsed.json> --bulk-data <path> [--format FORMAT] [--color-identity CI] [--min-quantity N] [--output PATH] — 从收藏中查找符合指挥官资格的卡牌
  • mtga-import --bulk-data <path> [--log-path PATH] [--output-dir DIR] [--force] — 从 Player.log 提取 Arena 收藏和替代牌。若 collection.json 并非由此命令写入（例如由 parse-deck 生成的 CSV 收藏），则拒绝覆盖，除非指定 --force。

评论

支持 Markdown