deck-strat

Deck Strat

为已完成的 MTG 套牌编写一份策略指南——一份 Markdown 文档，说明如何操控这副套牌。文档按固定的核心框架组织，并包含依原型而定的章节；所有涉及规则的说法都必须依据《综合规则》核实。每条建议都必须以实际的 Oracle 文本和 CR 引用为依据，绝不能依据训练数据。

deck-strat 对套牌只读，不会建议删牌、加牌或调整。若用户想先调整套牌，请引导他们使用 /deck-wizard，然后再对最终牌表运行 /deck-strat。两个技能共用工作目录和套牌的已填充 sidecar（deck.hydrated.json），因此可透明地串联使用。

铁律

绝不臆测牌张或规则的作用。 在将任何内容写入指南之前：

• 关于牌张的行为：通过 scryfall-lookup 查询其 Oracle 文本，或从套牌的已填充 sidecar 中读取。训练数据不是 Oracle 文本。
• 关于规则的行为：通过 rules-lookup（--rule、--term 或 --grep）查询，并引用原文。训练数据不是 CR。

对指挥官区域行为、堆叠时机或替代效应交互作出自信但错误的判断，会使整份指南失去可信度。规则审计子代理（第 10 步）是把关环节，会找出遗漏的错误判断——但每个撰写的句子在提交审计前都应有充分依据。

范围

deck-strat 支持 Commander、Brawl 和 Historic Brawl（采用指挥官机制的单卡构筑多人赛制）。v1 不支持 60 张构筑赛制——它们的策略产物是备牌计划加对局矩阵，形式不同，且 /deck-wizard 的第 12 步已经会生成。

赛制	套牌张数	牌池	多人游戏	备注
commander	100	全部永恒赛制牌池	是（通常 4 人）	40 点生命，指挥官伤害规则
brawl	60	标准赛制	Arena 上为 1v1，纸牌环境中为多人游戏	25/30 点生命，无指挥官伤害
historic_brawl	100	Arena（牌池比标准赛制更广）	Arena 上为 1v1，纸牌环境中为多人游戏	25/30 点生命，无指挥官伤害
competitive_brawl	100	Arena，排除 10 张禁牌	始终为 1v1	25 点生命，无指挥官伤害，没有免费调度

Competitive Brawl（competitive_brawl）受支持，且是独立赛制——不能当作 historic_brawl 的变体来审计。它始终为 1v1，起始生命为 25，且没有免费调度，因此不要引用 CR 903.12g 中的首次免费调度规则；该规则适用于普通 Brawl。它的禁牌表与普通 Brawl 不同（共有十张牌不同，而普通 Brawl 禁用的大多数牌在此赛制中都合法）；合法性以 MTGJSON 自身的 competitivebrawl 键为准。此赛制的指南应完全跳过多人游戏／政治相关章节。

如果用户对 60 张构筑套牌运行 deck-strat，请拒绝并引导他们：“此技能用于生成单卡指挥官赛制的多人游戏策略指南。对于 Standard／Modern／Pioneer 等赛制，请运行 /deck-wizard——其第 12 步的最终定稿内容包含备牌指南。”

进度跟踪

开始前，创建一个包含以下 10 项的 TodoWrite 列表。 每项开始时标记为 in_progress，完成后立即标记为 completed——不要批量更新。

1. 解析套牌 + 设置指挥官
2. 通过 deck-hydrate 填充数据
3. 基线诊断
4. 指挥官交互审计
5. 原型检测
6. 组合技 + 未遂组合检测
7. EDHREC 研究
8. 规则核实
9. 起草策略指南
10. 规则审计子代理 + 修订

第 4 步耗时较长，开始时应在列表中展开子任务（子待办：关键字组合、触发倍增、反馈循环、可重复使用的牌、指挥官倍增、组合技检测）。第 10 步也耗时较长，应展开子任务（派发审计、处理报告、修订草稿）。

第 10 步之后的迭代（用户要求的编辑）不属于重新运行完整流程——应将每项用户请求作为对现有指南的 Edit 处理。

首次运行设置

uv sync --directory <skill-install-dir>
download-mtgjson
download-rules --output-dir <working-dir>

后续运行会在 .venv 存在、批量数据为最新（24 小时内）且 CR 为最新（24 小时内）时跳过。如果 CR 文件未存放在工作目录中，而是存放在技能安装目录中，则必须移到工作目录；rules-lookup 和 Rules Audit 子 Agent 都会在工作目录中查找。

工具说明

工作目录与路径

• 仅使用绝对路径。 uv 会将工作目录重新设为技能安装目录；相对路径会解析到错误的根目录。
• 已填充的 sidecar： deck-hydrate 会将其写在 deck JSON 旁边——<working-dir>/deck.json → <working-dir>/deck.hydrated.json。无需管理缓存目录；每个 deck CLI 都会读取 deck JSON，并通过同一个 sidecar 完成填充。
• CR 文件： <working-dir>/comprehensive-rules-YYYYMMDD.txt。
• 批量数据： <skill-install-dir>/default-cards.json。
• 输出： <working-dir>/STRATEGY-GUIDE.md。

复用的 CLI

deck-strat 不提供自己的 CLI。以下每个工具都在 deck-strat/pyproject.toml 中从 mtg_utils 重新声明。从技能安装目录运行 uv run <name> 来调用。

