Von SPEC.md zu /goal: Mein Codex + GPT-5.5 Workflow

TL;DR

• Claude ist das beste Modell für die Erstellung einer SPEC.md. Der AskUserQuestionTool Interview-Flow erzwingt Entscheidungen und produziert in 10-15 Minuten eine vollständige Spec.
• GPT-5.5 (via Codex) liest diese Spec danach, hinterfragt sie und schärft sie nach, bevor auch nur eine Zeile Code läuft.
• /goal startet die langfristige Ausführung mit einem strukturierten Prompt-Body: XML-Blöcke, eine Reading List, Arbeitsregeln, Anti-Pattern-Fences und ein Completeness Contract.
• Die Codex-Konfiguration ~/.codex/config.toml macht einen Unterschied. model_reasoning_effort = "high" für die Ausführung, plan_mode_reasoning_effort = "xhigh" für die Planung, model_auto_compact_token_limit für Sessions, die lange laufen.
• Der vollständige Prompt für einen /goal-Run hat 600+ Wörter. Kein Einzeiler. Ein Vertrag.

---

Das ist der zweite Post in einer zweiteiligen Serie. Falls du den ersten noch nicht gelesen hast, fang dort an: /goal: Der sechsstündige Codex-Run, der eine fünfstündige Pause überlebt hat. Jener Post behandelt, was /goal ist, was sich in Codex CLI v0.128.0 geändert hat und wie ein echter sechsstündiger Run aussieht. Dieser Post hier handelt vom Workflow, der einen solchen Run erst ermöglicht: die Spec-Seite, die Prompt-Engineering-Seite, die Konfiguration, die verhindert, dass alles auseinanderfällt.

Diese Pipeline hat eine Weile gebraucht, bis sie sich eingependelt hat. Ich habe immer wieder versucht, alles in einem Modell, einer Session und einem Prompt zu erledigen. Das hat nie länger als 30 Minuten autonome Arbeit gehalten. Zwei Modelle, bewusst sequenziert, ist das, was tatsächlich funktioniert.

Warum zwei Modelle

Claude ist der bessere Interviewer. GPT-5.5 ist der bessere Ausführer.

Dieser Satz klingt vereinfachend, hält aber in der Praxis stand. Claudes AskUserQuestionTool-Flow ist die beste UX, die ich gefunden habe, um Entscheidungen aus dem eigenen Kopf herauszuzwingen. Er stellt 20 bis 40+ Multiple-Choice-Fragen. Man klickt sich durch. Heraus kommt eine Spec, die Entscheidungen widerspiegelt, die man tatsächlich getroffen hat, und keine Annahmen, die das Modell selbst aufgefüllt hat.

GPT-5.5 mit xhigh-Reasoning ist besser bei langfristiger Ausführung. Es hält ein komplexes Ziel über Hunderte von Schritten im Kopf, ohne abzudriften. Es erkennt, wenn ein Sub-Task einer früheren Entscheidung widerspricht. Es parallelisiert Reads und Searches natürlich mit multi_tool_use.parallel, anstatt Dateien eine nach der anderen zu lesen. Es weiß, wann es fertig ist, und sagt es klar, indem es task_complete sauber auslöst, statt einfach zu verstummen.

Ich nutze also beide. Claude für die Spec-Erstellung, weil die UX besser ist. Dann gpt-5.5 zum Verfeinern und Validieren. Dann /goal für die Ausführung.

Wer den Ralph Wiggum Loop kennt, versteht den Impuls: Lange autonome Runs brauchen eine Spec, die den Kontakt mit dem Modell überlebt. Eine wacklige Spec bedeutet, dass das Modell Lücken in die falsche Richtung füllt. Eine saubere Spec bedeutet, dass das Modell etwas Nützliches tut, während man schläft.

Schritt 1: SPEC.md mit Claude

Mit der rohsten Version der eigenen Idee beginnen. Fünf Bulletpoints. Ein Absatz. Das muss nicht gut sein.

Dann Claude Code öffnen und das Interview starten:

read this @SPEC.md and interview me in detail using the
AskUserQuestionTool about literally anything: technical
implementation, UI & UX, concerns, tradeoffs, etc. but
make sure the questions are not obvious

be very in-depth and continue interviewing me continually
until it's complete, then write the spec to the file

