Lies .codex/docs/codex-runtime.md, bevor du diesen Workflow verwendest. Folge den aktuellen Benutzerautorisierungs- und Hostberechtigungen.
Argumente: [path-to-design-doc] [--review full|lean|solo]
Führe vor dem Fortfahren diesen Konfigurationsbefehl vom Projektstammverzeichnis aus:
bash ".codex/hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,system_overrides
Verwende den obigen Befehl wie angegeben; --review überschreibt review_mode. --depth ist der Name des gleichen Flags vor Version 1.1: Behandle --depth <mode> genau wie --review <mode> und sage einmal, dass es umbenannt wurde. Wenn beide angegeben sind, gewinnt --review und --depth wird ignoriert – sage das. Kein Block → Standardwerte in .codex/docs/config-resolution.md.
Design Review
Phase 0: Argumente parsen
Siehe .codex/docs/director-gates.md für das vollständige Prüfmuster. Einzelne Gate-Definitionen befinden sich in .codex/docs/director-gates/[gate-id].md – der gestartete Agent liest seine eigene Gate-Datei; lies sie nicht in der übergeordneten Sitzung.
Jeder request_user_input-Aufruf folgt .codex/docs/automation-modes.md
(kollaborativ fragt immer · geführt nur bei wichtigen · autonom protokolliert und fährt fort;
automation_always_ask-Kategorien fragen immer).
workflow für das zu überprüfende GDD – verwende die system_overrides-Zeile für <system>, wenn der Block eine auflistet, sonst den Projektwert. Der Prüfumfang folgt der Stufe:
full– alle 8 Abschnitte validiert; jeder fehlende Abschnitt blockiert die Freigabe.standard– die 5 erforderlichen Abschnitte (Überblick, Detaillierte Regeln, Randfälle, Abhängigkeiten, Akzeptanzkriterien) blockieren bei Fehlen; Formeln blockieren nur, wenn das System numerische Regeln definiert (Raten, Kurven, Schwellenwerte, Kosten – die Kategorie ist ein Hinweis, nicht der Test); Spielerfantasie und Stellschrauben sind beratend (warnen, blockieren niemals), es sei denn,workflow_overridesverlangen sie.minimal– kein GDD wird erwartet; falls eines existiert, validiere die 5 Standard-Abschnitte beratend.
Der aufgelöste Modus steuert, wie gründlich diese Überprüfung ist:
full: Vollständige Überprüfung – alle Phasen + Delegation an spezialisierte Agenten (Phase 3b)lean: Alle Phasen, keine spezialisierten Agenten – schnellere Einzelsitzungsanalysesolo: Nur Phasen 1-4, keine Delegation, keine Phase-5-Aufforderung für nächste Schritte – verwende dies, wenn es von einem anderen Skill aufgerufen wird
Phase 1: Dokumente laden
Zuerst Frischeprüfung – eine erneute Überprüfung eines unveränderten Dokuments kostet den vollen Preis und liefert das gleiche Urteil. Führe aus:
Bash: bash .codex/scripts/review-receipts.sh check "design/gdd/reviews/[doc-name]-review-log.md" "[target-doc-path]" "design/registry/entities.yaml" ".agents/skills/design-review/SKILL.md"
Das Registry ist in der Prüfung enthalten, weil diese Überprüfung es für dokumentübergreifende Fakten konsultiert – ein unverändertes GDD, das gegen ein geändertes Registry überprüft wird, kann zu anderen Schlussfolgerungen kommen, daher ist der Übersprung nur sicher, wenn jede Zeile UNCHANGED liest (ein Registry, das nie existiert hat, erscheint nicht in der Ausgabe und blockiert den Übersprung nicht). Diese Skill-Datei ist enthalten, weil ein geändertes Skill anders überprüft. Die Prüfung vergleicht auch jede andere Datei, die das Protokoll markiert – die verwandten GDDs, Konzept- oder Kurzbeschreibungs- und Narrativdateien, die frühere Reviews gelesen haben – und gibt GONE: für eine aus, die nicht mehr existiert.
Lies dann die letzte Zeile Review mode: des Eintrags. Dieses Review deckt diesen Durchlauf nur ab, wenn sein Modus derselbe oder tiefer ist als der jetzt aufgelöste Modus (full > lean > solo) und sein Workflow derselbe oder tiefer ist (full > standard > minimal). Ein Eintrag ohne diese Zeile wurde geschrieben, bevor sie existierte, und deckt nichts ab.
- Alle
UNCHANGEDund der letzte Eintrag des Protokolls trägt ein Urteil – gib es aus: "Dieses Dokument ist byte-identisch mit seinem letzten Review am [Datum] ([Modus]-Review, Urteil: [Urteil])." Wenn dieses Urteil GENEHMIGT war und dieses Review diesen Durchlauf abdeckt, biete überrequest_user_inputan:[A] Vorheriges Urteil verwenden (Empfohlen)/[B] Trotzdem erneut prüfen–guidedfährt mit [A] fort und vermerkt es;autonomousprotokolliert überlog_decisionund verwendet das vorherige Urteil. Wenn es GENEHMIGT war, aber das jetzt angeforderte Review tiefer ist als das protokollierte, sage das – "Das war ein [Modus]-Review im Workflow [Stufe]; dieser Durchlauf fordert [Modus] auf [Stufe] an." – und biete[A] Erneut prüfen auf [Modus] (Empfohlen)/[B] Vorheriges [Modus]-Urteil verwendenan;guidedundautonomousprüfen erneut (autonomousprotokolliert es überlog_decision). Wenn es ÜBERARBEITUNG ERFORDERLICH oder GROSSE ÜBERARBEITUNG ERFORDERLICH war, sage das klar: das Dokument hat sich seit dem fehlgeschlagenen Review nicht geändert – die vorherigen Feststellungen bleiben bestehen; das Dokument zu überarbeiten ist der nächste Schritt, nicht eine erneute Überprüfung. Biete an, die vorherigen Feststellungen aus dem Protokoll anzuzeigen. - Das Zieldokument und diese Skill-Datei
UNCHANGED, und nur das Registry oder eine andere gestempelte dokumentübergreifende DateiCHANGED,NEWoderGONE– das vorherige Urteil bleibt bestehen, außer für dokumentübergreifende Fakten: überprüfe die Werte des Dokuments erneut gegen die geänderten Dateien und gib das Urteil erneut aus; eskalierte zu einer vollständigen erneuten Überprüfung, wenn ein Konflikt auftritt oder dieses Review diesen Durchlauf nicht abdeckt. - Zieldokument oder diese Skill-Datei
CHANGEDoderNEW, oderRECEIPT: NONE– fahre mit dem vollständigen Review unten fort. Biete kein Teil-/Deltareview an, das das Lesen oder erneute Analysieren unveränderter Abschnitte überspringt. Ein abschnittsbezogenes Review übersieht Fehler, die ein vollständiges Review findet, und spart wenig oder nichts. "Seit dem letzten Review unverändert" bedeutet nur byte-identisch mit dem, was damals überprüft wurde – es sagt nichts darüber aus, ob dieser vorherige Durchlauf selbst vollständig war, und die Aufmerksamkeit verengt sich auf die markierte Änderung, selbst unter einer Anweisung, alles trotzdem zu scannen.
Lies das gesamte Ziel-Design-Dokument. Dieser Schritt benötigt das gesamte GDD: lies es in Bereichen nach seinen Überschriften (gefunden mit dem Grep-Tool: Muster ^#, Inhalt-Modus), da ein ganzes Datei-Lesen über 40 KB abgelehnt wird. Lies AGENTS.md, um den Projektkontext und die Standards zu verstehen.
Für dokumentübergreifende Fakten bevorzuge das Registry gegenüber Schwester-GDDs. Wenn
design/registry/entities.yaml existiert und Einträge für dieses System auflistet,
durchsuche es mit Grep – dies sind die etablierten Fakten, denen dieses GDD nicht widersprechen darf, und sie ersetzen das Lesen von Schwester-GDDs, um sie neu zu entdecken:
Grep pattern="source: design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -A 6
Grep pattern="design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -B 8
Der erste findet Einträge, die diesem System gehören – der -A 6-Kontext enthält ihren
referenced_by:-Block. Der zweite findet Einträge, die dieses System referenzieren –
referenced_by: ist eine Block-Sequenz (der Schlüssel und seine Pfade sind in separaten
Zeilen), also stimme den Pfad mit -B 8-Kontext ab, um den besitzenden Eintrag zu sehen, nicht einen referenced_by.*name-Einzeiler (der niemals die Blockform erfüllt).
Wenn design/registry/entities.yaml nicht existiert, oder keinen Eintrag für dieses System auflistet – die Datei wird als leerer Stub geliefert, also ist dies der Standard, bis $design-system sie befüllt hat – falle zurück auf das Lesen der verwandten GDDs, die das Zieldokument in seinem Abschnitt "Abhängigkeiten" nennt. Beschränke das Lesen auf diese, nicht auf alles "Implizierte". Lies nicht alle design/gdd/ mit einem Glob.
Abhängigkeitsgraph-Validierung: Überprüfe für jedes im Abschnitt "Abhängigkeiten" aufgeführte System mit Glob, ob seine GDD-Datei in design/gdd/ existiert. Markiere alle, die noch nicht existieren – dies sind defekte Referenzen, auf die nachgelagerte Autoren stoßen werden.
Lore/Narrativ-Ausrichtung: Wenn design/gdd/game-concept.md (oder, bei rigor: minimal, die einseitige Kurzbeschreibung design/game-brief.md) oder eine Datei in design/narrative/ existiert, lies sie. Notiere alle mechanischen Entscheidungen in diesem GDD, die etablierten Weltregeln, Ton oder Design-Pfeilern widersprechen. Übergib diesen Kontext an game-designer in Phase 3b.
Prüfung auf vorherige Reviews: Überprüfe, ob design/gdd/reviews/[doc-name]-review-log.md existiert. Wenn ja, lies den neuesten Eintrag – notiere, welches Urteil gefällt wurde und welche blockierenden Punkte aufgelistet waren. Diese Sitzung ist eine erneute Überprüfung; verfolge, ob vorherige Punkte adressiert wurden.
Phase 2: Vollständigkeitsprüfung
Schritt 2a – Abschnittsvorhandensein deterministisch ermitteln (kein Dokumentlesen):
Bash: bash .codex/scripts/gdd-structure-check.sh [target-doc-path]
Es gibt eine PRESENT:-Liste und, wo zutreffend, eine ABSENT:-Liste und eine
PLACEHOLDER:-Liste aus (vorhandene Abschnitte, die nur [Noch zu entwerfen] enthalten: noch nicht geschrieben, also behandle sie als fehlend für die Checkliste). Es meldet
nur das Vorhandensein und fällt kein ERFORDERLICH/BERATEND-Urteil – das ist der Job von Schritt 2b. Es akzeptiert bereits ## Detailliertes Design als Erfüllung der Anforderung "Detaillierte Regeln", also markiere das nicht als fehlend.
Schritt 2b – die Stufe anwenden. Bewerte anhand der Schritt-2a-Listen gegen die Design-Dokument-Standard-Checkliste unten. Markiere jeden Abschnitt als ERFORDERLICH oder BERATEND gemäß der aufgelösten Workflow-Stufe (Phase 0). Ein fehlender ERFORDERLICHER Abschnitt blockiert die Freigabe; ein fehlender BERATENDER Abschnitt wird als Empfehlung genannt, blockiert aber nicht.
Ein als VORHANDEN gemeldeter Abschnitt kann die Überprüfung dennoch nicht bestehen, wenn es eine leere Überschrift ist – lies stichprobenartig jeden Abschnitt, von dem das Urteil tatsächlich abhängt.
- Hat Abschnitt "Überblick" (ein Absatz Zusammenfassung) – ERFORDERLICH auf allen Stufen
- Hat Abschnitt "Spielerfantasie" (beabsichtigtes Gefühl) – ERFORDERLICH auf
full; BERATEND aufstandard - Hat Abschnitt "Detaillierte Regeln" (eindeutige Mechaniken) – ERFORDERLICH auf
full/standard. Die GDD-Vorlage betitelt diesen Abschnitt## Detailliertes Design(er enthält Unterüberschriften wie Kernregeln / Zustände / Interaktionen); akzeptiere jede Überschrift als Erfüllung dieser Anforderung – markiere "Detaillierte Regeln" nicht als fehlend, wenn ein## Detailliertes Design-Abschnitt vorhanden ist. - Hat Abschnitt "Formeln" (alle Mathematik mit Variablen definiert) – ERFORDERLICH auf
full; aufstandardERFORDERLICH, wenn das System numerische Regeln definiert (Raten, Kurven, Schwellenwerte, Kosten, Schaden, Drop-Gewichte), sonst BERATEND. DieKategoriedes Systems ist ein Hinweis, nicht der Test – kläre dies nicht nur anhand eines Kategorie-Tokens - Hat Abschnitt "Randfälle" (ungewöhnliche Situationen behandelt) – ERFORDERLICH auf
full/standard - Hat Abschnitt "Abhängigkeiten" (andere Systeme aufgelistet) – ERFORDERLICH auf
full/standard - Hat Abschnitt "Stellschrauben" (konfigurierbare Werte identifiziert) – ERFORDERLICH auf
full; BERATEND aufstandard, es sei denn,workflow_overrides.tuning_knobs - Hat Abschnitt "Akzeptanzkriterien" (testbare Erfolgsbedingungen) – ERFORDERLICH auf
full/standard
Phase 3: Konsistenz und Umsetzbarkeit
Interne Konsistenz:
- Erzeugen die Formeln Werte, die mit dem beschriebenen Verhalten übereinstimmen?
- Widersprechen Randfälle den Hauptregeln?
- Sind die Abhängigkeiten bidirektional (weiß das andere System von diesem)?
Umsetzbarkeit:
- Sind die Regeln präzise genug, damit ein Programmierer sie ohne Raten implementieren kann?
- Gibt es "Handwummel"-Abschnitte, in denen Details fehlen?
- Werden Leistungsauswirkungen berücksichtigt?
- Ist jedes Akzeptanzkriterium unabhängig testbar? Markiere jedes, das es nicht ist, zitiere es – "fühlt sich ausgewogen an", "funktioniert korrekt", "leistet gut" sind keine Kriterien – mit einer messbaren Neufassung. Im
full-Modus überprüftqa-leadsie ebenfalls (Phase 3b); inleanundsololäuft kein Spezialist, also ist diese Hauptprüfung die einzige.
Systemübergreifende Konsistenz:
- Steht dies im Konflikt mit einer bestehenden Mechanik?
- Erzeugt dies unbeabsichtigte Interaktionen mit anderen Systemen?
- Ist dies konsistent mit dem etablierten Ton und den Pfeilern des Spiels?
Registry-Werte, wo immer das GDD sie angibt. Ein in einer Tabelle, einem Katalogeintrag oder einer Variantenbeschreibung wiederholter Wert widerspricht dem Registry genauso wie einer in "Detaillierte Regeln", und das Lesen nach Abschnitten macht diese Körper leicht überfliegbar. Liste die Eintragsnamen des Registrys auf (grep -E '^ - name:' design/registry/entities.yaml), durchsuche dann das gesamte Zieldokument einmal nach allen von ihnen plus den numerischen Schlüsseln, die sie tragen, case-insensitiv, wobei jedes _ als [_ ] geschrieben wird, sodass goblin_scout auch "Goblin scouts" findet:
grep -n -i -E 'goblin[_ ]scout|iron[_ ]sword|health|value[_ ]gold' [target-doc-path]
Überprüfe jede Zeile, die es ausgibt, gegen das Registry, unabhängig davon, in welchem Abschnitt sie steht. Eine Zeile, die einem Eintrag einen anderen Wert gibt, selbst für einen Raum, eine Variante, eine Ebene oder eine Ausnahme, widerspricht dem besitzenden GDD: liste es unter "Erforderlich vor Implementierung" mit seiner Zeilennummer, dem Wert dieses Dokuments und dem des Registrys. Ohne Registry-Einträge führe die gleiche Suche für die Entitäten und Werte durch, die die verwandten GDDs definieren.
Phase 3b: Gegnerisches Spezialisten-Review (nur voller Modus)
Überspringe diese Phase im lean- oder solo-Modus.
Diese Phase ist im vollen Modus VERPFLICHTEND. Überspringe sie nicht.
Vor dem Starten von Agenten gib diesen Hinweis aus:
"Vollständiges Review: Starte spezialisierte Agenten parallel. Dies dauert typischerweise 8–15 Minuten. Verwende
--review leanfür eine schnellere Einzelsitzungsanalyse."
Schritt 1 – Alle vom GDD berührten Bereiche identifizieren
Verwende das bereits in Phase 1 geladene GDD – lies es nicht erneut – und identifiziere jeden vorhandenen Bereich. Ein GDD kann gleichzeitig mehrere Bereiche berühren – sei gründlich. Häufige Signale:
| Wenn das GDD... enthält | Starte diese Agenten |
|---|---|
| Kosten, Preise, Drops, Belohnungen, Wirtschaft | economy-designer |
| Kampfstatistiken, Schaden, Gesundheit, DPS | game-designer, systems-designer |
| KI-Verhalten, Pfadfindung, Zielerfassung | ai-programmer |
| Level-Layout, Spawning, Wellenstruktur | level-designer |
| Spielerfortschritt, EP, Freischaltungen | economy-designer, game-designer |
| UI, HUD, Menüs, spielerorientierte Anzeigen | ux-designer, ui-programmer |
| Dialoge, Quests, Geschichte, Lore | narrative-director |
| Animation, Gefühl, Timing, Saft | gameplay-programmer |
| Mehrspieler, Synchronisation, Replikation | network-programmer |
| Audio-Cues, Musik-Trigger | audio-director |
| Leistung, Draw-Calls, Speicher | performance-analyst |
| Engine-spezifische Muster oder APIs | Primärer Engine-Spezialist (<engine>-specialist von engine.name – Godot→godot-specialist, Unity→unity-specialist, Unreal→unreal-specialist; falle zurück auf die Primärzeile von ## Engine Specialists in |
…
[gekürzt für Übersetzung]