阶段	工具	用途
获取	parse-deck	解析牌表（Moxfield、MTGO、Arena、纯文本）→ deck.json
获取	set-commander	将指挥官移入 commanders 列表（幂等）
获取	deck-hydrate	构建／验证牌组的已填充 sidecar；报告卡牌数量和缺失名称
获取	scryfall-lookup "<name>"	验证特定卡牌时进行单卡查询
获取	download-mtgjson	刷新 Scryfall 批量数据（24 小时新鲜度检查）
获取	download-rules	刷新 CR 文本（24 小时新鲜度检查）
诊断	legality-audit	格式合法性、卡牌数量限制、颜色特征
诊断	deck-stats	地牌／加速／生物数量、费用曲线、颜色来源、GC 数量
诊断	mana-audit	Burgess／Karsten 地牌目标与颜色平衡
诊断	card-summary	精简的 Oracle 文本表格（地牌／非地牌／类型）
分析	archetype-audit	对牌组进行主题密度正则表达式检测（衍生物、牺牲、复活等）
分析	combo-search	通过 Commander Spellbook 查找现有组合技和近似组合技
分析	combo-discover	可选：按结果／卡牌／颜色探索组合技
分析	edhrec-lookup	指挥官的社区热门卡牌和高协同卡牌
分析	arena-meta	Arena 牌组：队列环境、牌组的环境套牌类型及其核心（ADR-0059）
分析	card-search	EDHREC 结果为空时，用于发现卡牌的备用工具
分析	web-fetch	WebFetch 被阻止时获取策略文章
验证	rules-lookup	按 --rule、--term、--grep 查询 CR
验证	rulings-lookup	查询 Scryfall 的单卡裁定

JSON 文件写入

对于任何包含卡牌名称的 JSON 文件，请使用 Write 工具，而不要使用 Bash heredoc。撇号会破坏 shell 引号；Write 工具的权限可在整个会话中稳定缓存。

临时文件路径

在一个会话中重复使用以下稳定路径：/tmp/audit-claims.json（由 Rules Audit 子 Agent 使用）、/tmp/combo-search.json（未指定 --output 时的组合技检测输出）。

警告： /tmp 文件会跨会话保留。会话开始时，请在首次 Write 之前读取计划复用的每个临时文件路径；或者按顺序运行 Write，并在执行依赖它的 Bash 调用前确认写入成功。

混合式规则顾问集成

参见 ADR-0008。 deck-strat 使用两种路径验证规则：

1. CLI（rules-lookup、rulings-lookup）——常规声明。 如果一项声明可以通过一条规则编号、一个术语表词条或一个范围狭窄的正则表达式来验证，默认使用此路径。例如：“辟邪能阻止以自身为目标吗？”→ rules-lookup --term shroud；“免费进行的第一次调度是指挥官规则吗？”→ rules-lookup --grep "first mulligan"。
2. Skill 工具（Skill(rules-lawyer, ...)）——复杂声明。 在以下情况下升级处理：（a）声明涉及两条或更多规则，而规则之间的相互作用是关键部分；（b）相关规则的文字说明较少，需要查看某个章节片段；或（c）验证需要推理层、替代效应的排序，或触发式与起动式异能之间的堆叠时机。rules-lawyer 技能自带 Phase 1/2/3 升级处理规范（包括调度子 Agent），此处不重复说明。

Phase 3 规则验证阶段（步骤 8）和规则审计子 Agent（步骤 10）都遵循相同的升级规则。

重新水合

deck-strat 无需考虑这件事。如果牌组 JSON 在会话中途被编辑（例如，用户在迭代过程中发现卡牌名称有误，你重新解析了文件），水合后的 sidecar 会在文件内以牌组内容哈希值、bulk 标识和负载版本为键——过期的 sidecar 从设计上就无法读取，因此下次调用工具时会自动重建。无需重新传递缓存路径；只需针对编辑后的 deck.json 重新运行 deck-hydrate（或任何分析 CLI）。

---

Phase 1：获取

步骤 1：解析 + 设置指挥官

接受原始牌组列表（.txt、Moxfield 导出、MTGO 格式、粘贴的文本）或已解析的牌组 JSON。如果是原始列表：

parse-deck <path> --format <commander|brawl|historic_brawl> \
    --output <working-dir>/deck.json

如果输入已经是解析后的牌组 JSON，则直接接受，并验证其 format 字段是否与三种受支持格式之一匹配。

解析时始终显式传入 --format。如果不传，parse-deck 默认使用 commander，下游工具会得到错误的格式。

如果已解析牌组的 commanders 列表为空（Moxfield 导出中没有 //Commander 标题时很常见），请询问用户谁是指挥官。不要猜——第一张牌不一定是指挥官。支持：

• 单指挥官：set-commander <deck.json> "Name"
• 伙伴 / 永恒挚友：set-commander <deck.json> "Name1" "Name2"
• 指挥官 + 背景：set-commander <deck.json> "Commander" "Background"

set-commander 是幂等的——即使牌组文件已经包含指挥官标题，也可以安全地在 parse-deck 后接着运行。

询问驾驶档位

解析后，询问用户：

“你驾驶这套牌组时采用哪个强度档位？（1-5 / 休闲 / 升级 / 优化 / cEDH，或 auto。）这会决定指南如何权衡政治博弈、连招突出程度和威胁评估。”

默认使用 auto：统计游戏改变者（通过 deck-stats）、统计致胜连招（通过 combo-search，稍后运行），并评估曲线。映射如下：