Claude stellt 20, 30, manchmal 40+ Fragen. Man klickt sich durch. Wenn es fertig ist, enthält die SPEC.md jede getroffene Entscheidung, dokumentiert, mit der eingebetteten Begründung.

Den Ansatz habe ich ausführlich in Die Interview-Methode beschrieben. Kurzfassung: Strukturierte Fragen durchklicken ist schneller als eine Spec von Grund auf zu schreiben, und die Fragen bringen Edge Cases ans Licht, auf die man ohnehin mitten in der Implementierung gestoßen wäre.

Das Ergebnis dieses Schritts ist eine SPEC.md, der man tatsächlich vertraut. Dieses Vertrauen ist das Fundament für alles Folgende.

Schritt 2: Mit GPT-5.5 verfeinern

Die SPEC.md ist gut. Aber nicht gut genug.

Claude interviewt gut, neigt aber dazu, Antworten für bare Münze zu nehmen. Es baut, was man beschrieben hat. GPT-5.5, dem man die Spec mit einem präzisen Prompt gibt, liest sie skeptischer. Es hinterfragt. Es findet Stellen, an denen die Spec technisch möglich, aber architektonisch schmerzhaft ist. Es fragt, was in den Fehlerfällen passiert, die man nicht aufgezählt hat.

Mein Verfeinerungs-Prompt ist direkt:

Read SPEC.md. Identify every ambiguous requirement.
For each one: explain the ambiguity, give me two distinct
interpretations, and recommend the one that will produce
a more maintainable result. Then tighten the spec in place.
Do not change decisions that are already clear.
Do not add scope. Remove anything that can't be verified.

Nach diesem Durchgang habe ich eine Spec, die GPT-5.5 selbst kritisch gelesen und abgenommen hat. Wenn dasselbe Modell dann /goal ausführt, begegnet es der Spec nicht kalt. Es hat sie bereits einem Stresstest unterzogen.

Dieser Schritt dauert 5 Minuten. Er hat mir mehrere 2-stündige Debugging-Sessions erspart, in denen das Modell exakt das implementiert hat, was die Spec vorgab, und was die Spec vorgab, sich als falsch herausgestellt hat.

Schritt 3: Den Lauf mit /goal anstoßen

/goal ist ein Codex-Feature für langfristige autonome Ausführung. Man gibt ihm einen strukturierten Prompt-Body, und es läuft, trifft Entscheidungen, überprüft die eigene Arbeit, komprimiert den Kontext bei Bedarf und stoppt, wenn der Completeness Contract erfüllt ist.

Der /goal-Prompt ist nicht kurz. Meiner hat 600+ Wörter. Das ist die Struktur, die ich verwende:

/goal

<goal>
[Was der Task produziert. Konkret. Messbar. Keine vagen Verben.]
</goal>

<context>
[Dateien, die vor dem Start gelesen werden. 10+ Einträge. Das Modell
lädt diese, bevor es irgendetwas anderes tut.]
</context>

<constraints>
[Architekturregeln. Was das Modell nicht tun darf. Anti-Pattern-Fences.]
</constraints>

<done_when>
[Explizite, überprüfbare Kriterien. Test Suites grün. Bestimmte
Datei-Outputs vorhanden. Keine bestimmten Fehlermodi beobachtet.
Das Modell nutzt diesen Block, um zu entscheiden, wann task_complete
ausgelöst wird.]
</done_when>

<workflow>
[Schritt-für-Schritt Ausführungsreihenfolge. Was parallel läuft.
Wo Verification Gates liegen.]
</workflow>

<verification_loop>
[Self-Check-Protokoll. Was das Modell nach jedem wichtigen Schritt
ausführt, um zu bestätigen, dass nichts kaputtgegangen ist.]
</verification_loop>

<execution_rules>
[Arbeitsregeln. Wortwörtlich, konkret. Beispiele unten.]
</execution_rules>

<output_contract>
[Was das Modell als Deliverables produzieren muss. Formate. Speicherorte.
Abschlusssignal.]
</output_contract>

Die XML-Block-Struktur ist kein Cargo Culting. Jeder Block beantwortet eine Frage, die das Modell sonst erraten müsste. <done_when> ist der wichtigste. Ohne einen expliziten Terminations-Vertrag neigen Modelle dazu, entweder zu früh zu stoppen oder endlos weiterzupolieren.

