ask-codex

OpenAIs Codierungsagent Codex wird über codex exec (nicht-interaktiver Modus) aufgerufen, um Designberatung, Tiefenrecherche und Code-Reviews zu beauftragen.

Codex neigt dazu, hartnäckig zu recherchieren und die Genauigkeit zu erhöhen, daher eignet er sich besonders für zweite Meinungen und Tiefenrecherchen bei hoher Genauigkeitsanforderung.

Codex startet bei jedem Aufruf kalt und weiß nichts von der aktuellen Konversation, dem Plan oder den bisherigen Ergebnissen. Voraussetzungen, Absichten, Randbedingungen und zugehörige Dateien müssen bei jedem Aufruf explizit im Prompt angegeben werden (siehe unten „Schreiben von Aufgabenbeschreibungen“ und Beispiele).

Voraussetzungen

Die codex CLI muss installiert und authentifiziert sein (überprüfbar mit codex --version).
Wenn die Authentifizierung abgelaufen ist, ist ein erneutes Setup auf Codex-Seite erforderlich; der Benutzer muss darüber informiert werden.

Vor der Ausführung

Vor dem Aufruf von Codex wird dem Benutzer in einem Satz mitgeteilt, worum es geht. Es muss nicht auf eine Bestätigung gewartet werden; die Ausführung kann nach der Mitteilung direkt erfolgen.

Grundlegendes Aufrufmuster

Codex ist ein schreibgeschützter übergeordneter Reviewer, daher wird standardmäßig -s read-only verwendet. Der Prompt wird über stdin (codex exec -) übergeben, um Shell-Escaping zu vermeiden.

Zwei wesentliche Vorgehensweisen:

Die Antwort (mittels cat) muss im selben Befehl wie der Codex-Aufruf abgeschlossen werden. Die Variable $OUT aus OUT=$(mktemp …) existiert im nächsten Shell-Aufruf (einer anderen Shell) nicht mehr, sodass der Pfad beim nachfolgenden Lesen verloren geht. Ein cat im selben Befehl stellt sicher, dass die Antwort zuverlässig abgerufen werden kann, ohne auf ein bestimmtes Verhalten angewiesen zu sein.
stdout/stderr von Codex selbst werden nicht in den Kontext geleitet. Codex gibt Fortschrittslogs, Header, Warnungen, Hooks, Schluss-Echos und tokens used auf stderr aus, während nur die endgültige Nachricht auf stdout und in die -o Datei geschrieben wird (alles, was Codex „getan/gedacht“ hat, geht auf stderr). Da nur das Endergebnis benötigt wird, wird stdout verworfen und stderr in eine temporäre Datei umgeleitet, die nur im Fehlerfall angezeigt wird. So enthält das Tool-Ergebnis nur die endgültige Nachricht von cat "$OUT", während Fehlerursachen (abgelaufene Authentifizierung, ungültige Flags usw.) nur bei Misserfolg sichtbar werden.

Es gibt zwei kanonische Rezepte für verschiedene Anwendungsfälle:

A. Kurze Anfragen / kleine Reviews (Vordergrund)

Die Antwort (nur die endgültige Nachricht) wird im Tool-Ergebnis der Shell-Ausführung zurückgegeben. Kein zusätzliches Read erforderlich.

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' "$PROMPT" | codex exec - -s read-only -C <DIR> -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
cat "$OUT"

B. Zeitintensive Aufrufe (Hintergrund)

codex exec kann mehrere Minuten dauern; die Vordergrundausführung kann je nach Umgebung abgebrochen werden. Für Tiefenrecherchen oder Code-Reviews mit codex exec review, die länger dauern, wird der Aufruf über die Hintergrundausführungsmechanik des Hosts ausgeführt (die genaue Methode bleibt dem Host überlassen). Der eigentliche Befehl variiert je nach Anwendungsfall: codex exec - (Beratung/Recherche) oder codex exec review (Diff-Review, siehe unten).

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' "$PROMPT" | codex exec - -s read-only -C <DIR> -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
echo "=== ANSWER ==="; cat "$OUT"

Nach Abschluss gibt der Host eine Fertigstellungsbenachrichtigung aus, und die Hintergrundausgabe enthält die Antwort ab === ANSWER ===. Diese Ausgabe kann gelesen werden (bei langen Antworten kann mit grep nach === ANSWER === gesucht werden). Es soll keine eigene Polling-Schleife mit sleep/pgrep gebaut werden (der Host benachrichtigt über den Abschluss).

Bedeutung der Flags