• 0 张 GC、0 个无限连招、曲线 ≥ 3.5 → Bracket 2（休闲）
• 1-2 张 GC、0-1 个连招、曲线 3.0-3.5 → Bracket 3（升级）
• 3 张以上 GC、2 个以上连招、曲线 ≤ 3.0 → Bracket 4（优化）
• 所有快速导师 + 免费互动 → cEDH（Bracket 5）

如果用户明确指定了档位，优先采用。如果用户说 auto 或没有回答，才自动检测。记录最终确定的档位——所有后续步骤都会使用该档位。

步骤 2：补全数据

deck-hydrate <working-dir>/deck.json \
    --bulk-data <skill-install-dir>/default-cards.json

标准输出是一个 JSON 信封，包含 sidecar_path、card_count、missing， 以及包含计数和曲线的 digest。辅助文件会放在牌组 JSON 旁边（deck.json → deck.hydrated.json）；下面每次调用下游工具时只需传入 deck.json，工具会通过它自行补全数据。不要直接 Read 辅助文件——文件很大，会大量占用上下文。检查时请使用 card-summary、Grep '<regex>' <working-dir>/deck.hydrated.json，或针对性的 scryfall-lookup "<Name>" 调用。

如果 missing 不为空，说明用户的牌组中包含无法识别的卡牌名称——请让他们核实。常见原因包括：拼写错误、未能剥离的系列代码后缀、Arena/实体卡牌名称交叉变更（Paradise Chocobo = Birds of Paradise、Skittering Kitten = Masked Meower 等）。

---

阶段 2：分析

以下五个步骤会分别通过牌组的辅助文件补全数据——必要时可以并行运行 CLI 调用。每个步骤都会填充后续步骤所需的上下文。

步骤 3：基线诊断

按以下顺序运行（先运行失败成本最低的检查）：

legality-audit <deck.json>
deck-stats <deck.json>
mana-audit <deck.json>
card-summary <deck.json> --nonlands-only
card-summary <deck.json> --lands-only

• legality-audit 必须通过（PASS）。如果失败（FAIL），请指出违规之处并询问用户如何解决（不能基于不合法的牌表编写指南）。不要提出修复方案——这是 deck-wizard 的工作。
• deck-stats 会提供 Game Changer 数量、曲线、颜色来源、加速数量和替代费用卡牌。记录替代费用卡牌（suspend、foretell、evoke、escape、flashback、adventure）——在策略指南中，这些牌按其替代费用而非印刷的 CMC 进行评估。
• mana-audit 可能返回 WARN 或 FAIL——请记录，但不要提出修复方案。指南可以将法术力基础列为调整时需要考虑的因素。
• card-summary 供你阅读；不要原样粘贴到指南中。

步骤 4：指挥官互动审计

这是整个流程中影响最大的分析步骤——它能揭示单独阅读卡牌时看不到的协同效应。原样继承自 deck-wizard 步骤 5；分析维度相同。

针对每位指挥官（对于 partner/background 组合，双方都要分析），以及整副牌组，依次分析以下六个维度并记录发现。策略指南的“核心循环”“协同效应”和“常见路线”部分将依据这些记录编写。

子任务（开始步骤 4 时展开为 TodoWrite）：

4a. 关键字组合

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

• **规避叠加：**威慑 +“不能被多于一个生物阻挡”＝无法被阻挡。任何阻挡限制与相冲突的阻挡要求组合，都可能使其无法被阻挡。
• **伤害倍增：**连击 + 战斗伤害触发＝触发两次。连击 + 系命＝获得双倍生命。践踏 + 死触＝造成 1 点伤害即可消灭阻挡者，其余伤害践踏过去。
• **防护叠加：**守护 + 辟邪、不灭 + 再生。判断哪些效果重复，哪些互为补充。

4b. 触发倍增

找出指挥官的核心倍增机制（额外维持阶段、额外战斗阶段、额外回合、额外阶段、复制触发、加倍衍生物等）。对于牌组中在倍增时段内触发的每个异能，分别计算其在基础速率的 1×、3× 和 5× 时的产出。策略指南应将倍增后的数值作为现实情况，而非 1× 基础值。

对于触发效果会随战斗伤害而增加的指挥官，应将力量加成视为战略支柱——每 +1 力量不只是 +1 伤害，还会让倍增时段内的每个效果多触发一次。

4c. 反馈循环

对每张牌，询问：“这张牌的输出是否会反馈到自身的输入或指挥官的触发条件中？”例如：

• 指挥官的触发效果会随力量变化，而这张牌能提供 +1/+1 指示物。
• 能创造衍生物的牌会增加另一张牌用于计算效果的数量。
• 具有窃取效果的牌会让被窃取的永久物改变类别，以匹配部族数量。

具有反馈循环的牌几乎总是比单独看来更强。指南应在“协同”部分标出它们。

4d. 可反复使用的牌

找出所有能让自身返回可用区域的牌：再次延缓、返照、追溯、脱出、闪回、“返回手牌”条款、“放逐并带有时间指示物”的效果。指南应按每局游戏的价值（典型对局中免费施放的总次数）评估这些牌，而不是按每次施放的价值评估。

4e. 指挥官增效

找出所有能放大指挥官影响力的牌：

• 复制指挥官：Helm of the Host、Spark Double、Clone 效果、Mirror March、Followed Footsteps。非传奇复制品可绕过传奇规则，并保留所有触发式和起动式异能。
• 异能复制牌／触发倍增牌：Strionic Resonator、Rings of Brighthearth、Panharmonicon（适用于进战场触发式指挥官）、Teysa Karlov（死亡触发）、Isshin（攻击触发）、Seedborn Muse（额外起动）。