Ich habe diese XML-Tags im April manuell verwendet, bevor /goal als Feature veröffentlicht wurde. Die Struktur funktioniert mit oder ohne das Runtime-Feature. Mit /goal aktiviert sie auch den Persistence Cue: Sobald die Richtung vorgegeben ist, sammelt das Modell Kontext, plant, implementiert, testet und verfeinert, ohne auf Prompts bei jedem einzelnen Schritt zu warten.

Prompt-Patterns für GPT-5.5

Das sind die Patterns, die ich in jeden /goal-Run einbaue. Sie kommen direkt davon, wie GPT-5.5 sich bei high- und xhigh-Reasoning-Effort verhält, und aus dem OpenAI Cookbook: GPT-5 Codex Prompting Guide.

1. Die Reading List vorab laden. 10+ Dateien explizit in <context> auflisten. Das Modell liest sie, bevor es irgendetwas tut. Das bewahrt es davor, in den frühen Schritten Annahmen über die Codebase-Struktur zu machen, wo es eigentlich lernen sollte.

2. Die Arbeitsregeln wortwörtlich hinschreiben. In <execution_rules> eintragen. Konkrete, imperative Sätze. “Check git status before edits.” “Preserve unrelated user changes.” “Prefer rg over grep.” “Use apply_patch for manual edits.” “Do not create long-lived feature flags.” “Delete legacy paths once replacement tests pass.” Das Modell hält sich konsistent daran, wenn sie explizit angegeben sind.

3. Die Anti-Patterns absperren. In <constraints> eintragen: “Do not add string-matching patches to pass one test. If a test exposes a bad loop, fix the underlying evaluator, not the symptom.” Dieser eine Satz hat mindestens drei Hacks verhindert, die CI bestanden hätten und Production gebrochen hätten.

4. Architekturregeln einbacken. Beispiele: “Deterministic logic only at protocol/runtime boundaries. Semantic interpretation must not be regex-driven.” Das verhindert, dass das Modell Shortcuts nimmt, die die Test Suite befriedigen, aber das Design verletzen. Steht die Regel nicht im Prompt, optimiert das Modell für grüne Tests.

5. Messbare <done_when>-Kriterien formulieren. “All test suites green. Manual review of three representative outputs confirms no hallucinated citations. No 429 errors in the final 100 requests.” Vage Kriterien produzieren vages Stopp-Verhalten. Das Modell nutzt diesen Block, um zu bewerten, ob es wirklich fertig ist.

6. multi_tool_use.parallel für gebündelte Reads nutzen. Dem Modell explizit sagen: “Read all context files in parallel before starting.” GPT-5.5 tut das bei xhigh von Natur aus, aber es im Prompt festzulegen, verankert es auch für Sub-Tasks mitten im Run.

7. Länge der Abschlussantwort von der Reasoning-Qualität trennen. Eine Zeile hinzufügen wie “Reasoning may be thorough; final output should be concise. Code blocks only, no commentary unless explicitly requested.” Bei xhigh-Effort kann das Modell sehr lange Reasoning-Ketten produzieren. Man will die Qualität dieses Reasonings auf die Aufgabe angewandt sehen, nicht im Output surfaced.

Das Skills Repo

Ich pflege ein öffentliches Repository mit Agent-Skills unter github.com/yz5e/agent-skills. Mehrere davon sind direkt für diesen Workflow relevant.

gpt-5-5-prompt-writer kodifiziert die XML-Block-Strukturierung, das Reasoning- und Verbosity-Tuning und die Verification Cycles, die oben beschrieben sind. Wenn man einen ausgefeilten /goal-Prompt will, ohne ihn von Grund auf zu schreiben, produziert dieser Skill einen Entwurf, der die Struktur bereits enthält. Lohnt sich bei Tasks, die komplex genug sind, dass man nicht sicher ist, ob man alle Blöcke abgedeckt hat.

forge ist ein interview-gesteuerter Prompt-Erstellungs-Skill für entweder gpt-5.5 oder Claude Opus 4.7. Er stellt einem Fragen über die Aufgabe, genau wie der AskUserQuestionTool-Flow, und produziert einen vollständigen strukturierten Prompt. Gut, wenn man weiß, was man bauen will, aber nicht sicher ist, wie man es als /goal-Prompt formuliert.

