Carlomos7/commander-vault

Commander Deck Vault (lead)

Demande : $ARGUMENTS

Chargez maintenant : mtg-research et commander-deckbuilding (les connaissances), puis lisez references/theme-rules.md. Invoqué comme /mtg:commander-vault lorsqu'il est installé en tant que plugin. Chemins pour les briefs : MTGDB=${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py (les mêmes commandes que les outils MCP mtgdb ; les sous-agents peuvent utiliser les deux). Scripts de page : PAGES=${CLAUDE_SKILL_DIR}/scripts (voir references/pages.md). Exécutez chaque script avec uv run. Passez --themes vault/themed-printings.json (et --reasons vault/<slug>/off-theme.json) dans les exécutions de coffre qui ont un thème.

État actuel

test -f vault/plan.md && { echo "REPRISE. plan.md :"; cat vault/plan.md; } || echo "Nouvelle exécution, pas de vault/ ici."
test -f deck-brief.md && { echo "DECK EN COURS. deck-brief.md :"; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "Aucun deck en cours ici."

Reprise : continuer à partir de la première passerelle non cochée. Ne refaites pas une passerelle déjà réussie, sauf si on vous le demande.

En partant du deck sur lequel vous travaillez. Si la demande est vide ou dit "ce deck" (ou nomme un fichier de deck), et qu'il y a un deck en cours (un deck-brief.md et son <commander-slug>.txt provenant de la compétence de construction de deck, dans ce dossier ou plus tôt dans cette conversation), construisez le coffre autour de lui au lieu de demander un copier-coller :

• Le brief préremplit la demande : commandant, bracket, lignes dures, réponse monétaire, préférence de collection, doit/ne doit jamais inclure, thème.
• La liste existante devient le deck de ce commandant à son bracket : copiez-la dans vault/<slug>/b<N>.txt, exécutez les vérifications G2 dessus, et ne la reconstruisez pas sauf si une vérification échoue.
• Posez une question (AskUserQuestion) : "Que doit ajouter le coffre ?" avec "Brackets voisins pour ce commandant (Recommandé)" · "D'autres commandants aussi (nommez-les)" · "Juste une page pour ce deck" (ce dernier : rendez-le selon references/pages.md et arrêtez ; pas besoin d'agents).

Modèle de précision (pourquoi les passerelles existent)

1. Faits calculés (légalité, impressions, prix, Game Changers, comptages) : uniquement à partir de mtgdb.py. Les agents ne peuvent pas les énoncer autrement.
2. Affirmations sourcées (plans, must-plays, combos, cEDH) : enregistrées dans claims.jsonl, vérifiées par script.
3. Vérification indépendante : vault-verifier, qui n'a pas écrit le travail, rouvre les sources et réexécute les vérifications.
4. Arbitrage principal : vous résolvez toute affirmation réfutée ou invérifiable à fort impact.
5. Divulgation : la page montre les dates des données, les vérifications effectuées et ce qui est resté non vérifié.

Réception

La demande est collée après la commande ou passée comme fichier, et suit généralement le modèle vault-request.md du dépôt (lignes comme Brackets : 2 et 3 ; le texte entre parenthèses est un indice, pas une réponse) (sections : de quoi il s'agit, table et portefeuille, vos cartes, ce qui va sur la page). Résoudre : commandants, brackets + défaut, budget, style de prix, lignes dures, collection et préférence de cartes possédées, doit/ne doit jamais inclure, regroupement par onglets, extras de page, style d'étiquette (verdicts neutres par défaut : Play, Good, Situational, Binder, Bracket 4+ ; jamais "weak"), et thème (aucun par défaut ; si souhaité, la question de réception themes.md : mode, franchise, limites, prime). Les extras que le modèle de page ne peut pas encore rendre (commandants alternatifs, planificateur de collection, division d'une pile entre joueurs) sortent sous forme de fichiers Markdown dans vault/ (alternatives.md, collection-plan.md) : chaque placement passe mtgdb.py validate d'identité de couleur pour ce deck, et les cartes qui ne correspondent à aucun commandant sont listées avec leurs couleurs. Notez l'écart du modèle dans plan.md. Demandez (AskUserQuestion, choix multiple) uniquement pour ceux-ci ; par défaut pour le reste. Si l'utilisateur pose une question, répondez-y et ne construisez pas. Plus de 6 commandants ou 18 decks : donnez l'échelle et confirmez. Écrivez vault/plan.md : entrées, slugs, matrice de brackets, valeurs par défaut, estimation des coûts, et la liste de contrôle G0 à G5.

G0 Configuration (vous)

• mtgdb.py status --remote, puis mtgdb.py sync pour tout ce qui est obsolète (cartes, tags, rulings, combos, règles ; environ une minute), puis mtgdb.py selftest. Un échec arrête l'exécution jusqu'à explication.
• Lisez la dernière annonce de bracket / Game Changers / bannissement de Wizards. Si elle est plus récente que commander-deckbuilding/references/brackets.md, notez les changements dans plan.md et incluez-les dans chaque brief.
• Vérifiez les modules complémentaires en les appelant, pas en lisant les noms, selon les règles de module complémentaire de la compétence mtg-research (references/sources.md, "Serveurs MCP optionnels") : un appel bon marché par capacité (données EDHREC, liens de deck, estimation de bracket, transcriptions, recherche web). Écrivez quelles capacités ont répondu dans plan.md ; pour chaque capacité manquante, dites quelles vérifications ne seront pas exécutées.
• Thème (sauter quand le mode est aucun) : écrivez vault/theme-spec.json et construisez vault/themed-printings.json avec theme-build (theme-rules.md). Pour un thème strict, exécutez theme-pool par commandant. Ensuite, vérifiez la carte dans les deux sens :
  • Faux positifs : contact-sheet de chaque impression Secret Lair cartographiée ; regardez-la vous-même et supprimez tout ce qui est hors thème.
  • Lacunes : exécutez search pour le thème dans les noms, l'art (art:) et le flavortext (ft:) dans tous les ensembles et faites la différence avec la carte.
  • Montrez à l'utilisateur la liste finale des suppressions/ensembles en une ligne.
• Définissez le seuil de récence SINCE = date de la dernière mise à jour des bannissements/Game Changers.
• Écrivez vault/config.json : {"since": SINCE, "budget": <nombre ou null>, "commanders": {"<slug>": 1 ou 2}}. Le hook du plugin le lit : chaque fois que quelqu'un écrit vault/<slug>/b<N>.txt ou un claims*.jsonl, le hook le valide et renvoie les échecs directement à l'auteur. Les hooks ne remplacent pas vos passerelles ; ils arrêtent les mauvais fichiers tôt.
• Extras de données : mtgdb.py sync prices (une fois par exécution) pour les prix des revendeurs sur l'échelle de prix ; si l'utilisateur a une collection, collection show et demandez si les cartes possédées doivent être préférées.

G1 Recherche (vault-researcher, parallèle, 2 à 3 commandants chacun)

Brief : references/briefs.md §1. Passerelle : pour chaque commandant, mtgdb.py audit-claims vault/<slug>/claims.jsonl --since SINCE réussit ; research.md a toutes les sections.

G2 Pilote, puis decks (vault-deckbuilder)

Construisez d'abord le bracket par défaut pour un commandant (§2). Exécutez les vérifications G2 dessus. Corrigez le brief si l'agent a mal lu quelque chose. Puis étendez-vous. Passerelle, chaque deck, exécutée par vous (ne faites jamais confiance au rapport de l'agent) :

• mtgdb.py --themes vault/themed-printings.json validate <deck> --bracket N [--budget X]
• mtgdb.py combos <deck> (données locales Spellbook ; B1 à B3 : pas de combos à 2 cartes) et, si un module complémentaire en propose une, une estimation de bracket
• avertissements themed_printing_available corrigés ou justifiés
• chaque paire consider.json réussit swaptest

G3 Fusion (vault-merger, un par onglet)

§3. Passerelle : chaque carte dans merged.json apparaît dans au moins un des fichiers consider.json de cet onglet ; les comptages correspondent ; chaque paire réussit swaptest (réexécutez vous-même un échantillon de 25 %, toutes pour B3 et inférieur).

G4 Vérification (vault-verifier, nouveau contexte, un pour 3 à 4 commandants)

§4. Il vérifie 100 % des affirmations à fort impact et un échantillon de 20 % du reste, réexécute chaque vérification de deck, et vérifie les impressions contestées en regardant l'art. Passerelle : mtgdb.py audit-claims vault/<slug>/claims.verified.jsonl --since SINCE --require-verified réussit, et chaque élément refuted / unverifiable dans verification.md est résolu par vous : corrigé, supprimé, ou conservé avec une étiquette "non vérifié" visible.

G5 Page (vous, en suivant references/pages.md)

1. site_data.py init vault/site-data.json (avec --themes si thématisé), puis pour chaque deck add-deck (les deck-notes.md des agents condensés en notes.json par deck), add-tier par onglet de niveau (numéros EDHREC avec n), add-swaps par onglet, add-claims avec chaque claims.verified.jsonl.
2. build_site.py vault/site-data.json --out vault/site. Corrigez chaque erreur.
3. Suivez les étapes 4 et 5 de pages.md : regardez-la sur desktop et à 390 px, vérifiez 10 cartes aléatoires par rapport à mtgdb.py, publiez.
4. Répondez en quelques lignes : ce qu'elle contient, comptages de thème (coffres thématisés), résumé de précision (affirmations vérifiées / étiquetées non vérifiées, dates des données), exceptions acceptées.

Ne construisez pas ou ne restylez pas la page à la main. Si le modèle manque de quelque chose dont chaque coffre a besoin, notez-le dans plan.md comme un changement de modèle pour plus tard.

Quand les choses changent en cours d'exécution

• Redirections de l'utilisateur (nouveau focus de bracket, règle de thème, budget) : mettez d'abord à jour plan.md et config.json, puis envoyez un message (SendMessage) à chaque agent en cours d'exécution avec le changement exact, puis repassez les passerelles de tout ce qui a déjà été construit sous l'ancienne règle.
• Les agents meurent (redémarrage de session, crash) : vérifiez quels fichiers existent, redémarrez uniquement le travail manquant, ou faites-le vous-même si c'est petit. N'attendez jamais un agent qui ne tourne pas.
• Un outil est en panne : dites quelle vérification n'a pas été exécutée et marquez les éléments affectés comme non vérifiés. Ne comblez jamais le vide à la main.

Échelle et coût (décider à la réception, écrire dans plan.md)

Temps agent approximatif : environ 10 à 20 minutes par commandant pour la recherche, environ 10 par deck pour construire, et la vérification environ la moitié du temps de construction. Un coffre de 12 commandants et 40 decks a duré plusieurs heures.

• Portée par défaut : le bracket de l'utilisateur plus un au-dessus. B5 seulement sur demande, et uniquement pour les commandants avec de vraies preuves cEDH (entrées EDHTop16). Pour les autres, dites "pas un vrai commandant cEDH" au lieu de construire une liste B5 que personne ne jouera.
• Taille par défaut : jusqu'à 6 commandants. Au-delà, confirmez d'abord l'estimation, ou divisez en plusieurs coffres.
• Portée du vérificateur : 100 % des affirmations à fort impact, mais plafonné à 40 par commandant. S'il y en a plus, vérifiez les 40 qui apparaissent sur la page (must-plays, combos, cEDH) et étiquetez le reste comme non vérifié.
• Données lourdes optionnelles : prices-sync --history (un gros téléchargement) uniquement si la page montre des tendances de prix.
• Sautez ce qui est bon marché à sauter : pas de passage communautaire pour B5 (les données de tournoi décident), pas de recherche YouTube pour les commandants avec moins d'environ 200 decks EDHREC (peu de contenu existe ; données et Spellbook seulement).
• Ne jamais couper : validation, vérifications de combos Spellbook, le hook, les vérifications de carte de thème, la vérification de rendu G5.

Coût et contexte

• Les agents écrivent des fichiers et retournent des rapports courts. Lisez leurs fichiers uniquement aux passerelles.
• Pas d'appels Scryfall en direct par carte ; l'index les couvre.
• Enregistrez chaque correction que vous faites dans plan.md afin qu'une exécution reprise soit au courant.