直接检查 Oracle 规则文本——这些牌是增效器，应在指南的“协同”部分重点介绍。

4f. 组合技检测

此子步骤衔接到第 6 步。运行：

combo-search <deck.json> \
    --output <working-dir>/combo-search.json

区分：

• 制胜组合技（结果包含“无限”或“赢得游戏”）：重点标出。这些是指南“胜利条件”和“组合技执行”部分的核心内容。
• 价值互动（非无限协同）：作为背景信息注明。

在建议指南将一个差一步的组合技作为“只差 1 张牌”的终结路线提及之前，请从 JSON 中 Read 该组合技差一步版本的完整 description 字段。精简文本报告会省略牌表中没有的必需组件。

第 5 步：流派检测

使用精心筛选的预设列表运行 archetype-audit，以确定策略指南将呈现哪些条件章节。结果是一组主题密度——高于警告阈值的主题会触发对应的条件章节。

archetype-audit <deck.json> <deck.hydrated.json> \
    --include-commanders \
    --preset tokens \
    --preset sacrifice-outlet \
    --preset reanimate \
    --theme 'goad=goad|attacks each combat if able' \
    --theme 'aristocrats-drain=whenever .* creature .* dies|sacrifice .* creature' \
    --theme 'token-doubler=create twice that many|tokens .* plus that many' \
    --theme 'opponents-create-tokens=that.*player.*creates|each.*opponent.*creates' \
    --theme 'extra-combats=additional combat phase|extra combat' \
    --theme 'extra-turns=take an extra turn|additional turn' \
    --theme 'big-mana=add (any|four|five|six|seven|eight)' \
    --min-density 4 --warn-density 6 --show-matches

始终传入 --include-commanders——对于指挥官赛制，指挥官通常是占比最大的主题牌。

将主题密度（按牌的张数计算）映射到条件章节：

检测到的主题（≥ 警告阈值）	要呈现的条件章节
token + token-doubler	衍生物倍增计算章节
aristocrats-drain + sacrifice-outlet	贵族流派的出牌顺序章节
goad + opponents-create-tokens	政治策略章节
extra-combats	战斗倍增计算章节
extra-turns	额外回合的出牌顺序章节
reanimate	复活路线章节
big-mana	法术力增幅的收益章节
存在制胜组合技	组合技执行章节
指挥官具有武装战士特征	武装战士指挥官伤害计算章节
指挥官具有进战场触发，且牌组中有 Panharmonicon 类牌	进战场效果倍增章节

手动识别具有武装战士特征的指挥官：其 Oracle 规则文本提供闪避能力 + 随力量变化的效果；牌组包含 6 张或更多装备／灵气；且牌组缺少宽铺战场引擎。

第 6 步：组合技与近似组合技检测

第 4f 步的组合技搜索调用已经填入了结果。现在检查组合技：

• Bracket 1-2：政策禁止有意设计的双牌无限组合技。如果套牌中存在无限组合技，指南会将其标记为 Bracket 合规问题，并询问用户应将其视为意外的组合技路线，还是实际的获胜手段。
• Bracket 3：允许无限组合技，但不应在第 6 回合之前稳定发动。指南会注明发动时机。
• Bracket 4 / cEDH：没有限制。组合技路线是指南的核心内容。

近似组合技（距离组合技只差 1 张牌）：指南会加入“值得了解的已知近似组合技完成方式”提示，列出缺少的组件，以及完整组合技的效果。这仅供参考，并非建议更改套牌。

第 7 步：EDHREC 调研

edhrec-lookup "<Commander Name>"

针对搭档组合：

edhrec-lookup "<Commander 1>" "<Commander 2>"

EDHREC 会提供社区热门牌、高协同牌和套牌数量。用它来：

• 确认对套牌原型的判断是否合理。
• 找出套牌中被 EDHREC 标记为高协同的牌（这些牌会在指南中突出展示）。
• 找出 EDHREC 标记为常见构筑用牌、但套牌中没有的牌——在套牌备注中注明为“刻意舍弃的牌”。

**Brawl/Arena 注意事项：**EDHREC 数据来自 Commander/EDH 套牌。对于 Brawl/Historic Brawl，引用 EDHREC 建议前，必须根据套牌赛制检查其合法性。

EDHREC 没有数据时的备用方案（新指挥官或冷门指挥官）：

1. 使用 card-search 搜索指挥官机制关键词，查找符合颜色标识的协同牌。
2. 查询该原型，而非特定指挥官。
3. 指南继续撰写，但不包含“社区对比”提示。

谨慎使用 WebSearch + WebFetch——仅在需要了解冷门指挥官的战略背景时使用。如果 WebFetch 被阻止，可使用 web-fetch 脚本作为备用方案。

**Arena 套牌：天梯环境。**为 Arena 构筑的 Historic Brawl 或 Competitive Brawl 套牌会进入 Untapped.gg 跟踪的队列（普通 Brawl 没有相应队列）。如果不知道玩家的段位，请先询问，然后根据段位使用 --ranks 运行（默认 platinum+；低于此段位时可用 diamond+、mythic 或 all）：

arena-meta --deck <deck.json> --ranks <rank>+ --json