codex exec -: Liest den Prompt von stdin. Ermöglicht sicheres Übergeben von langen Texten, Codeblöcken und Sonderzeichen.
-s read-only: Erlaubt nur Lesezugriff. Dieses Flag wird bei diesem Skill standardmäßig gesetzt (da Codex als Berater/Reviewer fungiert, ist Schreibzugriff nicht erforderlich). Es ist nicht der Standardwert der CLI/Konfiguration. Gilt nur für codex exec, nicht für codex exec review (dort führt es zu einem Fehler).
-C <DIR>: Arbeitsverzeichnis für codex exec. Zeigt auf das Repository, das untersucht/reviewed werden soll. Wenn weggelassen, wird das aktuelle Verzeichnis verwendet. codex exec review hat kein -C, daher muss bei einem Review innerhalb desselben Befehls zuerst cd <DIR> ausgeführt werden (siehe unten).
-o <FILE>: Schreibt nur die endgültige Nachricht von Codex in diese Datei. Die Datei wird erst bei Abschluss beschrieben (während der Ausführung ist sie leer), daher darf sie vor Abschluss nicht gelesen werden. In den kanonischen Rezepten ist dies die Quelle der Antwort.
stdout: Codex gibt die endgültige Nachricht auch auf stdout aus, aber in den kanonischen Rezepten wird aus -o gelesen, daher wird stdout mit >/dev/null verworfen (um Doppelausgabe zu vermeiden und Kontext zu sparen).
stderr: Enthält Fortschrittslogs, Header, Warnungen, Hooks, Schluss-Echos, tokens used und Fehler (abgelaufene Authentifizierung, ungültige Flags, fehlgeschlagene Repo-Prüfung usw.). Ein einfaches 2>/dev/null würde die Ursache verbergen, wenn cat "$OUT" leer ist. Daher wird stderr in eine temporäre Datei ($ERR) umgeleitet und nur bei Fehlern mit cat "$ERR" angezeigt. Im Erfolgsfall wird kein Kontext hinzugefügt; nur bei Fehlern wird die Ursache sichtbar.
mktemp /tmp/codex_answer.XXXXXX.txt: Das Suffix XXXXXX wird zufällig ersetzt und erzeugt einen eindeutigen, kollisionsfreien Pfad. Auch bei parallelen mehrfachen Aufrufen wird pro Aufruf ein separates mktemp erzeugt.

Normalerweise nicht benötigte Optionen

--skip-git-repo-check: Nur erforderlich, wenn die Ausführung außerhalb eines Git-Repositorys erfolgt. Innerhalb eines Repos nicht setzen.
-s workspace-write: Nur wenn Codex Änderungen vornehmen soll. Dies liegt außerhalb des Anwendungsbereichs dieses Skills (read-only Reviewer), daher grundsätzlich nicht verwenden.

Modellauswahl

Um ein bestimmtes Modell zu verwenden, wird -m <MODEL> (z. B. -m gpt-5.5) gesetzt. Ohne Angabe folgt Codex der Konfigurationsvorgabe. Nicht unnötig setzen; nur auf Benutzerwunsch hinzufügen.

Websuche

Wenn in ~/.codex/config.toml web_search = "live" gesetzt ist, kann Codex Websuche verwenden. Die Websuche ist ein natives Tool der Responses-API und wird daher auch durch -s read-only (das nur Shell-Ausführungen einschränkt) nicht blockiert. Wenn spezifische Details von Bibliotheken, APIs oder CLIs überprüft werden sollen, wird im Prompt explizit „Bitte in den offiziellen Dokumentationen per Websuche prüfen“ angegeben. codex exec selbst hat kein --search-Flag; die Steuerung erfolgt über die web_search-Konfiguration.

Hilfe anzeigen

codex exec -h zeigt die Hilfe an.

Schreiben von Aufgabenbeschreibungen

LLMs folgen Beispielen am besten, daher dienen die folgenden Beispiele für printf-Prompts als direkte Vorlage für gute Aufgabenbeschreibungen. Jede Anfrage sollte auf eine einzelne Entscheidung/Review/Plan/Recherche beschränkt sein und Folgendes enthalten:

