Carlomos7/commander-vault

Commander Deck Vault (Lead)

Request: $ARGUMENTS

Jetzt laden: mtg-research und commander-deckbuilding (das Wissen), dann references/theme-rules.md lesen. Wird als /mtg:commander-vault aufgerufen, wenn es als Plugin installiert ist. Pfade für Briefings: MTGDB=${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py (die gleichen Befehle wie die mtgdb MCP-Tools; Subagenten dürfen beide verwenden). Seiten-Skripte: PAGES=${CLAUDE_SKILL_DIR}/scripts (siehe references/pages.md). Jedes Skript mit uv run ausführen. --themes vault/themed-printings.json (und --reasons vault/<slug>/off-theme.json) bei Vault-Läufen mit Theme übergeben.

Aktueller Stand

test -f vault/plan.md && { echo "FORTSETZUNG. plan.md:"; cat vault/plan.md; } || echo "Neuer Durchlauf, kein vault/ hier."
test -f deck-brief.md && { echo "DECK IN BEARBEITUNG. deck-brief.md:"; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "Kein Deck in Bearbeitung hier."

Fortsetzung: am ersten nicht bestandenen Gate weitermachen. Ein bestandenes Gate nicht wiederholen, außer bei Aufforderung.

Starten mit dem Deck, an dem du arbeitest. Wenn die Anfrage leer ist oder "dieses Deck" (oder eine Deck-Datei) nennt und ein Deck in Arbeit ist (eine deck-brief.md und ihre <commander-slug>.txt aus der Deckbau-Skill, in diesem Ordner oder früher in dieser Unterhaltung), baue den Vault darum herum, statt nach einer Eingabe zu fragen:

• Das Briefing füllt die Anfrage vor: Kommandeur, Bracket, harte Grenzen, Geld-Antwort, Sammlungspräferenz, muss/niemals enthalten, Thema.
• Die vorhandene Liste wird zum Deck dieses Kommandeurs in seinem Bracket: kopiere sie nach vault/<slug>/b<N>.txt, führe die G2-Prüfungen durch und baue sie nicht neu, es sei denn, eine Prüfung schlägt fehl.
• Stelle eine Frage (AskUserQuestion): "Was soll der Vault hinzufügen?" mit "Benachbarte Brackets für diesen Kommandeur (Empfohlen)" · "Auch andere Kommandeure (Namen nennen)" · "Nur eine Seite für dieses Deck" (letzteres: rendern gemäß references/pages.md und stoppen; keine Agenten nötig).

Genauigkeitsmodell (warum die Gates existieren)

1. Berechnete Fakten (Legalität, Drucke, Preise, Game Changer, Anzahl): nur von mtgdb.py. Agenten dürfen sie nicht anders angeben.
2. Belegte Behauptungen (Pläne, Must-Plays, Combos, cEDH): in claims.jsonl protokolliert, von einem Skript geprüft.
3. Unabhängige Verifikation: vault-verifier, der die Arbeit nicht geschrieben hat, öffnet Quellen erneut und führt Prüfungen erneut durch.
4. Lead-Entscheidung: Du löst jede widerlegte oder nicht verifizierbare hochrelevante Behauptung.
5. Offenlegung: Die Seite zeigt Datenstände, durchgeführte Prüfungen und was unverifiziert blieb.

Aufnahme

Die Anfrage wird nach dem Befehl eingefügt oder als Datei übergeben und folgt üblicherweise der vault-request.md-Vorlage des Repos (Zeilen wie Brackets: 2 und 3; Text in Klammern ist ein Hinweis, keine Antwort) (Abschnitte: worum es geht, Tabelle und Wallet, deine Karten, was auf die Seite soll). Auflösen: Kommandeure, Brackets + Standard, Budget, Preisstil, harte Grenzen, Sammlungs- und Kartenpräferenz, muss/niemals enthalten, Registerkarten-Gruppierung, Seitenextras, Label-Stil (Standard neutrale Bewertungen: Spielbar, Gut, Situativ, Binder, Bracket 4+; niemals "schwach") und Thema (Standard keines; falls gewünscht, die themes.md-Aufnahme-Frage: Modus, Franchise, Grenzen, Prämie). Extras, die die Seitenvorlage noch nicht rendern kann (alternative Kommandeure, Sammlungsplaner, Aufteilung eines Stapels zwischen Spielern) werden als Markdown-Dateien in vault/ ausgegeben (alternatives.md, collection-plan.md): jede Platzierung besteht mtgdb.py validate Farbidentität für dieses Deck, und Karten, die zu keinem Kommandeur passen, werden mit ihren Farben aufgelistet. Den Vorlagen-Gap in plan.md notieren. Nur dafür fragen (AskUserQuestion, Multiple Choice); den Rest standardmäßig belegen. Wenn der Benutzer eine Frage stellt, antworte und baue nicht. Bei über 6 Kommandeuren oder 18 Decks: den Umfang nennen und bestätigen lassen. vault/plan.md schreiben: Eingaben, Slugs, Bracket-Matrix, Standardwerte, die Kostenschätzung und die Checkliste G0 bis G5.

G0 Einrichtung (du)

• mtgdb.py status --remote, dann mtgdb.py sync für alles Veraltete (Karten, Tags, Entscheidungen, Combos, Regeln; etwa eine Minute), dann mtgdb.py selftest. Ein Fehler stoppt den Lauf bis zur Klärung.
• Die neueste Wizards-Bracket/Game Changers/Bekanntmachung lesen. Falls neuer als commander-deckbuilding/references/brackets.md, die Änderungen in plan.md notieren und in jedes Briefing aufnehmen.
• Add-ons prüfen, indem man sie aufruft, nicht indem man ihre Namen liest, gemäß den Add-on-Regeln der mtg-research-Skill (references/sources.md, "Optionale MCP-Server"): ein günstiger Aufruf pro Fähigkeit (EDHREC-Daten, Deck-Links, Bracket-Schätzung, Transkripte, Websuche). Welche Fähigkeiten geantwortet haben in plan.md schreiben; für jede fehlende angeben, welche Prüfungen nicht durchgeführt werden.
• Thema (überspringen, wenn Modus keine ist): vault/theme-spec.json schreiben und vault/themed-printings.json mit theme-build bauen (theme-rules.md). Bei "streng" theme-pool pro Kommandeur ausführen. Dann die Karte in beide Richtungen prüfen:
  • Falsch-Positive: contact-sheet von jedem abgebildeten Secret Lair-Druck; selbst ansehen und alles themenfremde entfernen.
  • Lücken: search nach dem Thema in Namen, Kunst (art:) und Geschmackstext (ft:) über alle Sets ausführen und mit der Karte abgleichen.
  • Dem Benutzer die endgültige Drop/Set-Liste in einer Zeile zeigen.
• Die Aktualitätsschwelle SINCE = Datum des letzten Bans/Game-Changer-Updates setzen.
• vault/config.json schreiben: {"since": SINCE, "budget": <number or null>, "commanders": {"<slug>": 1 or 2}}. Der Plugin-Hook liest es: jedes Mal, wenn jemand vault/<slug>/b<N>.txt oder eine claims*.jsonl schreibt, validiert der Hook es und leitet Fehler direkt an den Schreiber zurück. Hooks ersetzen nicht deine Gates; sie stoppen fehlerhafte Dateien frühzeitig.
• Daten-Extras: mtgdb.py sync prices (einmal pro Lauf) für Händlerpreise auf der Preisleiter; wenn der Benutzer eine Sammlung hat, collection show und fragen, ob besessene Karten bevorzugt werden sollen.

G1 Recherche (vault-researcher, parallel, 2 bis 3 Kommandeure pro Agent)

Briefing: references/briefs.md §1. Gate: für jeden Kommandeur mtgdb.py audit-claims vault/<slug>/claims.jsonl --since SINCE bestanden; research.md hat jeden Abschnitt.

G2 Pilot, dann Decks (vault-deckbuilder)

Das Standard-Bracket für einen Kommandeur zuerst bauen (§2). Die G2-Prüfungen durchführen. Das Briefing korrigieren, wenn der Agent etwas falsch gelesen hat. Dann ausrollen. Gate, jedes Deck, von dir durchgeführt (niemals dem Agentenbericht vertrauen):

• mtgdb.py --themes vault/themed-printings.json validate <deck> --bracket N [--budget X]
• mtgdb.py combos <deck> (lokale Spellbook-Daten; B1 bis B3: keine 2-Karten-Combos) und, falls ein Add-on eines anbietet, eine Bracket-Schätzung
• themed_printing_available-Warnungen behoben oder begründet
• jede consider.json-Paarung besteht swaptest

G3 Zusammenführen (vault-merger, einer pro Registerkarte)

§3. Gate: jede Karte in merged.json erscheint in mindestens einer consider.json dieser Registerkarte; Anzahl stimmt überein; jede Paarung besteht swaptest (25% Stichprobe selbst erneut durchführen, bei B3 und darunter alle).

G4 Verifizieren (vault-verifier, frischer Kontext, einer pro 3 bis 4 Kommandeure)

§4. Es verifiziert 100% der hochrelevanten Behauptungen und eine 20%-Stichprobe des Rests, führt jede Deck-Prüfung erneut durch und prüft strittige Drucke durch Ansehen der Kunst. Gate: mtgdb.py audit-claims vault/<slug>/claims.verified.jsonl --since SINCE --require-verified bestanden, und jedes refuted/unverifiable-Element in verification.md ist von dir gelöst: behoben, entfernt oder mit sichtbarem "unverifiziert"-Label belassen.

G5 Seite (du, nach references/pages.md)

1. site_data.py init vault/site-data.json (mit --themes falls thematisch), dann für jedes Deck add-deck (Agenten-deck-notes.md kondensiert in notes.json pro Deck), add-tier pro Tier-Registerkarte (EDHREC-Zahlen mit n), add-swaps pro Registerkarte, add-claims mit jeder claims.verified.jsonl.
2. build_site.py vault/site-data.json --out vault/site. Jeden Fehler beheben.
3. pages.md Schritte 4 und 5 folgen: auf Desktop und 390 px ansehen, 10 zufällige Karten gegen mtgdb.py stichprobenprüfen, veröffentlichen.
4. In wenigen Zeilen antworten: was enthalten ist, Themenanzahl (thematische Vaults), Genauigkeitsübersicht (Behauptungen verifiziert / als unverifiziert gekennzeichnet, Datenstände), akzeptierte Ausnahmen.

Die Seite nicht von Hand bauen oder umgestalten. Wenn der Vorlage etwas fehlt, das jeder Vault braucht, in plan.md als Vorlagenänderung für später notieren.

Wenn sich Dinge während des Laufs ändern

• Benutzer lenkt um (neuer Bracket-Fokus, Themenregel, Budget): zuerst plan.md und config.json aktualisieren, dann SendMessage an jeden laufenden Agenten mit der genauen Änderung, dann alles, das bereits unter der alten Regel gebaut wurde, erneut gaten.
• Agenten sterben (Sitzungsneustart, Absturz): prüfen, welche Dateien existieren, nur die fehlende Arbeit neu starten oder selbst erledigen, wenn es klein ist. Niemals auf einen Agenten warten, der nicht läuft.
• Ein Tool ist ausgefallen: angeben, welche Prüfung nicht durchgeführt wurde, und betroffene Elemente als unverifiziert markieren. Niemals die Lücke von Hand füllen.

Umfang und Kosten (bei der Aufnahme entscheiden, in plan.md schreiben)

Ungefähre Agentenzeit: etwa 10 bis 20 Minuten pro Kommandeur für Recherche, etwa 10 pro Deck zum Bauen, und Verifikation etwa die Hälfte der Bauzeit. Ein 12-Kommandeure-, 40-Deck-Vault lief mehrere Stunden.

• Standard-Umfang: das Bracket des Benutzers plus das nächsthöhere. B5 nur auf Anfrage und nur für Kommandeure mit echten cEDH-Beweisen (EDHTop16-Einträge). Bei anderen stattdessen sagen "kein echter cEDH-Kommandeur", statt einer B5-Liste, die niemand spielen wird.
• Standard-Größe: bis zu 6 Kommandeure. Darüber hinaus zuerst die Schätzung bestätigen lassen oder auf mehrere Vaults aufteilen.
• Verifikator-Umfang: 100% der hochrelevanten Behauptungen, aber gedeckelt auf 40 pro Kommandeur. Wenn es mehr gibt, die 40 verifizieren, die auf der Seite erscheinen (Must-Plays, Combos, cEDH) und den Rest als unverifiziert kennzeichnen.
• Optionale schwere Daten: prices-sync --history (ein großer Download) nur, wenn die Seite Preistrends zeigt.
• Überspringen, was billig zu überspringen ist: keine Community-Prüfung für B5 (Turnierdaten entscheiden), keine YouTube-Recherche für Kommandeure mit weniger als etwa 200 EDHREC-Decks (wenig Inhalt vorhanden; nur Daten und Spellbook).
• Nie kürzen: validieren, Spellbook-Combo-Prüfungen, der Hook, die Themenkarten-Prüfungen, die G5-Render-Prüfung.

Kosten und Kontext

• Agenten schreiben Dateien und geben kurze Berichte zurück. Ihre Dateien nur an den Gates lesen.
• Keine Live-Scryfall-Aufrufe pro Karte; der Index deckt es ab.
• Jede von dir vorgenommene Korrektur in plan.md protokollieren, damit ein fortgesetzter Lauf Bescheid weiß.