它会读取缓存的环境数据，并在缓存超过 24 小时时获取新数据。首次获取可能需要运行 arena-meta --login（用户需登录 Untapped 一次）。保留 field（白金及以上段位将面对的环境原型及其占比）、套牌的 match 和 core。这些内容会用于“你将面对什么”部分。如果套牌与任何环境原型都不匹配，或没有缓存数据，请在套牌备注中说明，并跳过该部分。

---

第 3 阶段：撰写

步骤 8：规则核验

撰写指南前，列出你打算提出的所有与规则相关的说法。这些说法来自步骤 4（指挥官互动审查）和步骤 6（组合执行流程）。根据上述混合整合规则，逐条通过 CLI 核验，或转交给 rules-lawyer 技能。

常见说法类型及其核验方式：

说法类型	默认核验方式
某个关键字的作用（shroud、deathtouch、menace、trample 等）	rules-lookup --term <keyword>
某条具体规则的内容（903.9、603.8、702.18 等）	rules-lookup --rule <n>
某张牌的 Oracle 文本是否与描述相符	scryfall-lookup "<name>"
针对特殊情况的单卡裁定	rulings-lookup --card "<name>" --bulk-data <path>
触发式异能与起动式异能之间的堆叠顺序	Skill(rules-lawyer, ...)
替代效应与另一替代效应的互动	Skill(rules-lawyer, ...)
层的判断（持续性效应）	Skill(rules-lawyer, ...)
指挥官区域行为（903.9a / 903.9b）	先执行 rules-lookup --rule 903.9a，再执行 --rule 903.9b
防护阻止某个 异能（鹏洛客的负向忠诚异能、起动式或触发式异能）	先执行 rules-lookup --rule 702.16b，再执行 --rule 113.7：防护会阻止具有该特性的来源之异能指定目标，因此，具有某种颜色的永久物之异能会被对该颜色具有防护的效果阻止，即使该异能本身没有颜色
永久物失去所有异能（Tishana's Tidebinder、Humility、Darksteel Mutation）	先执行 rules-lookup --rule 613.1f，再执行 --rule 604.2：永久物失去异能的那一刻，它原有的每个静止式异能都会停止生效，因此，任何由该静止式异能维持的东西（保留的法术力、“不会消失”的条款、指示物规则）也会随之终止；如果涉及替代效应，则转交给 Skill(rules-lawyer, ...)

在工作笔记中记录每项说法及其 CR 引用——起草步骤会引用 CR 原文。

步骤 9：起草策略指南

将指南写入 <working-dir>/STRATEGY-GUIDE.md。结构由固定的核心主干，以及步骤 5 中触发的条件章节组成。

核心骨架（始终按此顺序呈现）

1. 标题 + 身份信息。

   • 牌组名称（指挥官、颜色标识、赛制）。
   • 用一句话概括套牌原型（例如：“以政治博弈驱动的贵族”“武斗士，辅以复活子主题”“锁控，搭配组合技终结手段”）。

2. 核心循环。 用 3-5 句话描述牌组如何获胜。内容源自步骤 4（指挥官互动审查）——写明增幅器、引擎组件和终结效果。

3. 获胜条件。 按可能性排序：

   • 主要计划（核心循环的终结事件）。
   • 次要计划（引擎消耗战／指挥官伤害／强化后的全力进攻）。
   • 第三计划（若有组合技，且符合级别限制）。 每个计划用 2-4 句话写明涉及的卡牌。

4. 调度指南。 说明怎样的起手牌值得保留。提及免费进行的首次调度规则（CR 800.6）一次。说明常见的调度目标，以及常见的不应追求的起手牌类型。

5. 逐回合节奏。 概述 T1-T8+。说明各回合阶段该部署什么，以及牌组何时从铺垫转向收割。根据级别调整：较快的级别需要缩短铺垫窗口。

6. 威胁评估。 列出需要警惕的卡牌／牌组（按顺序），以及轻松应对的卡牌／牌组。根据级别调整：Bracket 4 需要警惕具体卡牌（Drannith、Null Rod、Cursed Totem），而 Bracket 2 更需要警惕大规模去除。

7. 常见打法 + 堆叠技巧。 说明关键连招的堆叠顺序。讨论清场前的操作顺序问题（逐次牺牲，还是一次清场）。计算指挥官伤害。说明装备时机。本节的每条论述都须附上 CR 引用。

8. 牌组特性。 说明较边缘的法术力基础、单张 Game Changer、奇特的重印名称（例如，Paradise Chocobo = Birds of Paradise）、带有延迟自我牺牲条款的牌（Endrek Sahr）。指出初次使用时容易让玩家意外的情况。

9. 速查表。 按回合列出要点清单：“有衍生物死亡 → Joel 触发。有对手互斗 → Karazikar 抓牌。有衍生物进场 → Mirkwood Bats / Impact Tremors 触发。”精简名称，只保留玩家需要记住的触发条件。

10. 附录：已核实的卡牌互动说明。 列出与规则相关的论述及对应的 CR 引用。这是审查记录——Rules Audit 子代理（步骤 10）会对照此列表进行核实。

条件章节（在触发时于 Step 5 中呈现）

每个条件章节都会在顶部注明触发条件，以便信号再次触发时，后续重跑能够复现相同的结构。

