scasella/claude-dynamic-workflows-codex

Codex Workflows

Führt ein Claude Code dynamisches Workflow-Skript gegen einen lokalen Codex App Server aus. Die Autorenoberfläche ist identisch mit nativen dynamischen Workflows — export const meta plus ein Rumpf mit agent(), parallel(), pipeline(), phase(), log(), args, budget, workflow() — aber jeder agent()-Aufruf läuft als ein Codex (GPT)-Thread+Turn anstelle eines Claude-Subagenten.

Nur manuelle Aufrufe. Claude löst dieses Skill nicht automatisch aus (disable-model-invocation: true); es läuft nur, wenn der Benutzer /codex-workflows eingibt oder explizit nach einem Codex-Workflow fragt. Nach dem Aufruf folgen Sie der unten stehenden Schleife — die Arbeit läuft auf Codex/GPT-Agenten. Wenn der Benutzer eigentlich Claude-Subagenten wollte, sagen Sie dies und verweisen Sie auf das native Workflow-Tool.

RUNNER unten bezeichnet das gebündelte Runner-Verzeichnis: runner/ relativ zum Basisverzeichnis dieses Skills (wird beim Laden des Skills angezeigt). Für eine klassische Skills-Dir-Installation ist dies ~/.claude/skills/codex-workflows/runner — die literarischen Pfade in den unten stehenden Beispielen gehen davon aus; ersetzen Sie Ihr Basisverzeichnis, wenn dieses Skill als Plugin installiert ist. Es ist abhängigkeitsfrei und benötigt Node ≥ 18.

Standard-Rough-Intent-Modus

Ein oder zwei grobe Sätze reichen aus. Sie müssen diesem Skill keine vollständig ausgearbeitete Spezifikation übergeben — beschreiben Sie, was Sie möchten (z.B. /codex-workflows Härte dieses Ziel, bevor ich es ausführe) und das Skill kompiliert selbstständig einen betriebsfähigen Workflow: es klassifiziert die Aufgabe, wählt den kleinsten sinnvollen Maßstab, ein Archetyp und ein Workflow-Muster, erstellt einen Aufgabenvertrag, setzt Phasen zusammen, besetzt Personas, wendet die Qualitäts-/Epistemikstandards an, schreibt das Skript, wählt sichere Ausführungseinstellungen und führt es aus — wobei es seine Annahmen während des Prozesses nennt.

Betriebsregeln in diesem Modus:

• Die grobe Absicht ist der Vertrag. Treffen Sie angemessene Annahmen für alles, was nicht spezifiziert ist, und nennen Sie sie; befragen Sie den Benutzer nicht mit Rückfragen.
• Wählen Sie den kleinsten sinnvollen Workflow, nicht den größtmöglichen (siehe die Anti-Überbau-Regel).
• Geben Sie keinen riesigen Prompt aus, den der Benutzer wieder einfügen müsste. Kompilieren Sie und fahren Sie mit der Autorenerstellung/Ausführung fort. (Die einzige Ausnahme ist der prompt-only-Modus — siehe Moduserkennung.)
• Dieses ersetzt jedes externe "Metaprompt": die Erweiterung erfolgt jetzt innerhalb des Skills. Der gesamte Abschnitt Kompilieren grober Absicht in einen Workflow unten ist dieser Compiler.

Standard-Ausführungs-Checkliste

Jede Ausführung, in der Reihenfolge (die Abschnitte unten erweitern jeden Schritt):

1. Preflight Codex einmal (handshake.js); notieren Sie das neueste Frontier-Modell.
2. Kompilieren Sie die grobe Absicht: Klassifizieren Sie die Aufgabe → Maßstab → Archetyp → Muster (nennen Sie den Fehlermodus, den es verhindert) → Aufgabenvertrag. Nennen Sie Ihre Annahmen.
3. Erstellen Sie das Skript im Repository (./<name>.workflow.js).
4. Einstellungen: --frontier · Aufwand nach Maßstab (--effort medium für einen quick_harness, --auto-effort für standard/deep) · --sandbox read-only, es sei denn, es muss schreiben · ein limitiertes --budget · strenge Schemata (additionalProperties:false).
5. Bemessen Sie es — führen Sie zuerst --plan für jeden teuren oder komplexen Workflow aus.
6. Ausführen auf dem Codex-Runner (niemals das native Workflow-Tool).
7. Präsentieren — Inline-ASCII-Karte + summarize-run-Highlights; nennen Sie das Skript, Journal, Viewer, Bericht und Run-Summary-Pfade (siehe Ausgabeverhalten).

Moduserkennung

Lesen Sie den Modus aus der Formulierung des Benutzers und verhalten Sie sich entsprechend:

Modus	Auslöser	Verhalten
Standard (grobe Absicht)	1–2 grobe Sätze	Intern kompilieren → erstellen → ausführen. Annahmen nennen.
--multi (Flotte)	das --multi-Flag, oder "Flotte" / "mehrere Workflows gleichzeitig"	Erstellen Sie einen Flottenplan (2–4 gleichzeitige Varianten-Workflows, ähnlich und/oder verschieden), starten Sie sie im Hintergrund, und überwachen Sie: Pollen Sie fleet status, beantworten Sie Tore, steuern Sie, beenden Sie, gabeln Sie, und synthetisieren Sie dann. Siehe Flottenmodus.
prompt-only	"prompt-only", "nur der Aufruf", "nicht ausführen"	Geben Sie einen vollständigen /codex-workflows-Aufruf/die Spezifikation aus (die A–L-Struktur unten) und STOPPEN SIE — erstellen oder führen Sie nicht aus.
write-only	"schreiben, aber nicht ausführen", "nur erstellen"	Erstellen Sie das Workflow-Skript, geben Sie seinen Pfad aus, stoppen Sie vor der Ausführung.
run-existing	ein Skriptpfad oder ein gespeicherter Workflow-Name wird angegeben	Überspringen Sie die Kompilierung; führen Sie dieses Skript/den Namen über den Runner aus.
quick	"schnell", "klein", "günstig"	Neigen Sie zu einem quick_harness (2–5 Agenten).
deep	"tief", "gründlich", "erschöpfend"	Erlauben Sie einen größeren / deep_harness; begründen Sie die Größe.
no-write	"keine Dateien schreiben", "sag es mir einfach"	Geben Sie nur finales JSON/Markdown zurück; keine Berichts-/Quelldateien; --sandbox read-only.

Zwei Vorrangregeln: Wenn der Benutzer einen Skriptpfad oder gespeicherten Namen angibt, führen Sie ihn aus (nicht neu kompilieren). Wenn der Benutzer eine detaillierte Spezifikation angibt, befolgen Sie diese wie geschrieben, wenden Sie aber dennoch die Sicherheits- + Ausführungsstandards unten an. Andernfalls handelt es sich um grobe Absicht → kompilieren.

Im prompt-only-Modus folgt der von Ihnen ausgegebene Aufruf derselben A–L-Struktur, die das Skill intern aufbaut: A Name · B Zweck · C Aufgabenvertrag · D Eingaben / Kontext-Rekonstruktion · E Phasen · F Personas · G Anti-Wrapper- Standards · H Ausgaben · I Ausführungseinstellungen · J Sicherheit / Epistemologie · K Format der endgültigen Antwort · L Produktivierung. Dann stoppen — nicht ausführen.

Die Schleife

Im Standard-Rough-Intent-Modus führen Sie die Schritte 1–2 still aus und nennen Ihre Annahmen, bevor Sie das Skript erstellen. Die Mechanismen unten — Handshake, der Run-Befehl, die Inline-Karte — sind unverändert; die Schritte 2 und 4 sind die, in denen die grobe Absicht kompiliert wird.

1. Preflight — einmal pro Sitzung, oder immer dann, wenn eine Verbindung fehlschlägt, bestätigen Sie, dass Codex erreichbar und authentifiziert ist:

   node ~/.claude/skills/codex-workflows/runner/test/handshake.js
   

   Es gibt state: ready und die verfügbaren Modelle aus. Wenn es fehlschlägt, sagen Sie dem Benutzer, codex login auszuführen (der Runner benötigt ein eingeloggtes codex CLI im PATH). Notieren Sie aus dieser Liste das neueste Frontier-Modell — das neueste Flaggschiff- Allzweck-Modell (keine -mini/-spark-Variante; model/list kennzeichnet es als isDefault und seine Beschreibung nennt es das stärkste). Die GPT-5.6-Codex-Reihe ist Sol (Flaggschiff), Terra (ausgewogen) und Luna (effizient); heute ist das Frontier gpt-5.6-sol. Jeder Agent im Run verwendet es (siehe Modell).

2. Kompilieren Sie die grobe Absicht in einen Workflow (siehe Kompilieren grober Absicht in einen Workflow): Klassifizieren Sie die Aufgabe → wählen Sie den Maßstab → wählen Sie den Archetyp → wählen Sie das Muster und nennen Sie den Fehlermodus, den es verhindert → erstellen Sie den Aufgabenvertrag → setzen Sie die Phasen zusammen → besetzen Sie die Personas → wenden Sie die Standards an. Nennen Sie die resultierenden Annahmen dem Benutzer, bevor Sie das Skript erstellen.

3. Erstellen Sie ein Workflow-Skript aus dieser Kompilierung (siehe Erstellung). Schreiben Sie es in das Projekt des Benutzers, damit sie es lesen und erneut ausführen können — ./<name>.workflow.js, oder workflows/<name>.workflow.js / examples/harness-zoo/<name>/ für einen wiederverwendbaren Workflow. Skripte sind einfaches JavaScript, das nur die injizierten Globals verwendet (keine Importe).