Absicht/Hintergrund/Randbedingungen: Da Codex kalt startet, müssen das Ziel, der Grund und die Voraussetzungen immer genannt werden.
Zugehörige Dateien: Werden inline mit @path/to/file angegeben. Wenn aktuelle Änderungen berücksichtigt werden sollen, wird explizit „Bitte die Diffs mit git diff prüfen“ gesagt.
Fokus/alternative Optionen/zu untersuchende Risiken: Werden konkret beschrieben.
Ausgabeformat: Wird spezifiziert (z. B. ranked risks / Tradeoff-Tabelle / empfohlene Planänderung).
Was ignoriert werden soll: Um Scope Creep zu vermeiden, werden Dinge wie Benennung/Formatierung explizit ausgeschlossen.
Wenn externe Spezifikationen geprüft werden müssen: Wird explizit „Bitte in den offiziellen Dokumentationen per Websuche prüfen“ angegeben.
Review: Soll in der Reihenfolge Absicht → Implementierung erfolgen (zuerst Prüfung auf Absicht, dann auf Implementierung).

Der Prompt-Text wird mit printf '%s' '…' in einfachen Anführungszeichen umschlossen. Dadurch werden $ und Backticks im Text sicher vor der Shell interpretiert (nur wenn der Text ein ASCII ' enthält, muss eine andere Umschließung gewählt werden).

Beispiele nach Anwendungsfall

1. Zweite Meinung / Vergleich mehrerer Optionen (Rezept A)

Zweite Meinung zu Design-/Implementierungsentscheidungen. Je konkreter die zu vergleichenden Optionen, Randbedingungen und das Ausgabeformat, desto höher die Qualität.

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' 'Absicht: Ich möchte das Verfahren zum Aktualisieren von Authentifizierungstoken festlegen. Derzeit wird bei jedem API-Aufruf die Gültigkeit geprüft und synchron aktualisiert (@src/auth/client.ts), was bei vielen parallelen Anfragen zu doppelten Aktualisierungen führt.

Zu vergleichende Optionen:
(1) Gemeinsames Promise während der Aktualisierung verwenden
(2) Proaktive Hintergrundaktualisierung vor Ablauf
(3) Nach 401 einmal aktualisieren und wiederholen

Randbedingungen: Muss sowohl in SSR als auch CSR funktionieren. Keine neuen Bibliotheken hinzufügen.
Ausgabe: Tradeoff-Tabelle mit Spalten correctness / Komplexität / Fehlermodi, empfohlener Standard- und Fallback-Plan, unter welchen Bedingungen zu einer anderen Option gewechselt werden sollte. Benennung/Formatierung ignorieren.' \
  | codex exec - -s read-only -C /path/to/repo -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
cat "$OUT"

2. Code-Review

Wichtige Einschränkung: Die Bereichsflags von codex exec review (--uncommitted / --base / --commit) können nicht zusammen mit einem benutzerdefinierten PROMPT (weder über stdin - noch über Positionsargumente) verwendet werden (getestet mit Codex 0.142.4; bei gemeinsamer Verwendung erscheint der Fehler error: the argument '--uncommitted' cannot be used with '[PROMPT]'). Daher wird nach Anwendungsfall unterschieden:

2a. Review mit Perspektive/Absicht (Hauptanwendungsfall dieses Skills, empfohlen): Da Bereichsflags und Perspektivenvorgabe nicht gleichzeitig verwendet werden können, wird statt codex exec review codex exec - (Rezept A/B) verwendet. Die Bereichseingrenzung erfolgt durch die Aufforderung, git diff etc. im Prompt zu prüfen. -s read-only / -C / stdin bleiben nutzbar und Escaping wird vermieden.

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' 'Absicht: Diese Änderung sollte das Verhalten nur beim Unterdrücken von Ruhetonsignalen ändern und die Wiedergabe von Benutzereingabeanforderungen nicht beeinflussen. Bitte die uncommitted Änderungen per git diff (ggf. auch git diff --cached und untracked) prüfen. Zuerst Prüfung auf Absicht, dann auf Implementierung.
Fokus: Umkehrung von Bedingungen, Änderung von Standardwerten, Bedeutungskonflikte zwischen Client/Server.
Ausgabe: Empfehlung → findings mit evidence → ungeprüfte Annahmen. Benennung/Formatierung ignorieren.' \
  | codex exec - -s read-only -C /path/to/repo -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
echo "=== ANSWER ==="; cat "$OUT"

2b. Reines Diff-Review ohne Perspektivenvorgabe: Wenn kein benutzerdefinierter Prompt erforderlich ist, können die Bereichsflags von codex exec review direkt verwendet werden (da kein PROMPT angegeben wird, wird die oben genannte Einschränkung nicht aktiv). codex exec hat kein -C und kein -s, daher muss zuerst in das Zielrepository gewechselt werden.

OUT=$(mktemp /tmp/codex_review.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
cd /path/to/repo || exit 1
codex exec review --uncommitted -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
echo "=== ANSWER ==="; cat "$OUT"

Austausch der Bereichsflags (ersetzen Sie die Zeile codex exec review … oben; in keinem Fall einen PROMPT angeben):

codex exec review --uncommitted -o "$OUT" >/dev/null 2>"$ERR"   # Uncommitted (staged + unstaged + untracked)
codex exec review --base main   -o "$OUT" >/dev/null 2>"$ERR"   # Diff zum Basis-Branch
codex exec review --commit <SHA> -o "$OUT" >/dev/null 2>"$ERR"  # Bestimmter Commit

Für Reviews mit Perspektive wird 2a (codex exec - + git diff) verwendet. Bereichsflags + benutzerdefinierte Anweisungen können nicht gleichzeitig verwendet werden.
Review wird innerhalb des Zielrepositorys ausgeführt (-C existiert nicht, also vorher cd). Außerhalb des Repos ist --skip-git-repo-check nutzbar, aber ohne Diff im Review-Ziel sinnlos.

3. Validierung von Plänen/Migrationen (Rezept B)

Vor der Implementierung werden Pläne/Migrationsschritte einem Stresstest unterzogen, um Lücken zu identifizieren, die vor Beginn geschlossen werden müssen. Im schreibgeschützten Modus werden die aktuellen Code-Verträge geprüft.

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' 'Bitte den Plan vor der Implementierung reviewen und nur die Lücken nennen, die vor dem Codieren geschlossen werden müssen.
Plan: Wenn die Ereignissynchronisation vom Server abgewiesen wird, wird repair_required gesetzt, ein kompaktes Snapshot gesendet, und nach Bestätigung der konsistenten Sequenz durch den Server werden nur noch inkrementelle Ereignisse fortgesetzt.
Zugehörig: @src/sync/event-syncer.ts @src/db/sync-state.ts @api/types.ts.
Bitte die aktuellen Verträge durch Lesen des vorhandenen Codes prüfen, bevor bewertet wird.
Fokus: Schema-Kompatibilität, Snapshot-Größenlimit, Randbedingungen der Fortsetzungssequenz, Auswirkungen von Backfill/Migration, fehlende Tests.
Ausgabe: Nur die vor Beginn erforderlichen Planänderungen + eine kurze Aussage, ob „die Implementierung so sicher ist“. ' \
  | codex exec - -s read-only -C /path/to/repo -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
echo "=== ANSWER ==="; cat "$OUT"

4. Tiefenrecherche (Rezept B)

Hartnäckige Untersuchung von Fehlern, Testfehlern, Race Conditions, veralteten Caches usw. Die Angabe überprüfbarer Erfolgskriterien nutzt Codex‘ Fähigkeit zur Tiefenrecherche optimal. Zeitintensiv, daher als Hintergrundaufgabe.

OUT=$(mktemp /tmp/codex_answer.XXXXXX.txt)
ERR=$(mktemp /tmp/codex_err.XXXXXX.txt)
printf '%s' 'Der Test TestBar in foo_test.go schlägt in CI selten fehl. Bitte die Grundursache untersuchen.
Erfolgskriterium: Reproduktionsbedingungen und Ursache auf Datei:Zeile identifizieren und einen minimalen Korrekturvorschlag präsentieren.
Wenn ein externer Library-Verdacht besteht, bitte die offiziellen Dokumentationen der betreffenden Bibliothek per Websuche prüfen.' \
  | codex exec - -s read-only -C /path/to/repo -o "$OUT" >/dev/null 2>"$ERR" \
  || { echo "codex failed:"; cat "$ERR"; exit 1; }
echo "=== ANSWER ==="; cat "$OUT"

Umgang mit den Ergebnissen

Aus der Antwort (bei Rezept A im Tool-Ergebnis, bei Rezept B in der Hintergrundausgabe nach Fertigstellung) werden die Kernaussagen an den Benutzer weitergegeben. Bei langen Antworten wird zusammengefasst, während wichtige Hinweise im Original zitiert werden.
Codex kann extrem defensive Vorschläge machen (übermäßige Rücksicht auf Abwärtskompatibilität usw.). Es wird selbst entschieden, welche Hinweise übernommen und welche abgelehnt werden. Nicht blind übernehmen; nur übernehmen, was sinnvoll erscheint.

S sure33/agent-skills

Was ist agent-skills?

In Ihrer bevorzugten KI fragen

Dokumentation