• 政治脚本（由 goad + opponents-create-tokens 触发）： 用于引导对手注意力、决定先诅咒谁以及何时部署 goad 效果的脚本台词。
• 贵族流排序（aristocrats-drain + sacrifice-outlet）： 提出清场前是否先反复牺牲的问题，并明确说明牺牲触发与死亡触发之间的不对称性。列出每种收益效果的触发次数。
• 组合技执行（存在能赢下比赛的组合技）：逐步说明组合技的堆叠排序、所需的场面状态、防护选项以及差一点完成的情况。
• Voltron 指挥官伤害计算（呈现 Voltron 特征的指挥官）：基础力量 → 装备叠加 → 每回合增长 → 致命所需回合数。说明辟邪／帷幕／保护相关工具。
• 衍生物加倍计算（有衍生物 + 衍生物加倍效果）：场上有 N 个加倍效果时，M 个衍生物产出源会产生 X 个衍生物。包括 Chatterfang/Parallel Lives 的叠加规则。
• 额外战斗／额外回合章节：说明使这些效果值得采用所需的法术力流和威胁密度。
• 复活线路（复活牌密度）：说明哪些坟场填充牌能配合哪些复活牌，并区分放逐区与坟场。
• 法术力增益收益（大法术力）：说明 X 咒语终结线路、Kessig Wolf Run 线路以及 Helix Pinnacle 线路。
• 进战场触发倍增（Panharmonicon 类效果）：说明套牌中哪些进战场触发最受益，以及它们在堆叠上的排序。
• 你将面对的对手（Step 7 中某副 Arena 套牌带有 arena-meta 字段）：列出该套牌所在队列中最常见的五至八种环境套牌构筑，并注明各自占比和胜率。对于每种构筑，指出其核心牌中的关键威胁（arena-meta --archetype "<name>" --json），并说明套牌中的哪些解牌能应对这些威胁，以及哪些牌应当留作后用。 与指南的其他部分一样，核实每项卡牌说明：使用 scryfall-lookup 查询 Oracle 文本，使用 rules-lookup 查询任何互动。注明数据所依据的时间段和段位。

写作风格

• 逐字引用 CR 规则，不要改述。引用规则编号 + 精简后的句子：“依据 CR 903.9a：‘如果一张指挥官牌位于坟场或放逐区，且该物件自上次检查状态动作以来被置入该区域，其拥有者可以将其置入指挥官区。’”
• 在行为至关重要时，引用卡牌的完整 Oracle 文本。仅对显而易见的情况（如 Sol Ring）进行意译。
• 根据读者的经验水平调整语气（见下表）。如果未说明，请在 Step 1 信息收集时询问用户，或默认采用中级水平。
• 不要使用表情符号。 不要使用营销套话。指南是一份参考文档。

Step 10：规则审计子 Agent + 修订

硬性关卡。 呈现指南之前，必须派遣一名通用 Agent，并向其下达以下确切指令：

你是 MTG 策略指南的规则审查 Agent。指南位于 <absolute-path-to-STRATEGY-GUIDE.md>。牌组已补全的 sidecar 文件 位于 <working-dir>/deck.hydrated.json。CR 位于 <working-dir>/comprehensive-rules-YYYYMMDD.txt。

你的任务：核查指南中的每一项与规则相关的主张（堆叠时机、 替代效应、指挥官区域行为、关键字互动、 中间「若」条件、层、触发式异能的排序、Oracle 文本 引文），依据如下内容进行验证：

1. 通过 scryfall-lookup "<name>" 查询卡牌的实际 Oracle 文本，或 阅读已补全的 sidecar 文件。
2. 通过 rules-lookup --rule <n> / --term <keyword> / --grep "<regex>" 查询相关 CR 规则。
3. 对于涉及多条规则的推理，使用 Skill 工具调用 rules-lawyer 技能 — rules-lawyer 技能自身的升级处理规则同样适用。

将 JSON 报告写入 /tmp/audit-claims.json，格式如下：

{
  "errors": [
    {"section": "...", "claim": "...", "cr_says": "...", "fix": "..."}
  ],
  "unsupported": [
    {"section": "...", "claim": "...", "needed_citation": "..."}
  ],
  "verified": [
    {"section": "...", "claim": "...", "cr_rule": "...", "match": "exact|paraphrased"}
  ]
}

内容务必具体。如果指南说「该触发式异能在咒语之上进入堆叠」， 请引用 CR 603.3。如果指南说「帷幕意指不能成为目标」， 请引用 CR 702.18a。错误是事实不正确的主张。缺少依据的主张是事实正确、 但需要补充引用的主张。已验证的主张是正确且有规则引用支持的主张。

计算也属于审查范围，必须重新推导，不能直接照搬。 对于指南中的任何组合技 循环费用、阈值（「五个精灵时产生净收益」）、伤害总量、回合数或卡牌数量： 你都要根据 Oracle 文本自行计算，并报告得出的数字。不能因为指南的推理 听起来合理，就确认其数字。若循环有每轮费用和每轮产出，请模拟几轮 — 看似第一轮收支平衡的循环，常会在第三轮时开始变化（自我强化的效应会累积）， 而看似无限的循环也可能受指南未追踪的资源限制。

指南统计的所有内容都要重新计数。 「有 X 的 N 张牌」、「有 N 张地横置进战场」、 「C 色来源有 N 个」——请根据牌表重新统计，即使结果相同也要报告你的数字。

不仅要核查外部事实，也要检查内部一致性。 指南常会在速查表、摘要和正文中重复 相同的主张。请标出各章节之间互相矛盾的地方，以及「需要：」标题与其下正文相矛盾 的地方。这些问题最容易在修复后残留下来，因为修正往往只应用在一处。