4. Wählen Sie Ausführungseinstellungen (siehe Ausführungsstandards): --frontier, das Aufwands-Flag für den gewählten Maßstab (--auto-effort für einen Standard-/Deep-Workflow, --effort medium für einen schnellen), eine schreibgeschützte Sandbox, es sei denn, der Run muss schreiben, und ein limitiertes --budget. Für einen teuren oder komplexen Workflow zuerst --plan — ein Token-freier Probelauf, der die Anzahl der Agenten pro Phase/Aufwand zählt und ein --budget schätzt.

5. Ausführen — übergeben Sie immer --frontier, plus das Aufwands-Flag für den gewählten Maßstab: --auto-effort für einen Standard-/Deep-Workflow (es skaliert den Aufwand jedes Agenten auf die parallele Breite seiner Schicht, sodass einsame Synthese-/Beurteilungstore am härtesten denken) oder --effort medium für einen schnellen Workflow (siehe Aufwand). --frontier setzt jeden Agenten auf das neueste Frontier-Modell (siehe Modell):

   node ~/.claude/skills/codex-workflows/runner/bin/run-workflow.js <script.js> --frontier --auto-effort [andere Flags]
   #   quick_harness:  … <script.js> --frontier --effort medium [andere Flags]
   

   Der Fortschritt streamt auf stderr; der Rückgabewert des Workflows wird als JSON auf stdout ausgegeben. Erfassen Sie stdout für das Ergebnis (… 1>/tmp/result.json), wenn es groß ist. Um den Run live zu sehen, fügen Sie --tui hinzu (Live-ASCII-Karte in einem neuen Terminalfenster) und/oder --gui (Live-HTML-Viewer im Browser) — siehe Ausführen → Live-Überwachung.

