concava/skills

Anleitung für die Codex-Skill

Ausführen einer Aufgabe

1. Fragen Sie den Benutzer bei einer neuen Sitzung (Fortsetzungen übernehmen das vorherige Modell/den vorherigen Aufwand – siehe Schritt 5) in einer einzigen Eingabeaufforderung mit zwei Fragen, welches Modell UND welcher Reasoning-Aufwand verwendet werden soll. Wenn der Benutzer keine Präferenz äußert, verwenden Sie standardmäßig gpt-6-astra mit high.
   • Modell – Standard gpt-6-astra:
     • GPT-6: gpt-6-astra (führend / am leistungsfähigsten – Standard)
     • GPT-5.6: gpt-5.6-sol (zuverlässiges agentisches Arbeitspferd), gpt-5.6-terra (ausgewogen, alltäglich), gpt-5.6-luna (schnell & erschwinglich)
     • Legacy (aus Kompatibilitätsgründen beibehalten): gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, gpt-5.3-codex
   • Reasoning-Aufwand – Standard high: low, medium, high, xhigh, max, ultra.
     • max/ultra erfordern ein GPT-6- oder GPT-5.6-Modell; ultra ist nur auf astra/sol/terra verfügbar (luna ist auf max begrenzt); Legacy-Modelle sind auf xhigh begrenzt.
     • ultra = maximales Reasoning mit automatischer Aufgabenverteilung (am langsamsten und teuersten – für die schwierigsten Aufgaben reservieren).
     • Wenn der gewählte Aufwand das Maximum des gewählten Modells überschreitet, auf den höchsten unterstützten Aufwand dieses Modells zurückgreifen und den Benutzer informieren.
2. Wählen Sie den für die Aufgabe erforderlichen Sandbox-Modus; standardmäßig --sandbox read-only, es sei denn, Bearbeitungen oder Netzwerkzugriff sind erforderlich.
3. Setzen Sie den Befehl mit den entsprechenden Optionen zusammen:
   • -m, --model <MODELL>
   • --config model_reasoning_effort="<low|medium|high|xhigh|max|ultra>" (max/ultra nur auf GPT-6 / GPT-5.6 Modellen; ultra nur auf astra/sol/terra – siehe Schritt 1)
   • --sandbox <read-only|workspace-write|danger-full-access>
   • --full-auto
   • -C, --cd <VERZ>
   • --skip-git-repo-check
   • "Ihre Eingabeaufforderung hier" (als letztes Positionsargument)
4. Verwenden Sie immer --skip-git-repo-check.
5. Verwenden Sie beim Fortsetzen einer vorherigen Sitzung codex exec --skip-git-repo-check resume --last über stdin. Verwenden Sie beim Wiederaufnehmen keine Konfigurationsflags, es sei denn, der Benutzer hat sie ausdrücklich angefordert, z. B. wenn er das Modell oder den Reasoning-Aufwand angibt. Syntax für Wiederaufnahme: echo "Ihre Eingabeaufforderung hier" | codex exec --skip-git-repo-check resume --last 2>/dev/null. Alle Flags müssen zwischen exec und resume eingefügt werden.
6. WICHTIG: Hängen Sie standardmäßig 2>/dev/null an alle codex exec-Befehle an, um Denk-Token (stderr) zu unterdrücken. Zeigen Sie stderr nur an, wenn der Benutzer ausdrücklich die Anzeige von Denk-Token anfordert oder wenn Debugging erforderlich ist.
7. WICHTIG (stdin): codex exec liest immer stdin und verknüpft es mit der Positionsaufforderung – auch wenn die Aufforderung vollständig als Positionsargument angegeben wird. Wenn stdin nicht geschlossen wird, blockiert Codex dauerhaft. Wenn Sie aus einer Umgebung aufrufen (Hintergrundaufgaben, Hooks, Skripte, in denen stdin kein TTY ist, aber auch nicht geschlossen wird), leiten Sie stdin explizit um: Hängen Sie </dev/null an den Befehl an, z. B. codex exec ... "Aufforderung" </dev/null 2>/dev/null. Symptom, wenn dies falsch gemacht wird: Null Bytes stdout, null CPU-Akkumulation, Prozess scheint auf unbestimmte Zeit zu hängen.
8. Führen Sie den Befehl aus, erfassen Sie stdout/stderr (gefiltert wie angemessen) und fassen Sie das Ergebnis für den Benutzer zusammen.
9. Nachdem Codex abgeschlossen ist, informieren Sie den Benutzer: "Sie können diese Codex-Sitzung jederzeit fortsetzen, indem Sie 'codex resume' sagen oder mich bitten, mit zusätzlichen Analysen oder Änderungen fortzufahren."

Kurzreferenz