code-simplifier und opus-4-7-prompt-writer sind komplementär. Der erste prüft Code, der aus einem langen Run stammt, und markiert alles, das überkompliziert aussieht. Der zweite ist das Claude-seitige Äquivalent von gpt-5-5-prompt-writer.

Skills können per Symlink in ~/.codex/skills eingebunden werden. Das Repo enthält Install-Anweisungen.

Die Konfiguration

Die ~/.codex/config.toml-Datei macht hier echte Arbeit. Das ist die Konfiguration, die ich für autonome /goal-Sessions verwende:

model = "gpt-5.5"
model_context_window = 1050000
model_auto_compact_token_limit = 997500
model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"
approval_policy = "never"
sandbox_mode = "danger-full-access"

[features]
goals = true

Ein paar Anmerkungen zu den einzelnen Einstellungen.

model_reasoning_effort = "high" für Ausführungs-Tasks. plan_mode_reasoning_effort = "xhigh" für den Planungs-Durchgang. Diese entsprechen den Reasoning-Effort-Tiers: low, medium, high, xhigh. Standard ist medium. Für alles, das man mehrere Stunden laufen lassen würde, reicht medium nicht. Das Modell nimmt dann bei schwierigen Sub-Tasks den günstigeren Weg.

model_auto_compact_token_limit = 997500 ist das, was eine /goal-Session über das hinaus ermöglicht, was sonst ein hartes Kontext-Limit wäre. Das Modell komprimiert seinen Kontext automatisch, wenn es sich dem Limit nähert, bewahrt den wesentlichen Zustand und fährt fort. Ohne das würde ein sechs-stündiger Run irgendwo in Stunde zwei hart stoppen.

approval_policy = "never" und sandbox_mode = "danger-full-access" sollten nur in Verzeichnissen verwendet werden, die man in der Konfiguration explizit als vertrauenswürdig markiert hat. Diese Einstellungen geben dem Modell vollen Schreibzugriff auf das Dateisystem. Nicht in einem Verzeichnis verwenden, das man keinem unbeaufsichtigten Prozess überlassen würde. Ich wende sie nur auf bestimmte Projekt-Pfade an.

Der Mindset Shift

Alt: Einen Prompt schreiben, eine Antwort bekommen, manuell iterieren. Neu: Einen Vertrag schreiben, ihn dem Modell übergeben, das Deliverable prüfen.

Die Verschiebung geht von Prompt-zu-Antwort zu Spec-zu-Ausführung. Sobald man aufhört, /goal als besseren Chat zu betrachten, und anfängt, es als Weg zu sehen, einen definierten Arbeitsumfang zu delegieren, fällt der Workflow an seinen Platz. Die Spec ist nicht Vorarbeit vor der eigentlichen Arbeit. Die Spec ist die Arbeit. Das Modell erledigt die Implementierung.

---

Fazit

Zwei Modelle. Eine Pipeline. Claude interviewt einen und produziert eine Spec. GPT-5.5 liest diese Spec kritisch und schärft sie nach. Dann läuft /goal mit einem strukturierten Prompt, der die Arbeitsregeln, die Architektur-Constraints und die Abbruchkriterien einbaut.

Die Konfiguration ist nicht optional. xhigh-Reasoning im Plan-Modus, high bei der Ausführung, model_auto_compact_token_limit hoch genug gesetzt, um einen langen Run zu überstehen. Der Prompt ist nicht kurz. 600+ Wörter, strukturierte XML-Blöcke, explizite Anti-Pattern-Fences. Die Spec ist keine grobe Idee. Es ist ein Dokument, das einen GPT-5.5-Challenge-Durchgang überlebt hat.

Das ist ein Workflow, kein Hack. Er funktioniert, weil jedes Teil das übernimmt, was es am besten kann. Kein Modell macht alles.

Das erste Mal, wenn ein sechs-stündiger Run sauber abgeschlossen wird und man den Output öffnet, fühlt es sich an, als hätte sich etwas verschoben. Hat es auch.

Lies den begleitenden Post, falls noch nicht geschehen: /goal: Der sechsstündige Codex-Run, der eine fünfstündige Pause überlebt hat.

---

Quellen

• OpenAI Cookbook: GPT-5 Codex Prompting Guide
• Codex configuration reference
• yz5e/agent-skills on GitHub
• Codex v0.128.0 release notes