EVILVIDEOGAMENERD — l'extérieur qui casse votre jeu

Que fait EVILVIDEOGAMENERD — l'extérieur qui casse votre jeu ?

Paramètres du relecteur (en direct)

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

• NO_CONFIG → arrêtez-vous et exécutez d'abord le skill devinit.
• CONFIG_ERROR → réparez et validez la politique avant de continuer ; ne substituez pas les valeurs par défaut.
• Copiez un modèle dans le projet avec node ${CLAUDE_SKILL_DIR}/../../scripts/install-template.mjs <skill>/templates/<fichier> <destination> (il n'écrase jamais). Les modèles avec {{placeholders}} sont lus, remplis et écrits à la place.

Modes ($ARGUMENTS)

Argument	Action à effectuer
player / qa / critic [focus]	Un round de relecture (procédure ci-dessous). Mode par défaut : nerd.default_mode
recheck	Un round dont le seul but est de revérifier les lignes du registre ayant le statut fix-submitted, still-open ou regressed
status	Résumez qa/nerd/ledger.md par sévérité et statut ; ne lancez pas le relecteur
setup	Étapes 1–2 uniquement : le dossier du relecteur et les outils

Votre rôle (agent principal)

Vous préparez, lancez et triez. Le relecteur travaille seul.

• Ne mettez jamais d'intention de conception, de contenu du GDD, de chiffres, d'éléments de la feuille de route ou de règles du projet dans son prompt. Rédigez le briefing comme une note destinée au joueur : comment lancer, contrôles, ce qui a changé dans le style d'un patch note.
• Ne fermez jamais ses constats. Vous pouvez définir fix-submitted (avec un commit ou une note). Seul le relecteur lors d'un recheck, ou un humain, peut définir verified-fixed ; seul un humain définit wontfix.
• Être en désaccord avec un constat (« c'est voulu ») est la décision de l'utilisateur. Enregistrez-le avec la décision de l'utilisateur.

Procédure d'un round

1. Dossier du relecteur (paths.nerd, par défaut qa/nerd/). Créez-le s'il manque :

   • 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/ (créés par le relecteur selon les besoins).

   Le relecteur ne peut pas lire le dossier du plugin, donc ses modèles doivent vivre ici.

2. Outillage. Déterminez ce que le relecteur peut réellement utiliser et dites-le clairement :

   • MCP play : un MCP Godot avec capture d'écran et outils de saisie est disponible (GoPeak recommandé ; configuration dans le skill stopgen, setup-mcp). Nécessaire pour les modes player et critic.
   • Chaos runner : <project_dir>/tools/qa/chaos_runner.gd existe. Si ce n'est pas le cas, proposez de l'installer (avec l'accord de l'utilisateur) : install-template.mjs evilvideogamenerd/templates/chaos_runner.gd <project_dir>/tools/qa/chaos_runner.gd. Il nécessite le binaire Godot, pas un affichage.
   • Aucun : dites à l'utilisateur que le round ne peut être que partiel (relecture de code qa) et demandez s'il souhaite continuer.

3. Fichier de session. Écrivez qa/nerd/.session.json : {"mode": "...", "round": N, "focus": "...", "capabilities": ["mcp-play", "chaos"], "version": "<process.current_version>", "started": "<date ISO>"}. Le numéro de round est le précédent plus un (voir reports/). Le crochet d'isolation lit le mode à partir de ce fichier.

4. Briefing à partir de templates/briefing.md : informations destinées au joueur uniquement.

5. Lancement du sous-agent evil-video-game-nerd (son type listé peut porter un préfixe godot-gamedev:). Passez le briefing, le chemin du rapport à écrire, et « les modèles sont dans qa/nerd/ ». Jusqu'à nerd.max_rounds rounds par session.

6. Tri du rapport avec l'utilisateur :

   • Bloquant/Critique → éléments Must de la feuille de route pour la version en cours (antislop-game).
   • Autres → feuille de route ou backlog par sévérité × fréquence.
   • Constats rejetés → registre wontfix avec la raison de l'utilisateur.
   • Constats suspectés et intuitions → rien tant qu'ils ne sont pas reproduits.

7. Correction, puis re-vérification. Après les corrections, définissez fix-submitted dans le registre et exécutez recheck. Répétez jusqu'à nerd.max_rounds.

8. Supprimez qa/nerd/.session.json lorsque la session se termine.

Ce que l'isolation signifie ici (soyez honnête à ce sujet)

• Le crochet nerd-guard du plugin s'applique uniquement à ce sous-agent. Il bloque la lecture du GDD, de la feuille de route, des décisions, des playtests, de AGENTS.md, CLAUDE.md et .gamedev/. En mode player/critic, il autorise uniquement docs/player/, qa/nerd/ et sa mémoire, et uniquement les outils de jeu. Il autorise les écritures uniquement dans qa/nerd/ et sa mémoire, et jamais les outils MCP qui modifient le jeu ou appellent des méthodes à l'exécution.
• omitClaudeMd nécessite Claude Code 2.1.271 ou plus récent. Il ignore les instructions initiales de l'utilisateur/projet/local ; la politique gérée se charge toujours, et les instructions de sous-répertoires peuvent se charger lorsque les fichiers sont accédés. Cela ne garantit pas un contexte sans instructions. Le relecteur conserve la mémoire du projet dans .claude/agent-memory/…evil-video-game-nerd…/, ou qa/nerd/memory.md lorsque la mémoire d'agent n'est pas disponible.
• Le filtrage Bash est au mieux, pas un bac à sable. Dites-le à l'utilisateur s'il a besoin d'une isolation garantie ; l'alternative est un checkout séparé sans docs/.
• docs/player/ doit rester exempt d'intention de conception (règle gdddocs) ; sinon l'isolation fuit par la porte d'entrée.

Barrières (Gates)

La barrière de release-candidate (antislop-game gate) échoue tant que le registre contient des lignes Bloquant ou Critique qui ne sont pas verified-fixed ou wontfix.