evilvideogamenerd – Der Außenseiter, der dein Spiel kaputt macht

Was macht evilvideogamenerd – Der Außenseiter, der dein Spiel kaputt macht?

Reviewer-Einstellungen (live)

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

• NO_CONFIG → Stoppe und führe zuerst das Devinit-Skill aus.
• CONFIG_ERROR → Repariere und validiere die Richtlinie vor dem Fortfahren; ersetze keine Standardwerte.
• Kopiere eine Vorlage in das Projekt mit node ${CLAUDE_SKILL_DIR}/../../scripts/install-template.mjs <skill>/templates/<file> <destination> (überschreibt niemals). Vorlagen mit {{placeholders}} werden gelesen, ausgefüllt und stattdessen geschrieben.

Modi ($ARGUMENTS)

Argument	Aufgabe
player / qa / critic [focus]	Ein Review-Durchgang (Verfahren siehe unten). Standardmodus: nerd.default_mode
recheck	Ein Durchgang, der nur prüft, ob Ledger-Zeilen mit Status fix-submitted, still-open oder regressed behoben wurden
status	Fasse qa/nerd/ledger.md nach Schweregrad und Status zusammen; starte den Reviewer nicht
setup	Nur Schritte 1–2: Erstelle den Reviewer-Ordner und die Werkzeuge

Deine Rolle (Haupt-Agent)

Du bereitest vor, startest und triagierst. Der Reviewer arbeitet allein.

• Gib niemals Designabsicht, GDD-Inhalte, Zahlen, Roadmap-Elemente oder Projektregeln in seinen Prompt. Schreibe das Briefing als spielerorientierte Notiz: wie man startet, Steuerung, was sich geändert hat – im Patch-Notizen-Stil.
• Schließe seine Funde niemals. Du darfst fix-submitted setzen (mit einem Commit oder einer Notiz). Nur der Reviewer beim Recheck oder ein Mensch setzt verified-fixed; nur ein Mensch setzt wontfix.
• Wenn der Nutzer mit einem Fund nicht einverstanden ist („das ist beabsichtigt”), entscheidet der Nutzer. Halte den Fund mit der Entscheidung des Nutzers fest.

Durchlauf-Verfahren

1. Reviewer-Ordner (paths.nerd, Standard qa/nerd/). Erstelle ihn, falls er fehlt:

   • 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/ (vom Reviewer nach Bedarf erstellt).

   Der Reviewer kann den Plugin-Ordner nicht lesen, daher müssen seine Vorlagen hier leben.

2. Werkzeuge. Stelle fest, was der Reviewer tatsächlich nutzen kann, und sage es klar:

   • MCP Play: Ein Godot MCP mit Bildschirmfoto- und Eingabe-Werkzeugen ist verfügbar (GoPeak empfohlen; Einrichtung im Stopgen-Skill, setup-mcp). Notwendig für player und critic.
   • Chaos Runner: <project_dir>/tools/qa/chaos_runner.gd existiert. Falls nicht, biete an, es zu installieren (mit Nutzer-Zustimmung): install-template.mjs evilvideogamenerd/templates/chaos_runner.gd <project_dir>/tools/qa/chaos_runner.gd. Benötigt das Godot-Binary, keinen Bildschirm.
   • Keines: Teile dem Nutzer mit, dass der Durchgang nur teilweise möglich ist (qa-Code-Review) und frage, ob er fortfahren möchte.

3. Sitzungsdatei. Schreibe qa/nerd/.session.json: {"mode": "...", "round": N, "focus": "...", "capabilities": ["mcp-play", "chaos"], "version": "<process.current_version>", "started": "<ISO-Datum>"}. Die Rundennummer ist die vorherige plus eins (siehe reports/). Der Isolations-Hook liest den Modus aus dieser Datei.

4. Briefing aus templates/briefing.md: Nur spielerorientierte Informationen.

5. Starte den evil-video-game-nerd-Unter-Agenten (sein gelisteter Typ kann ein godot-gamedev:-Prefix tragen). Übergib das Briefing, den Berichtspfad zum Schreiben und „Vorlagen sind in qa/nerd/”. Maximal nerd.max_rounds Durchgänge pro Sitzung.

6. Triage den Bericht mit dem Nutzer:

   • Blocker/Critical → Roadmap-Muss-Elemente für die aktuelle Version (antislop-game).
   • Andere → Roadmap oder Backlog nach Schweregrad × Häufigkeit.
   • Abgelehnte Funde → Ledger wontfix mit der Begründung des Nutzers.
   • Vermutete Funde und Ahnungen → nichts, bis sie reproduziert wurden.

7. Fix, dann Recheck. Nach Fixes setze fix-submitted im Ledger und führe recheck aus. Wiederhole bis zu nerd.max_rounds.

8. Lösche qa/nerd/.session.json, wenn die Sitzung endet.

Was Isolation hier bedeutet (sei ehrlich dazu)

• Der nerd-guard-Hook des Plugins gilt nur für diesen Unter-Agenten. Er blockiert das Lesen von GDD, Roadmap, Entscheidungen, Playtests, AGENTS.md, CLAUDE.md und .gamedev/. Im player/critic-Modus erlaubt er nur docs/player/, qa/nerd/ und dessen Gedächtnis sowie nur Spiel-Werkzeuge. Er erlaubt Schreibzugriffe nur auf qa/nerd/ und dessen Gedächtnis, niemals auf MCP-Werkzeuge, die das Spiel bearbeiten oder Methoden zur Laufzeit aufrufen.
• omitClaudeMd benötigt Claude Code 2.1.271 oder neuer. Es überspringt die initialen Benutzer-/Projekt-/Lokalanweisungen; die verwaltete Richtlinie wird trotzdem geladen, und Unterverzeichnis-Anweisungen können beim Zugriff auf Dateien geladen werden. Dies garantiert keinen anweisungsfreien Kontext. Der Reviewer speichert das Projektgedächtnis in .claude/agent-memory/…evil-video-game-nerd…/ oder in qa/nerd/memory.md, wenn Agentenspeicher nicht verfügbar ist.
• Die Bash-Filterung ist eine Bemühung nach bestem Wissen und Gewissen, keine Sandbox. Teile dies dem Nutzer mit, wenn eine garantierte Isolation erforderlich ist; die Alternative ist ein separater Checkout ohne docs/.
• docs/player/ muss frei von Designabsicht bleiben (gdddocs-Regel); sonst tritt die Isolation durch die Vordertür aus.

Gates

Das Release-Candidate-Gate (antislop-game gate) schlägt fehl, solange das Ledger Blocker- oder Critical-Einträge enthält, die nicht verified-fixed oder wontfix sind.