evilvideogamenerd — el externo que rompe tu juego

¿Qué hace evilvideogamenerd — el externo que rompe tu juego?

Configuración del revisor (en vivo)

!node ${CLAUDE_SKILL_DIR}/../../scripts/gate.mjs evilvideogamenerd || echo GATE_UNAVAILABLE

• NO_CONFIG → detenerse y ejecutar primero el skill devinit.
• CONFIG_ERROR → reparar y validar la política antes de continuar; no sustituir con valores por defecto.
• Copiar una plantilla al proyecto con node ${CLAUDE_SKILL_DIR}/../../scripts/install-template.mjs <skill>/templates/<file> <destination> (nunca sobrescribe). Las plantillas con {{placeholders}} se leen, completan y escriben en su lugar.

Modos ($ARGUMENTS)

Argumento	Qué hacer
player / qa / critic [focus]	Una ronda de revisión (procedimiento abajo). Modo por defecto: nerd.default_mode
recheck	Una ronda cuyo único trabajo es re-verificar las filas del ledger con estado fix-submitted, still-open o regressed
status	Resumir qa/nerd/ledger.md por severidad y estado; no lanzar el revisor
setup	Solo pasos 1–2: la carpeta del revisor y las herramientas

Tu rol (agente principal)

Tú preparas, lanzas y trias. El revisor trabaja solo.

• Nunca pongas intención de diseño, contenido del GDD, números, elementos de la hoja de ruta o reglas del proyecto en su prompt. Redacta el briefing como una nota dirigida al jugador: cómo lanzar, controles, qué cambió al estilo de notas de parche.
• Nunca cierres sus hallazgos. Puedes establecer fix-submitted (con un commit o nota). Solo el revisor en una re-verificación, o un humano, establece verified-fixed; solo un humano establece wontfix.
• Estar en desacuerdo con un hallazgo ("eso es intencionado") es decisión del usuario. Regístralo con la decisión del usuario.

Procedimiento de ronda

1. Carpeta del revisor (paths.nerd, por defecto qa/nerd/). Crearla si falta:

   • ledger.md: install-template.mjs evilvideogamenerd/templates/ledger.md qa/nerd/ledger.md;
   • report-template.md: install-template.mjs evilvideogamenerd/templates/report.md qa/nerd/report-template.md;
   • reports/, screens/, logs/, scripts/ (creados por el revisor según sea necesario).

   El revisor no puede leer la carpeta del plugin, por lo que sus plantillas deben vivir aquí.

2. Herramientas. Determinar qué puede usar realmente el revisor y decirlo claramente:

   • MCP play: un MCP de Godot con herramientas de captura de pantalla e input está disponible (se recomienda GoPeak; configuración en el skill stopgen, setup-mcp). Necesario para player y critic.
   • Chaos runner: <project_dir>/tools/qa/chaos_runner.gd existe. Si no existe, ofrecer instalarlo (con aprobación del usuario): install-template.mjs evilvideogamenerd/templates/chaos_runner.gd <project_dir>/tools/qa/chaos_runner.gd. Necesita el binario de Godot, no una pantalla.
   • Ninguna: informar al usuario de que la ronda solo puede ser parcial (revisión de código qa) y preguntar si desea continuar.

3. Archivo de sesión. Escribir qa/nerd/.session.json: {"mode": "...", "round": N, "focus": "...", "capabilities": ["mcp-play", "chaos"], "version": "<process.current_version>", "started": "<ISO date>"}. El número de ronda es el anterior más uno (ver reports/). El hook de aislamiento lee el modo de este archivo.

4. Briefing desde templates/briefing.md: solo información orientada al jugador.

5. Lanzar el subagente evil-video-game-nerd (su tipo listado puede llevar el prefijo godot-gamedev:). Pasarle el briefing, la ruta del informe a escribir y "las plantillas están en qa/nerd/". Hasta nerd.max_rounds rondas por sesión.

6. Triar el informe con el usuario:

   • Bloqueante/Crítico → elementos Must de la hoja de ruta para la versión actual (antislop-game).
   • Otros → hoja de ruta o backlog según severidad × frecuencia.
   • Hallazgos rechazados → ledger wontfix con la razón del usuario.
   • Hallazgos sospechosos y corazonadas → nada hasta ser reproducidos.

7. Corregir, luego re-verificar. Después de correcciones, establecer fix-submitted en el ledger y ejecutar recheck. Repetir hasta nerd.max_rounds.

8. Eliminar qa/nerd/.session.json cuando termine la sesión.

Qué significa el aislamiento aquí (sé honesto al respecto)

• El hook nerd-guard del plugin se aplica solo a este subagente. Bloquea la lectura del GDD, hoja de ruta, decisiones, playtests, AGENTS.md, CLAUDE.md y .gamedev/. En modo player/critic solo permite docs/player/, qa/nerd/ y su memoria, y solo herramientas de juego. Permite escrituras solo en qa/nerd/ y su memoria, y nunca herramientas MCP que editen el juego o llamen a métodos en tiempo de ejecución.
• omitClaudeMd necesita Claude Code 2.1.271 o superior. Omite las instrucciones iniciales de usuario/proyecto/local; la política gestionada aún se carga, y las instrucciones de subdirectorios pueden cargarse cuando se accede a archivos. Esto no garantiza un contexto libre de instrucciones. El revisor mantiene la memoria del proyecto en .claude/agent-memory/…evil-video-game-nerd…/, o qa/nerd/memory.md cuando la memoria del agente no está disponible.
• El filtrado de Bash es un esfuerzo de mejor esfuerzo, no un sandbox. Informa al usuario si necesita un aislamiento garantizado; la alternativa es un checkout separado sin docs/.
• docs/player/ debe mantenerse libre de intención de diseño (regla gdddocs); de lo contrario, el aislamiento se filtra por la puerta principal.

Compuertas

La compuerta de release-candidate (antislop-game gate) falla mientras el ledger tenga filas Bloqueante o Crítico que no sean verified-fixed o wontfix.