Carlomos7/commander-vault

指挥官卡组宝库（主导）

请求: $ARGUMENTS

立即加载：mtg-research 和 commander-deckbuilding（知识库），然后阅读 references/theme-rules.md。 作为插件安装时，通过 /mtg:commander-vault 调用。简报路径：MTGDB=${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py（与 mtgdb MCP 工具相同的命令；子代理可使用任一方式）。页面脚本：PAGES=${CLAUDE_SKILL_DIR}/scripts（参见 references/pages.md）。每个脚本都使用 uv run 运行。在包含主题的宝库运行中，传递 --themes vault/themed-printings.json（以及 --reasons vault/<slug>/off-theme.json）。

当前状态

test -f vault/plan.md && { echo "正在恢复。plan.md："; cat vault/plan.md; } || echo "全新运行，此处无 vault/。"
test -f deck-brief.md && { echo "正在进行的卡组。deck-brief.md："; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "此处无正在进行的卡组。"

恢复中：从第一个未勾选的关卡继续。除非被要求，否则不要重新通过已通过的关卡。

从您正在构筑的卡组开始。 如果请求为空，或包含“此卡组”（或命名了一个卡组文件），且这里（或本对话的较早部分）有一个正在进行的卡组（来自卡组构筑技能的 deck-brief.md 及其 <commander-slug>.txt），则围绕它构建宝库，而非要求粘贴：

• 简报预填充请求：指挥官、分组、硬约束、预算偏好、收藏偏好、必须/绝不包含、主题。
• 现有列表成为该指挥官在其分组中的卡组：将其复制到 vault/<slug>/b<N>.txt，对其运行 G2 检查，并且除非检查失败，否则不要重新构建。
• 询问一个问题 (AskUserQuestion)：“宝库应添加什么？”选项包括“此指挥官的相邻分组（推荐）”、“其他指挥官（请列出名称）”、“仅为此卡组生成页面”（最后一项：按 references/pages.md 渲染并停止；无需代理）。

准确性模型（为什么存在关卡）

1. 计算事实（合法性、印刷、价格、游戏改变者、计数）：仅来自 mtgdb.py。代理不得以其他方式陈述。
2. 有来源的主张（计划、必玩牌、连击、cEDH）：记录在 claims.jsonl 中，由脚本审计。
3. 独立验证：vault-verifier（未参与编写工作）重新打开来源并重新运行检查。
4. 主导裁决：您解决每个被反驳或无法验证的高影响主张。
5. 披露：页面显示数据日期、已运行的检查以及保持未验证的内容。

输入

请求在命令之后粘贴，或作为文件传递，通常遵循仓库的 vault-request.md 模板（行如 Brackets: 2 and 3；括号内的文本为提示，而非答案）（章节：关于什么、牌桌与预算、您的卡牌、页面显示什么）。解析：指挥官、分组 + 默认、预算、价格风格、硬约束、收藏与拥有卡牌偏好、必须/绝不包含、标签分组、页面附加内容、标签风格（默认中性判定：可玩、良好、视情况、备牌、分组4+；绝不使用“弱”），以及主题（默认无；如需，themes.md 输入问题：模式、系列、限制、特级）。 页面模板尚不能渲染的额外内容（替代指挥官、收藏计划、在玩家之间分配一堆卡牌）作为 Markdown 文件输出到 vault/（alternatives.md、collection-plan.md）：每个放置都通过 mtgdb.py validate 对该卡组的颜色身份验证，且不适合任何指挥官的卡牌会连同其颜色列出。在 plan.md 中注明模板缺口。仅在必要时提问 (AskUserQuestion，多项选择)；其余默认。如果用户提问，则回答该问题，不构建宝库。超过 6 个指挥官或 18 套卡组：给出规模并确认。 编写 vault/plan.md：输入、别名、分组矩阵、默认、成本估算以及从 G0 到 G5 的检查清单。

G0 设置（您）

• mtgdb.py status --remote，然后对任何过时内容（卡牌、标签、裁决、连击、规则；大约一分钟）运行 mtgdb.py sync，然后运行 mtgdb.py selftest。失败会停止运行，直到作出解释。
• 阅读最新的威世智分组/游戏改变者/禁牌公告。如果比 commander-deckbuilding/references/brackets.md 更新，则在 plan.md 中注明更改，并将其包含在每个简报中。
• 通过调用而非读取名称来检查附加功能，遵循 mtg-research 技能（references/sources.md，“可选的 MCP 服务器”）中的附加功能规则：每项能力（EDHREC 数据、卡组链接、分组估算、日志、网页搜索）进行一次廉价调用。将已应答的能力写入 plan.md；对于每个缺失的能力，说明哪些检查不会运行。
• 主题（在模式为“无”时跳过）：编写 vault/theme-spec.json 并使用 theme-build（theme-rules.md）构建 vault/themed-printings.json。对于严格模式，按指挥官运行 theme-pool。然后双向检查映射：
  • 误报：每个映射的秘密巢穴印刷的 contact-sheet；您亲自查看并移除任何偏离主题的内容。
  • 缺口：在名称、艺术（art:）和风味（ft:）中运行 search 以查找该主题的所有系列，并与映射进行差异比对。
  • 在一行中向用户显示最终的移除/系列列表。
• 设置时效截止日期 SINCE = 最新禁牌/游戏改变者更新的日期。
• 编写 vault/config.json：{"since": SINCE, "budget": <number or null>, "commanders": {"<slug>": 1 or 2}}。插件的钩子会读取它：每当有人写入 vault/<slug>/b<N>.txt 或 claims*.jsonl 时，钩子会验证它，并将失败直接反馈给写入者。钩子不代替您的关卡；它们会提前阻止错误文件。
• 数据附加功能：mtgdb.py sync prices（每次运行一次）用于价格阶梯上的供应商价格；如果用户有收藏，运行 collection show 并询问是否应优先考虑拥有的卡牌。

G1 研究（vault-researcher，并行，每个 2 到 3 个指挥官）

简报：references/briefs.md §1。 关卡：对于每个指挥官，mtgdb.py audit-claims vault/<slug>/claims.jsonl --since SINCE 通过；research.md 包含所有章节。

G2 试运行，然后卡组（vault-deckbuilder）

首先为一个指挥官构建默认分组（§2）。对其运行 G2 检查。如果代理误读了任何内容，则修复简报。然后展开。 关卡，每套卡组，由您运行（绝不信任代理的报告）：

• mtgdb.py --themes vault/themed-printings.json validate <deck> --bracket N [--budget X]
• mtgdb.py combos <deck>（本地 Spellbook 数据；B1 到 B3：没有双牌连击）以及，如果附加功能提供，则进行分组估算
• themed_printing_available 警告已修复或有正当理由
• 每个 consider.json 配对通过 swaptest

G3 合并（vault-merger，每个标签一个）

§3。关卡：merged.json 中的每张卡牌至少出现在该标签的一个 consider.json 文件中；计数匹配；每个配对通过 swaptest（您亲自重新运行 25% 的样本，对于 B3 及以下则全部重新运行）。

G4 验证（vault-verifier，全新上下文，每 3 到 4 个指挥官一个）

§4。它验证 100% 的高影响主张和其余主张的 20% 样本，重新运行每套卡组检查，并通过查看艺术来检查有争议的印刷。 关卡：mtgdb.py audit-claims vault/<slug>/claims.verified.jsonl --since SINCE --require-verified 通过，并且 verification.md 中的每个“被反驳”/“无法验证”项均由您解决：修复、移除，或保留并附带可见的“未验证”标签。

G5 页面（您，遵循 references/pages.md）

1. site_data.py init vault/site-data.json（如果带主题则加上 --themes），然后对每套卡组执行 add-deck（将代理的 deck-notes.md 压缩为每套卡组的 notes.json），对每个层级标签执行 add-tier（带 n 的 EDHREC 数字），对每个标签执行 add-swaps，并使用每个 claims.verified.jsonl 执行 add-claims。
2. build_site.py vault/site-data.json --out vault/site。修复所有错误。
3. 遵循 pages.md 的步骤 4 和 5：在桌面端和 390px 宽度下查看，随机抽查 10 张卡牌与 mtgdb.py 对比，发布。
4. 用几行回复：包含内容、主题计数（主题宝库）、准确性摘要（已验证/标记为未验证的主张、数据日期）、已接受的例外。

不要手动构建或重新设计页面。如果模板缺少每个宝库都需要的内容，请在 plan.md 中将其记录为稍后进行的模板更改。

当运行中途发生变化时

• 用户重定向（新的分组焦点、主题规则、预算）：首先更新 plan.md 和 config.json，然后向每个正在运行的代理发送消息 (SendMessage) 告知确切更改，然后重新关卡任何已在旧规则下构建的内容。
• 代理死亡（会话重启、崩溃）：检查哪些文件存在，仅重启缺失的工作，如果工作较小则自行完成。绝不等待一个未运行的代理。
• 某个工具宕机：说明哪项检查未运行，并将受影响的项标记为未验证。绝不手动填补缺口。

规模与成本（在输入时决定，写入 plan.md）

粗略代理时间：每个指挥官研究约 10 到 20 分钟，每套卡组构建约 10 分钟，验证约需构建时间的一半。一个 12 个指挥官、40 套卡组的宝库运行了数小时。

• 默认范围：用户的分组加上一个更高分组。B5 仅在要求时，且仅针对有真实 cEDH 证据（EDHTop16 条目）的指挥官。对于其他指挥官，说“不是真正的 cEDH 指挥官”，而不是构建一套没人会玩的 B5 列表。
• 默认规模：最多 6 个指挥官。超过该数量，先确认估算，或拆分为多个宝库。
• 验证范围：100% 的高影响主张，但每个指挥官上限 40 条。如果超过，验证页面上出现的 40 条（必玩牌、连击、cEDH），并将其余标记为未验证。
• 可选的重数据：prices-sync --history（大量下载）仅在页面显示价格趋势时使用。
• 跳过可跳过的内容：B5 不需要社区通过（比赛数据决定），对于少于约 200 个 EDHREC 卡组的指挥官不需要 YouTube 研究（内容很少；仅使用数据和 Spellbook）。
• 绝不削减：验证、Spellbook 连击检查、钩子、主题映射检查、G5 渲染检查。

成本与上下文

• 代理写入文件并返回简短报告。仅在关卡处阅读它们的文件。
• 没有实时的每张卡牌 Scryfall 调用；索引已覆盖。
• 将您所做的每个修复记录在 plan.md 中，以便恢复的运行知道。