Carlomos7/commander-vault

Bóveda de Mazos de Commander (líder)

Solicitud: $ARGUMENTS

Cargar ahora: mtg-research y commander-deckbuilding (el conocimiento), luego leer references/theme-rules.md. Invocado como /mtg:commander-vault cuando está instalado como plugin. Rutas para briefs: MTGDB=${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py (los mismos comandos que las herramientas MCP de mtgdb; los subagentes pueden usar cualquiera de los dos). Scripts de página: PAGES=${CLAUDE_SKILL_DIR}/scripts (ver references/pages.md). Ejecutar cada script con uv run. Pasar --themes vault/themed-printings.json (y --reasons vault/<slug>/off-theme.json) en ejecuciones de bóveda que tengan un tema.

Estado actual

test -f vault/plan.md && { echo "REANUDANDO. plan.md:"; cat vault/plan.md; } || echo "Ejecución nueva, no hay vault/ aquí."
test -f deck-brief.md && { echo "MAZO EN PROGRESO. deck-brief.md:"; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "No hay mazo en progreso aquí."

Reanudando: continuar desde la primera puerta no verificada. No rehacer una puerta ya superada a menos que se solicite.

Comenzando desde el mazo en el que estás trabajando. Si la solicitud está vacía o dice "este mazo" (o nombra un archivo de mazo), y hay un mazo en progreso (un deck-brief.md y su <commander-slug>.txt de la habilidad de construcción de mazos, en esta carpeta o antes en esta conversación), construir la bóveda alrededor de él en lugar de pedir un pegado:

• El brief prefija la solicitud: comandante, bracket, líneas duras, respuesta monetaria, preferencia de colección, debe/incluir nunca, tema.
• La lista existente se convierte en el mazo de ese comandante en su bracket: copiarlo a vault/<slug>/b<N>.txt, ejecutar las verificaciones G2 en él, y no reconstruirlo a menos que una verificación falle.
• Hacer una pregunta (AskUserQuestion): "¿Qué debería agregar la bóveda?" con "Brackets vecinos para este comandante (Recomendado)" · "También otros comandantes (nómbralos)" · "Solo una página para este mazo" (esta última: renderizarla según references/pages.md y detenerse; no se necesitan agentes).

Modelo de precisión (por qué existen las puertas)

1. Hechos computados (legalidad, impresiones, precios, Game Changers, conteos): solo de mtgdb.py. Los agentes no pueden afirmarlos de otra manera.
2. Afirmaciones con fuente (planes, must-plays, combos, cEDH): registradas en claims.jsonl, auditadas por script.
3. Verificación independiente: vault-verifier, que no escribió el trabajo, reabre fuentes y vuelve a ejecutar verificaciones.
4. Adjudicación del líder: tú resuelves cada afirmación refutada o no verificable de alto impacto.
5. Divulgación: la página muestra fechas de datos, verificaciones realizadas y lo que permaneció sin verificar.

Admisión

La solicitud se pega después del comando o se pasa como archivo, y generalmente sigue la plantilla vault-request.md del repositorio (líneas como Brackets: 2 y 3; el texto entre paréntesis es una pista, no una respuesta) (secciones: de qué se trata, tabla y billetera, tus cartas, qué va en la página). Resolver: comandantes, brackets + predeterminado, presupuesto, estilo de precio, líneas duras, preferencia de colección y cartas poseídas, debe/incluir nunca, agrupación de pestañas, extras de página, estilo de etiqueta (veredictos neutrales predeterminados: Jugar, Bueno, Situacional, Carpeta, Bracket 4+; nunca "débil"), y tema (predeterminado ninguno; si se desea, la pregunta de admisión de themes.md: modo, franquicia, límites, prima). Los extras que la plantilla de página no puede renderizar aún (comandantes alternativos, planificador de colección, dividir un montón entre jugadores) se envían como archivos Markdown en vault/ (alternatives.md, collection-plan.md): cada colocación pasa mtgdb.py validate identidad de color para ese mazo, y las cartas que no encajan con ningún comandante se listan con sus colores. Anotar la brecha de la plantilla en plan.md. Preguntar (AskUserQuestion, opción múltiple) solo por esos; el resto predeterminarlo. Si el usuario hace una pregunta, responderla y no construir. Más de 6 comandantes o 18 mazos: dar la escala y confirmar. Escribir vault/plan.md: entradas, slugs, matriz de brackets, predeterminados, la estimación de costo y la lista de verificación G0 a G5.

G0 Configuración (tú)

• mtgdb.py status --remote, luego mtgdb.py sync para cualquier cosa desactualizada (cartas, tags, reglas, combos, reglas; aproximadamente un minuto), luego mtgdb.py selftest. Un fallo detiene la ejecución hasta que se explique.
• Leer el último anuncio de bracket / Game Changers / baneo de Wizards. Si es más reciente que commander-deckbuilding/references/brackets.md, anotar los cambios en plan.md e incluirlos en cada brief.
• Verificar complementos llamándolos, no leyendo nombres, según las reglas de complementos en la habilidad mtg-research (references/sources.md, "Servidores MCP opcionales"): una llamada barata por capacidad (datos de EDHREC, enlaces de mazos, estimación de bracket, transcripciones, búsqueda web). Escribir qué capacidades respondieron en plan.md; para cada una faltante, decir qué verificaciones no se ejecutarán.
• Tema (saltar cuando el modo es ninguno): escribir vault/theme-spec.json y construir vault/themed-printings.json con theme-build (theme-rules.md). Para estricto, ejecutar theme-pool por comandante. Luego verificar el mapa en ambos sentidos:
  • Falsos positivos: contact-sheet de cada impresión de Secret Lair mapeada; mirarlo tú mismo y descartar cualquier cosa fuera de tema.
  • Brechas: ejecutar search para el tema en nombres, arte (art:) y sabor (ft:) en todos los conjuntos y comparar con el mapa.
  • Mostrar al usuario la lista final de descartes/conjuntos en una línea.
• Establecer el límite de antigüedad SINCE = fecha de la última actualización de baneos/Game Changers.
• Escribir vault/config.json: {"since": SINCE, "budget": <número o null>, "commanders": {"<slug>": 1 o 2}}. El hook del plugin lo lee: cada vez que alguien escribe vault/<slug>/b<N>.txt o un archivo claims*.jsonl, el hook lo valida y alimenta los fallos directamente al escritor. Los hooks no reemplazan tus puertas; detienen archivos incorrectos temprano.
• Extras de datos: mtgdb.py sync prices (una vez por ejecución) para precios de vendedor en la escalera de precios; si el usuario tiene una colección, collection show y preguntar si las cartas poseídas deben ser preferidas.

G1 Investigación (vault-researcher, paralelo, 2 a 3 comandantes cada uno)

Brief: references/briefs.md §1. Puerta: para cada comandante, mtgdb.py audit-claims vault/<slug>/claims.jsonl --since SINCE pasa; research.md tiene cada sección.

G2 Piloto, luego mazos (vault-deckbuilder)

Construir el bracket predeterminado para un comandante primero (§2). Ejecutar las verificaciones G2 en él. Corregir el brief si el agente malinterpretó algo. Luego expandir. Puerta, cada mazo, ejecutada por ti (nunca confiar en el informe del agente):

• mtgdb.py --themes vault/themed-printings.json validate <deck> --bracket N [--budget X]
• mtgdb.py combos <deck> (datos locales de Spellbook; B1 a B3: sin combos de 2 cartas) y, si un complemento ofrece uno, una estimación de bracket
• Advertencias de themed_printing_available corregidas o justificadas
• Cada emparejamiento de consider.json pasa swaptest

G3 Fusionar (vault-merger, uno por pestaña)

§3. Puerta: cada carta en merged.json aparece en al menos uno de los archivos consider.json de esa pestaña; los conteos coinciden; cada emparejamiento pasa swaptest (volver a ejecutar una muestra del 25% tú mismo, todos para B3 e inferiores).

G4 Verificar (vault-verifier, contexto fresco, uno por cada 3 a 4 comandantes)

§4. Verifica el 100% de las afirmaciones de alto impacto y una muestra del 20% del resto, vuelve a ejecutar cada verificación de mazo y verifica impresiones disputadas mirando el arte. Puerta: mtgdb.py audit-claims vault/<slug>/claims.verified.jsonl --since SINCE --require-verified pasa, y cada elemento refuted / unverifiable en verification.md es resuelto por ti: corregido, eliminado o mantenido con una etiqueta visible "no verificado".

G5 Página (tú, siguiendo references/pages.md)

1. site_data.py init vault/site-data.json (con --themes si tiene tema), luego para cada mazo add-deck (las deck-notes.md de los agentes condensadas en notes.json por mazo), add-tier por pestaña de nivel (números de EDHREC con n), add-swaps por pestaña, add-claims con cada claims.verified.jsonl.
2. build_site.py vault/site-data.json --out vault/site. Corregir cada error.
3. Seguir los pasos 4 y 5 de pages.md: mirarlo en escritorio y 390 px, verificar al azar 10 cartas contra mtgdb.py, publicar.
4. Responder en pocas líneas: qué contiene, conteos de tema (bóvedas temáticas), resumen de precisión (afirmaciones verificadas / etiquetadas no verificadas, fechas de datos), excepciones aceptadas.

No construir ni reestilizar la página manualmente. Si a la plantilla le falta algo que toda bóveda necesita, anotarlo en plan.md como un cambio de plantilla para después.

Cuando las cosas cambian durante la ejecución

• Redirecciones del usuario (nuevo enfoque de bracket, regla de tema, presupuesto): actualizar plan.md y config.json primero, luego SendMessage a cada agente en ejecución el cambio exacto, luego volver a pasar puerta cualquier cosa ya construida bajo la regla anterior.
• Agentes mueren (reinicio de sesión, bloqueo): verificar qué archivos existen, reiniciar solo el trabajo faltante, o hacerlo tú mismo si es pequeño. Nunca esperar a un agente que no está ejecutándose.
• Una herramienta está caída: decir qué verificación no se ejecutó y marcar los elementos afectados como no verificados. Nunca llenar la brecha manualmente.

Escala y costo (decidir en la admisión, escribir en plan.md)

Tiempo aproximado del agente: alrededor de 10 a 20 minutos por comandante para investigación, alrededor de 10 por mazo para construir, y la verificación aproximadamente la mitad del tiempo de construcción nuevamente. Una bóveda de 12 comandantes y 40 mazos se ejecutó durante varias horas.

• Alcance predeterminado: el bracket del usuario más uno por encima. B5 solo cuando se solicite, y solo para comandantes con evidencia real de cEDH (entradas de EDHTop16). Para otros, decir "no es un comandante cEDH real" en lugar de construir una lista B5 que nadie jugará.
• Tamaño predeterminado: hasta 6 comandantes. Por encima de eso, confirmar la estimación primero, o dividir en varias bóvedas.
• Alcance del verificador: 100% de las afirmaciones de alto impacto, pero con un límite de 40 por comandante. Si hay más, verificar las 40 que aparecen en la página (must-plays, combos, cEDH) y etiquetar el resto como no verificadas.
• Datos pesados opcionales: prices-sync --history (una descarga grande) solo si la página muestra tendencias de precios.
• Omitir lo que es barato de omitir: sin pase comunitario para B5 (los datos de torneos deciden), sin investigación de YouTube para comandantes con menos de aproximadamente 200 mazos en EDHREC (poco contenido existe; solo datos y Spellbook).
• Nunca cortar: validar, verificaciones de combos de Spellbook, el hook, las verificaciones del mapa de temas, la verificación de renderizado G5.

Costo y contexto

• Los agentes escriben archivos y devuelven informes cortos. Leer sus archivos solo en las puertas.
• Sin llamadas en vivo a Scryfall por carta; el índice lo cubre.
• Registrar cada corrección que hagas en plan.md para que una ejecución reanudada lo sepa.