Anwendungsfall	Sandbox-Modus	Wichtige Flags
Schreibgeschützte Überprüfung oder Analyse	read-only	--sandbox read-only 2>/dev/null
Anwenden lokaler Bearbeitungen	workspace-write	--sandbox workspace-write --full-auto 2>/dev/null
Netzwerk- oder breiten Zugriff erlauben	danger-full-access	--sandbox danger-full-access --full-auto 2>/dev/null
Letzte Sitzung fortsetzen	Von ursprünglicher Sitzung übernommen	echo "Aufforderung" | codex exec --skip-git-repo-check resume --last 2>/dev/null (keine Flags erlaubt)
Von einem anderen Verzeichnis aus ausführen	Den Aufgabenanforderungen entsprechend	-C <VERZ> plus andere Flags 2>/dev/null

Ausführungs-Timeout

Codex erzeugt keine Zwischenausgabe – es schreibt das Ergebnis erst bei Abschluss. Wenn der Prozess vor dem Beenden beendet wird, ist die Ausgabedatei stillschweigend leer (kein Fehler).

Bevorzugter Ansatz: synchron ausführen – eliminiert das Timeout-Risiko vollständig, und die Konversation wartet ohnehin auf das Ergebnis.

Wenn im Hintergrund ausgeführt, setzen Sie das Ausführungs-Timeout basierend auf dem Reasoning-Aufwand:

Reasoning-Aufwand	Timeout
low	150s
medium	300s
high	600s
xhigh	1200s
max	1800s
ultra	1800s

Nachfassen

• Verwenden Sie nach jedem codex-Befehl sofort AskUserQuestion, um nächste Schritte zu bestätigen, Klarstellungen einzuholen oder zu entscheiden, ob mit codex exec resume --last fortgesetzt werden soll.
• Leiten Sie beim Wiederaufnehmen die neue Aufforderung über stdin: echo "neue Aufforderung" | codex exec resume --last 2>/dev/null. Die fortgesetzte Sitzung verwendet automatisch dasselbe Modell, denselben Reasoning-Aufwand und denselben Sandbox-Modus wie die ursprüngliche Sitzung.
• Wiederholen Sie das gewählte Modell, den Reasoning-Aufwand und den Sandbox-Modus, wenn Sie Folgemaßnahmen vorschlagen.

Kritische Bewertung der Codex-Ausgabe

Codex wird von OpenAI-Modellen mit eigenen Wissensgrenzen betrieben. Behandeln Sie Codex als Kollegen, nicht als Autorität.

Richtlinien

• Vertrauen Sie Ihrem eigenen Wissen, wenn Sie sich sicher sind. Wenn Codex etwas behauptet, von dem Sie wissen, dass es falsch ist, widersprechen Sie direkt.
• Recherchieren Sie Unstimmigkeiten mit WebSearch oder Dokumentation, bevor Sie Codex' Behauptungen akzeptieren. Teilen Sie die Ergebnisse bei Bedarf über eine Wiederaufnahme mit Codex.
• Denken Sie an Wissensgrenzen – Codex kennt möglicherweise keine aktuellen Veröffentlichungen, APIs oder Änderungen, die nach seinen Trainingsdaten aufgetreten sind.
• Vertrauen Sie nicht blind – Codex kann falsch liegen. Bewerten Sie seine Vorschläge kritisch, insbesondere in Bezug auf:
  • Modellnamen und -fähigkeiten
  • Aktuelle Bibliotheksversionen oder API-Änderungen
  • Best Practices, die sich möglicherweise weiterentwickelt haben

Wenn Codex falsch liegt

1. Erklären Sie dem Benutzer klar, wo Sie widersprechen
2. Liefern Sie Beweise (Ihr eigenes Wissen, Websuche, Dokumentation)
3. Setzen Sie optional die Codex-Sitzung fort, um die Meinungsverschiedenheit zu diskutieren. Identifizieren Sie sich als Claude, damit Codex weiß, dass es sich um eine KI-Diskussion auf Augenhöhe handelt. Verwenden Sie Ihren tatsächlichen Modellnamen (z. B. das Modell, unter dem Sie derzeit laufen) anstelle eines fest codierten Namens:

   echo "Dies ist Claude (<Ihr aktueller Modellname>) mit einer Rückmeldung. Ich widerspreche [X] wegen [Beweise]. Was ist Ihre Meinung dazu?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
   

4. Stellen Sie Meinungsverschiedenheiten als Diskussionen dar, nicht als Korrekturen – jede KI könnte falsch liegen
5. Lassen Sie den Benutzer entscheiden, wie bei echter Ambiguität fortgefahren werden soll

Fehlerbehandlung

• Stoppen Sie und melden Sie Fehler, wenn codex --version oder ein codex exec-Befehl mit einem Nicht-Null-Code beendet wird; fordern Sie vor einem erneuten Versuch eine Anweisung an.
• Fragen Sie den Benutzer vor der Verwendung von wirkungsstarken Flags (--full-auto, --sandbox danger-full-access, --skip-git-repo-check) mit AskUserQuestion um Erlaubnis, es sei denn, diese wurde bereits erteilt.
• Wenn die Ausgabe Warnungen oder Teilergebnisse enthält, fassen Sie diese zusammen und fragen Sie mit AskUserQuestion, wie angepasst werden soll.