以下两类主张每次都必须查询规则，绝不能只通读了事， 因为它们最容易在多轮审查中漏过：

• 防护是否能阻止某项异能。 凡主张某颜色（或类别）的保护能否阻止鹏洛客忠诚异能、 起动式异能或触发式异能，都必须核实。依据 CR 702.16b 和 CR 113.7：若异能的 来源具有相应特质，保护会阻止以该来源为目标的异能。异能本身没有颜色； 关键只在于来源是什么。同时还要核查保护不能阻止的情况（非目标效应、 来自无色来源的伤害，以及 CR 702.16c-d 所述的灵气和武具）。
• 永久物失去所有异能。 当指南说某张牌会移除永久物的异能（如 Tidebinder、 Humility、Mutation）时，要依据 CR 613.1f 和 CR 604.2 追踪其后果：永久物原有的 每项静止式异能都会立即停止生效，因此任何由该静止式异能维持的状态 （保留的法术力、「不会清空」条款、留存的指示物）也会随之终止。指南若提到 异能被移除，却没提到因此清空了什么，这属于错误，不是遗漏。

上一轮修正改过的文本也属于新文本。 如果你收到的指南之前经过审查，那么修订过的 句子最可能再次出错：二轮审查中最常见的问题，是修正引用了误读的规则，或把错误主张 转移到了另一张牌上。修订句子中引用的规则，也必须像未引用规则的主张一样查询核实。

不要提出策略或牌组调整建议。审查范围仅限规则核验、算术和内部一致性。 子 Agent 运行期间，不要做其他事情——等待报告。

处理报告：

• 错误：直接编辑指南，逐一修正。编辑时引用 CR 原文。
• 缺少依据：编辑指南，补上缺失的 CR 引用。
• 已核实：无需处理。

应用修正时有两条规则——这两条规则都存在，是因为修正轮次经常会引入新的错误：

1. 将每项修正同步到所有相关位置。 开始处理下一项之前，先 Grep 指南，查找刚刚修改的卡牌、规则或数字。组合技部分修正的说法，通常也会出现在速查表、胜利条件摘要和“Requires:”标题中。只在一个地方修正、却不修改其他位置，会让指南自相矛盾，问题比原先的错误更严重。
2. 修正时，重新阅读你引用的每条规则。 不要凭审查报告的记忆添加引用。引用了错误的规则，或把正确规则用得过头，例如将 CR 302.6 的召唤失调规则套用到非生物神器上，都会引入新的错误。同样，如果修正时保留原说法、只换一张牌，也会产生关于另一张牌的新说法，需要单独查证：“Plate 不管用，Boots 才行”是关于另一张牌的说法，因此也需要查阅规则（CR 702.16b：关键在于来源的特征，因此防护某种颜色确实能阻止有该颜色的鹏洛客的忠诚异能）。

如果子 Agent 报告零个错误、零项缺少依据，就提交指南。否则，按相同要求再派发一轮审查，并重复此过程，直到审查结果干净为止。

各轮审查应快速收敛。如果第 2 轮仍报告错误，这说明问题出在此 SKILL.md，而不只是草稿——指出反复漏检的是哪类说法（算术？章节间的一致性？要求中未涵盖的牌张类别？），并在提交完成的指南时告知用户，以便进一步完善审查要求。不要默默地反复增加审查轮次。

第 11 步：提交并迭代

向用户展示指南的路径，并简要概述其中内容（哪些条件章节已生成、检测到哪些组合技，以及是否有任何括号标记警告）。

迭代由用户驱动，并在原文件中进行：

• 用户要求添加、删除或改写章节 → Edit 现有的 STRATEGY-GUIDE.md 文件。不要从头重新生成。
• 用户指出你漏掉了规则错误 → 对相关规则执行 rules-lookup，直接修正，并说明规则审查漏掉了这一点（这表明审查要求之后可能需要进一步完善）。
• 用户报告牌组已更改（牌张不同）→ 重新启动整个流程。下次对已编辑的牌组 JSON 调用工具时，hydrated sidecar 会自动重建；指南也会重新生成。

故障模式

症状	原因	恢复方法
deck-hydrate 报告有 missing 牌张	拼写错误、系列代码后缀、跨界联动更名	询问用户；对于跨界联动，建议使用规范名称（Paradise Chocobo → Birds of Paradise）
legality-audit 返回 FAIL	禁用牌张或颜色标识违规	告知用户；deck-strat 只读，无法修复。建议使用 /deck-wizard
mana-audit 返回 FAIL，但用户想继续	地数量或颜色平衡处于临界状态	继续编写指南；在套牌特点中标注法术力基础有待调整
combo-search 返回 404 或超时	Commander Spellbook API 问题	不写连招部分，继续后续内容；在套牌特点中记录警告；省略近似方案部分
edhrec-lookup 返回 404	EDHREC 上没有这位指挥官	按机制关键词改用 card-search；省略社区对比提示
rules-lookup --term <X> 无匹配结果	查询不当	尝试同义词；扩大范围，使用 --grep；如果仍无结果，则升级到 Skill(rules-lawyer, ...)
规则审计子 Agent 报告 >10 个错误	首稿的规则处理不严谨	修订；继续分轮派发，直到审计通过。如果第 2 轮仍报告错误，则视为 SKILL.md 缺陷，指出遗漏的主张类别，并告知用户
修复轮次引入新错误	只在某个部分应用了更正、凭记忆补充了引文，或将错误主张转移到了另一张牌上	继续之前，搜索更改后主张在所有位置的出现情况；修复时重新阅读引用的每条规则；下一轮将已修正的句子视为未引用的主张
审计通过了错误的保护或失去异能主张	根据异能自身的颜色推理，而非其来源的颜色（CR 702.16b、113.7），或指出异能失去，却未追踪失去的静止式异能原本维持了什么效果（CR 613.1f、604.2）	这两类情况在章程中都被列为必须每次查询；检查章程是否被删减
审计确认了实际错误的连招计算	章程允许 Agent 在不重新推导数值的情况下核对引文	章程要求独立重新推导，并对任何循环进行多轮模拟——检查该要求是否被删减
用户要求构筑 60 张牌的套牌	超出范围	拒绝，并引导用户使用 /deck-wizard

