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 "RESUMING. plan.md:"; cat vault/plan.md; } || echo "Fresh run, no vault/ here."
test -f deck-brief.md && { echo "DECK IN PROGRESS. deck-brief.md:"; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "No deck in progress here."

繼續：從第一個未檢查的閘門繼續。除非被要求，否則不要重做已通過的閘門。

從你正在構築的牌組開始。 如果請求為空或提到「此牌組」（或指定一個牌組檔案），且目前有正在進行中的牌組（一個 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 構建 vault/themed-printings.json（theme-rules.md）。對於嚴格模式，為每位指揮官執行 theme-pool。然後雙向檢查映射：
  • 誤報：對每個映射到的 Secret Lair 印刷版本執行 contact-sheet；自行檢視並刪除任何不符主題的項目。
  • 缺口：在所有系列中，對名稱、藝術（art:）和 flavor（ft:）執行 search 尋找該主題，並與映射進行比對。
  • 以一行向使用者顯示最終的刪除/設定清單。
• 設定新近截止日期 SINCE = 最新禁牌/遊戲變革者更新的日期。
• 撰寫 vault/config.json：{"since": SINCE, "budget": <數字或null>, "commanders": {"<slug>": 1 或 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：無 2 張牌組合技），如果附加元件提供，則進行分級估計
• 已修正或證明 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：在桌面和 390 px 寬度下檢視，對照 mtgdb.py 抽查 10 張隨機牌，發布。
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 不需要社群審查（由賽事數據決定），對於 EDHREC 牌組少於約 200 副的指揮官，不需要 YouTube 研究（相關內容很少；僅使用數據和 Spellbook）。
• 絕不省略：validate、Spellbook 組合技檢查、鉤子、主題映射檢查、G5 渲染檢查。

成本與上下文

• 代理撰寫檔案並回傳簡短報告。僅在閘門處讀取其檔案。
• 不進行即時每張牌的 Scryfall 呼叫；索引已涵蓋。
• 將你進行的每個修正記錄在 plan.md 中，以便恢復的執行知道。