6. Präsentieren Sie das Ergebnis dem Benutzer (siehe Ausgabeverhalten) — fassen Sie es zusammen, erwähnen Sie den Skriptpfad, und geben Sie die ASCII-Karte des Runs inline in dieser Konversation aus, sodass der Benutzer den Ausführungsgraphen nativ sieht (kein zu öffnendes Fenster):

   node ~/.claude/skills/codex-workflows/runner/bin/map-run.js --journal <journal> --no-color
   

   (<journal> ist der Pfad, den der Run als ✎ journal: … protokolliert hat, Standard .workflow-journal/<name>.jsonl.) Fügen Sie diese Ausgabe in Ihre Antwort innerhalb eines ```text-Blocks ein — es ist der Orchestrator → Phasenebenen → Agentengitter → Ergebnis-DAG mit Modell/Aufwand/Tokens/Zeit pro Agent und einem einzeiligen Ergebnis-Snippet pro Agent. Verwenden Sie immer --no-color inline (rohe ANSI-Codes würden im Chat als Müll dargestellt werden). Für Live-, sitzungsinterne Überwachung führen Sie den Workflow mit run_in_background aus und rendern Sie diesen Schnappschuss einige Male, während er läuft (laufende Agenten zeigen ⠋ … läuft …); für ein flüssiges Live-Fenster stattdessen fügen Sie --tui/--gui hinzu (siehe Ausführen → Live-Überwachung).

   Der Run gibt auch eine einzeilige Kosten-/Zuverlässigkeitszusammenfassung aus, wenn er fertig ist. Für eine detailliertere Aufschlüsselung — Tokens nach Phase, die teuersten/langsamsten Agenten und alle roten Flaggen (viele Nullwerte, ein nicht gestaffelter riesiger Fan-Out, Standardaufwandskosten) — führen Sie summarize-run auf dem Journal aus und fügen Sie die Highlights in Ihre Antwort ein (siehe Zusammenfassen eines Runs).

Rufen Sie NICHT das native Workflow-Tool auf, während Sie dieses Skill verwenden. Das Erstellen des Skripts und die Ausführung über die oben genannte CLI leitet die Arbeit genau an Codex weiter; der Aufruf des nativen Tools würde stattdessen Claude-Subagenten erzeugen.

Flottenmodus (--multi): starten, überwachen, steuern

Wenn der Benutzer --multi übergibt (oder nach einer Flotte / mehreren Workflows gleichzeitig fragt), sind Sie der Operator von N gleichzeitigen Runs — kein Feuer-und-Vergessen-Starter. Sie erstellen einen Flottenplan, starten jede Variante im Hintergrund und führen dann eine Überwachungsschleife aus: Status pollen, Tore beantworten, abweichende Arbeiter steuern, Sackgassen beenden, vielversprechende Abzweigungen verfolgen und am Ende synthetisieren. Der Mensch legt die Richtlinie einmal fest (Ziel, Gesamtbudget, Risikotoleranz); Sie treffen die Zwischenentscheidungen im Run, die die Varianten nicht selbst treffen können.

1 · Erstellen Sie den Flottenplan

Zerlegen Sie die Absicht in 2–4 Varianten und nennen Sie den Plan (Varianten, worauf jede wettet, Budgets pro Run), bevor Sie starten. Zwei Achsen, frei gemischt:

• Ähnlich — der gleiche Workflow, verschiedene Ausschnitte: Teilen Sie eine große Eingabe über Runs mittels --args auf, oder greifen Sie dieselbe Frage aus verschiedenen Start- Hypothesen/Seeds an. Ein Skript + --args pro Run + --run-id (damit sich die Journale nicht überschreiben), oder N Kopien des Skripts.
• Verschieden — verschiedene Workflow-Formen, die auf unterschiedlichen Theorien der Aufgabe basieren: z.B. eine loop_until_dry-Fehlersuche vs. ein adversarial_verification-Durchlauf vs. eine sessionful_controller_loop-Untersuchung, alle auf das gleiche Ziel ausgerichtet. Ein Skript pro Variante.

Teilen Sie das Gesamtbudget des Benutzers über die Varianten auf (der Status zeigt die Ausgaben jedes Runs gegen sein Budget). Bemessen Sie leseintensive Fan-Outs realistisch anhand der vorhandenen GPT-5.5-Messungen: Ein Agent, dessen Aufgabe das Lesen eines Repositorys/Korpus ist, kostet ~400–600k Tokens, unabhängig von seiner Aufwandsstufe — die Eingabe dominiert, also macht --effort low einen Durchlauf nicht günstig, und --plan's Aufwandsschätzung unterschätzt sie gemessen: vier "niedrige" Sweeps = 2,1 Mio., 525k pro Stück, vs. einer Schätzung von 150k/Agent im Plan). Bei xhigh — das --auto-effort jedem sessionfähigen Arbeiter gibt (Breite 1) — kostet ein Lese-Turn ~1–1,5 Mio. (gemessen: erster Turn eines Walkthrough-Arbeiters + eine Steuerung löste ein 2,5-Mio.-Limit aus). Budget ≈ Leser × 500k + xhigh-Lese-Turns × 1,2 Mio. + Nicht-Leser × die Planschätzung, mit Spielraum. Ein erreichtes Limit ist behebbar (--resume spielt das Präfix erneut ab) kostet aber eine Überwachungs-Roundtrip. Wenden Sie die Anti-Überbau-Regel auch auf die Flotte an: 2 gut differenzierte Varianten schlagen 4 redundante — jede Variante muss auf etwas wetten, was die anderen nicht tun.

2 · Für Überwachung erstellen

Jede Variante erhält Überwachungs-Checkpoints — human()-Tore an den Knotenpunkten, an denen ein externes Urteil den Run umlenken kann:

const directive = await human(
  `Runde ${round}: Ergebnisse: ${summary}. Richtlinie für nächste Runde?`,
  { id: `round${round}`, choices: ["weiter", "stop"], default: "weiter", timeoutMs: 240_000 })
if (directive === "stop") break
if (directive !== "weiter") await worker.steer(directive)   // Freitext = eine Steuerung

Dies ist der Steuerkanal: eine Freitext-Antwort ist die Richtlinie, und das Skript wendet sie an (session.steer(...), Neuausrichtung der nächsten Runde, Eingrenzung des Umfangs). Platzieren Sie Tore zwischen Runden, vor teuren Phasen und bei Unsicherheit. Die Standardwerte müssen sicher sein — ein unbeantwortetes Tor läuft mit seinem Standardwert aus und der Run degradiert autark, hängt niemals. (Dies nutzt den protokollierten human()-Kanal, sodass ein --resume Antworten wiederholt, anstatt sie erneut zu erfragen.)

3 · Starten — ein Verzeichnis pro Flotte, jeder Run im Hintergrund

Varianten teilen sich ein Verzeichnis (das ist es, was fleet status <dir> überwacht). Starten Sie jeden mit run_in_background, immer mit --interactive (es ermöglicht den Antwortkanal headless):

node ~/.claude/skills/codex-workflows/runner/bin/run-workflow.js hunt-orm.workflow.js \
  --frontier --auto-effort --interactive --budget 1500000 1>hunt-orm.result.json
# gleiches Skript, anderer Ausschnitt → mit --run-id isolieren:
node …/run-workflow.js hunt.workflow.js --args '{"slice":"auth"}' --run-id auth --interactive …

4 · Überwachen — die Schleife

Pollen Sie die Flottenzusammenfassung zwischen anderen Arbeiten (und zeitnah, während Tore möglicherweise anhängig sind…

[gekürzt für die Übersetzung]