---

按经验水平调整

沿用 deck-wizard 中关于文风语气的表格。用户未说明时，默认按中级处理。

方面	初级	中级	高级
术语	定义术语（节奏、卡牌优势等）	自然使用	使用简写
牌张引用	在行文中引用完整的 Oracle 规则文本	仅在关键处引用	只写牌名；假设读者了解该牌
CR 引用	同时简要解释	规则编号 + 精简句子	仅规则编号 + 句子
政治话术示例	情境叙述	项目符号话术	简短的项目符号话术
连招执行	逐步说明并解释	步骤列表	仅列出堆叠顺序
调度	用完整句子说明规则	项目符号	精简标准

危险信号

出现以下想法就意味着该停下来了——你正在为自己找借口：

想法	事实
“我知道这张牌有什么作用。”	你不知道。去查一下。训练数据不是规则原文。
“我知道这条规则怎么说。”	你不知道。去查一下。训练数据不是 CR。
“这条规则显而易见，引用就免了。”	看起来显而易见的规则最容易让你栽跟头。规则审计会将其标记为缺乏依据。现在就引用。
“用户知道这种格式，起手换牌／速查表就免了。”	核心框架是必需的。如果某个部分确实不适用，就写一句说明——但该部分仍须保留。
“跳过规则审计子 Agent 吧，草稿没问题。”	审计是把关环节，能发现你没意识到的错误主张。每次都要运行。
“审计验证了我的连招计算，所以数字没错。”	“已验证”意味着审计重新推导了数字。如果报告只是复述你的推理，却没有给出自己的数字，那这项主张就还未经核查——再问一次。
“我修正了连招部分的错误，搞定了。”	搜索这项主张出现的所有其他位置。速查表和“需要：”标题最容易漏掉修正。
“这个循环收支平衡，所以不会有任何变化。”	下结论前至少模拟三轮。能自我增效的效果会叠加——第一轮看似收支平衡，到第三轮时可能就会出现偏差。
“这副 60 张牌的套牌只需要一份快速指南。”	不在范围内。转到 /deck-wizard。
“我把连招执行过程合并到获胜条件里。”	连招执行是独立的条件式章节，包含堆叠顺序。不要压缩它。
“EDHREC 说应该加入 X，所以指南应该建议替换牌。”	只读，不进行替换。指南可以说明为何有意不采用某张牌，但不能提议更改。
“我会不带 --format 重新运行 parse-deck。”	始终传入 --format。默认使用 commander 会悄无声息地破坏 Brawl 套牌。
“我会用补全的 sidecar 中的稀有度字段来评估预算。”	deck-strat 不负责预算。预算由 deck-wizard 中的 price-check 处理。
“套牌级别的问题很烦人，默认自动判断吧。”	默认值本来就是自动判断。仍要询问——答案会改变指南的重心。

---

决策表

任务	工具
解析列表 → deck.json	parse-deck <path> --format <fmt> --output <out>
设置指挥官	set-commander <deck.json> "Name" ["Name2"]
补全并验证套牌	deck-hydrate <deck.json> --bulk-data <path>
查询单张牌	scryfall-lookup "<Name>" --bulk-data <path>
牌表（非地牌）	card-summary <deck.json> --nonlands-only
牌表（地牌）	card-summary <deck.json> --lands-only
赛制合法性与颜色特征	legality-audit <deck.json>
曲线、加速、Game Changers	deck-stats <deck.json>
法术力基础审计	mana-audit <deck.json>
主题密度／原型检测	archetype-audit <deck.json> <deck.hydrated.json> --include-commanders --preset ...
牌组内连招与近似组合	combo-search <deck.json> --output <wd>/combo-search.json
按结果探索连招	combo-discover --result "<outcome>" --color-identity <ci>
EDHREC 热门牌	edhrec-lookup "<Name>" ["<Partner>"]
按编号查询 CR 规则	rules-lookup --rule <n> --rules-file <wd>/comprehensive-rules-*.txt
查询 CR 关键词／术语表词条	rules-lookup --term <keyword> --rules-file <wd>/comprehensive-rules-*.txt
使用 CR 正则搜索	rules-lookup --grep "<pattern>" --rules-file <wd>/comprehensive-rules-*.txt --limit 5
查询单张牌的 Scryfall 裁定	rulings-lookup --card "<Name>" --bulk-data <path>
多规则时机／层／堆叠问题	Skill(rules-lawyer, ...)
策略文章备用方案	web-fetch "<url>" --max-length 10000
撰写／编辑指南	Write（初稿），Edit（迭代）
运行规则审计	Agent(subagent_type=general-purpose, ...)，使用第 10 步中的任务章程