scasella/claude-dynamic-workflows-codex

Workflows Codex

Exécute un script de workflow dynamique (dynamic-workflow) de Claude Code sur un serveur d'application Codex local. La surface de rédaction est identique à celle des workflows dynamiques natifs — export const meta plus un corps utilisant agent(), parallel(), pipeline(), phase(), log(), args, budget, workflow() — mais chaque appel à agent() s'exécute comme un thread+tour Codex (GPT) au lieu d'un sous-agent Claude.

Invocation manuelle uniquement. Claude ne déclenche pas automatiquement ce skill (disable-model-invocation: true) ; il ne s'exécute que lorsque l'utilisateur tape /codex-workflows ou demande explicitement un workflow Codex. Une fois invoqué, suivez la boucle ci-dessous — le travail s'exécute sur des agents Codex/GPT. Si l'utilisateur voulait en fait des sous-agents Claude, dites-le et orientez-le vers l'outil Workflow natif.

RUNNER ci-dessous désigne le répertoire d'exécution fourni : runner/ par rapport au répertoire de base de ce skill (affiché lorsque le skill se charge). Pour une installation classique dans un répertoire de skills, c'est ~/.claude/skills/codex-workflows/runner — les chemins littéraux dans les exemples ci-dessous le supposent ; remplacez par votre répertoire de base si ce skill est installé en tant que plugin. Il est sans dépendance et nécessite Node ≥ 18.

Mode d'intention approximative par défaut

Une ou deux phrases approximatives suffisent. Vous n'avez pas besoin de fournir à ce skill une spécification entièrement élaborée — décrivez ce que vous voulez (par ex. /codex-workflows Renforce cet objectif avant de l'exécuter) et le skill le compile lui-même en un harnais opérationnel : il classifie le travail, choisit l'échelle de travail la plus petite possible, un archétype et un motif de harnais, construit un contrat de tâche, compose des phases, distribue des personnages, applique les normes de qualité/épistémiques, rédige le script, choisit des paramètres d'exécution sûrs et l'exécute — en énonçant ses hypothèses au fur et à mesure.

Règles de fonctionnement dans ce mode :

• L'intention approximative est le contrat. Faites des hypothèses raisonnables pour tout ce qui n'est pas spécifié et énoncez-les ; n'interrogez pas l'utilisateur avec des questions de suivi.
• Choisissez le harnais utile le plus petit, pas le plus grand possible (voir la Règle anti-surcharge).
• N'émettez pas une invite géante que l'utilisateur doit recopier. Compilez et passez à la rédaction/exécution. (La seule exception est le mode prompt-only — voir Détection de mode.)
• Cela remplace tout "métaprompt" externe : l'expansion se produit désormais à l'intérieur du skill. Toute la section Compilation d'une intention approximative en un workflow ci-dessous est ce compilateur.

Liste de contrôle d'exécution par défaut

Chaque exécution, dans l'ordre (les sections ci-dessous développent chaque étape) :

1. Pré-vol Codex une fois (handshake.js) ; notez le modèle frontalier le plus récent.
2. Compilez l'intention approximative : classifiez le travail → échelle → archétype → motif (nommez le mode de défaillance qu'il évite) → contrat de tâche. Énoncez vos hypothèses.
3. Rédigez le script dans le dépôt (./<nom>.workflow.js).
4. Paramètres : --frontier · effort par échelle (--effort medium pour un quick_harness, --auto-effort pour standard/deep) · --sandbox read-only sauf s'il doit écrire · un --budget limité · des schémas stricts (additionalProperties:false).
5. Dimensionnez-le — exécutez --plan d'abord pour tout workflow coûteux ou complexe.
6. Exécutez sur le runner Codex (jamais l'outil Workflow natif).
7. Restituez — carte ASCII en ligne + points saillants summarize-run ; citez le script, le journal, le visualiseur, le rapport et les chemins du résumé d'exécution (voir Comportement de sortie).

Détection de mode

Lisez le mode à partir du phrasé de l'utilisateur, puis comportez-vous en conséquence :

Mode	Déclencheur	Comportement
par défaut (intention approximative)	1–2 phrases approximatives	Compilation interne → rédaction → exécution. Énoncez les hypothèses.
--multi (flotte)	le drapeau --multi, ou "flotte" / "plusieurs workflows à la fois"	Compilez un plan de flotte (2–4 workflows variantes concurrents, similaires et/ou divers), lancez-les en arrière-plan et supervisez : interrogez fleet status, répondez aux portes, dirigez, tuez, bifurquez, puis synthétisez. Voir Mode flotte.
prompt-only	"invite uniquement", "juste l'invocation", "ne l'exécute pas"	Émettez une invocation/spécification /codex-workflows complète (la structure A–L ci-dessous) et ARRÊTEZ — ne rédigez pas ou n'exécutez pas.
write-only	"écris-le mais ne l'exécute pas", "rédige uniquement"	Rédigez le script de workflow, imprimez son chemin, arrêtez avant l'exécution.
run-existing	un chemin de script ou un nom de workflow sauvegardé est donné	Sautez la compilation ; exécutez ce script/nom via le runner.
quick	"rapide", "petit", "bon marché"	Favorisez un quick_harness (2–5 agents).
deep	"profond", "approfondi", "exhaustif"	Autorisez un deep_harness plus grand ; justifiez la taille.
no-write	"n'écris pas de fichiers", "dis-moi juste"	Retournez uniquement le JSON/Markdown final ; pas de fichiers de rapport/source ; --sandbox read-only.

Deux règles de précédence : si l'utilisateur donne un chemin de script ou un nom sauvegardé, exécutez-le (ne recompilez pas). Si l'utilisateur donne une spécification détaillée, respectez-la telle quelle mais appliquez toujours les valeurs par défaut de sécurité et d'exécution ci-dessous. Sinon, c'est une intention approximative → compilation.

En mode prompt-only, l'invocation que vous émettez suit la même structure A–L que le skill construit en interne : A nom · B objectif · C contrat de tâche · D entrées / reconstruction du contexte · E phases · F personnages · G normes anti-enveloppe · H sorties · I paramètres d'exécution · J sécurité / épistémique · K format de réponse finale · L industrialisation. Puis arrêtez — n'exécutez pas.

La boucle

En mode d'intention approximative par défaut, effectuez les étapes 1–2 silencieusement et énoncez vos hypothèses avant la rédaction. Les mécaniques ci-dessous — poignée de main, la commande d'exécution, la carte en ligne — sont inchangées ; les étapes 2 et 4 sont celles où l'intention approximative est compilée.

1. Pré-vol — une fois par session, ou chaque fois qu'une exécution ne parvient pas à se connecter, confirmez que Codex est accessible et authentifié :

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

   Il affiche state: ready et les modèles disponibles. En cas d'échec, dites à l'utilisateur d'exécuter codex login (le runner a besoin d'une CLI codex connectée sur le PATH). À partir de cette liste, notez le modèle frontalier le plus récent — le modèle général phare le plus récent (pas une variante -mini/-spark ; model/list le marque isDefault et sa description le qualifie de plus puissant). La série Codex GPT-5.6 est Sol (phare), Terra (équilibré) et Luna (efficient) ; aujourd'hui, le modèle frontalier est gpt-5.6-sol. Chaque agent de l'exécution l'utilise (voir Modèle).

2. Compilez l'intention approximative en un workflow (voir Compiler une intention approximative en un workflow) : classifiez le travail → choisissez l'échelle → choisissez l'archétype → choisissez le motif et nommez le mode de défaillance qu'il évite → construisez le contrat de tâche → composez les phases → distribuez les personnages → appliquez les normes. Énoncez les hypothèses résultantes à l'utilisateur avant la rédaction.

3. Rédigez un script de workflow à partir de cette compilation (voir Rédaction). Écrivez-le dans le projet de l'utilisateur afin qu'il puisse le lire et le réexécuter — ./<nom>.workflow.js, ou workflows/<nom>.workflow.js / examples/harness-zoo/<nom>/ pour un harnais réutilisable. Les scripts sont en JavaScript simple utilisant uniquement les globales injectées (pas d'imports).

4. Choisissez les paramètres d'exécution (voir Valeurs par défaut d'exécution) : --frontier, le drapeau d'effort pour l'échelle choisie (--auto-effort pour un harnais standard/profond, --effort medium pour un harnais rapide), un sandbox en lecture seule sauf si l'exécution doit écrire, et un --budget limité. Pour un workflow coûteux ou complexe, exécutez --plan d'abord — un essai à blanc sans jeton qui compte les agents par phase/effort et estime un --budget.

5. Exécutez-le — passez toujours --frontier, plus le drapeau d'effort pour l'échelle choisie : --auto-effort pour un harnais standard/profond (il adapte l'effort de chaque agent à la largeur parallèle de sa couche, de sorte que les portes de synthèse/jugement solitaires réfléchissent le plus), ou --effort medium pour un harnais rapide (voir Effort). --frontier verrouille chaque agent sur le modèle frontalier le plus récent (voir Modèle) :

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

   La progression est diffusée sur stderr ; la valeur de retour du workflow est imprimée en JSON sur stdout. Capturez stdout pour le résultat (… 1>/tmp/result.json) lorsqu'il est volumineux. Pour regarder l'exécution en direct, ajoutez --tui (carte ASCII en direct dans une nouvelle fenêtre de terminal) et/ou --gui (visualiseur HTML en direct dans le navigateur) — voir Exécution → Surveillance en direct.

6. Restituez le résultat à l'utilisateur (voir Comportement de sortie) — résumez-le, mentionnez le chemin du script, et affichez la carte ASCII de l'exécution en ligne dans cette conversation afin qu'il voie le graphe d'exécution nativement (pas de fenêtre à ouvrir) :

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

   (<journal> est le chemin que l'exécution a enregistré comme ✎ journal: …, par défaut .workflow-journal/<nom>.jsonl.) Collez cette sortie dans votre réponse à l'intérieur d'un bloc ```text — c'est l'orchestrateur → les couches de phases → la grille d'agents → le DAG des résultats avec le modèle/effort/jetons/temps par agent et un extrait de résultat d'une ligne par agent. Utilisez toujours --no-color en ligne (les ANSI bruts s'afficheraient comme des déchets dans le chat). Pour une surveillance en direct et en session, exécutez le workflow avec run_in_background et réaffichez cet instantané plusieurs fois pendant qu'il est en cours (les agents en cours d'exécution s'affichent comme ⠋ … en cours…) ; pour une fenêtre en direct plus fluide à la place, ajoutez --tui/--gui (voir Exécution → Surveillance en direct).

   L'exécution imprime également un récapitulatif coût/fiabilité d'une ligne lorsqu'elle se termine. Pour une ventilation plus détaillée — jetons par phase, les agents les plus coûteux/les plus lents, et tout signal d'alarme (nombreuses valeurs nulles, un énorme déploiement non préparé, un coût d'effort par défaut) — exécutez summarize-run sur le journal et incorporez les points saillants dans votre réponse (voir Résumer une exécution).

N'UTILISEZ PAS l'outil Workflow natif pendant que vous utilisez ce skill. Rédiger le script et l'exécuter via le CLI ci-dessus est exactement ce qui achemine le travail vers Codex ; invoquer l'outil natif générerait des sous-agents Claude à la place.

Mode flotte (--multi) : lancer, superviser, diriger

Lorsque l'utilisateur passe --multi (ou demande une flotte / plusieurs workflows à la fois), vous êtes l'opérateur de N exécutions concurrentes — pas un lanceur "fire-and-forget". Vous compilez un plan de flotte, lancez chaque variante en arrière-plan, puis exécutez une boucle de supervision : interrogez l'état, répondez aux portes, dirigez les travailleurs qui dérivent, tuez les impasses, bifurquez vers des pistes prometteuses et synthétisez à la fin. L'humain définit la politique une fois (objectif, budget total, tolérance au risque) ; vous prenez les décisions en cours d'exécution que les variantes ne peuvent pas prendre elles-mêmes.

1 · Compilez le plan de flotte

Décomposez l'intention en 2 à 4 variantes et énoncez le plan (variantes, ce que chacune parie, budgets par exécution) avant de lancer. Deux axes, librement mélangés :

• Similaires — le même harnais, différentes tranches : divisez une grande entrée sur plusieurs exécutions via --args, ou attaquez la même question à partir de différentes hypothèses/graines de départ. Un script + des --args par exécution + --run-id (afin que les journaux n'entrent pas en collision), ou N copies du script.
• Diverses — des formes de harnais différentes pariant sur différentes théories de la tâche : par exemple, une chasse aux bugs loop_until_dry vs un balayage adversarial_verification vs une investigation sessionful_controller_loop, tous visant le même objectif. Un script par variante.

Divisez le budget global de l'utilisateur entre les variantes (l'état montre la dépense de chaque exécution par rapport à son plafond). Dimensionnez les déploiements à forte lecture de manière réaliste en utilisant les mesures existantes de GPT-5.5 : un agent dont le travail consiste à lire un dépôt/corpus coûte ~400–600k jetons, quel que soit son niveau d'effort — l'entrée domine, donc --effort low ne rend pas un balayage bon marché, et l'estimation par effort de --plan le sous-estime (mesuré : quatre balayages "low" = 2,1 M, 525k chacun, contre une estimation de plan de 150k/agent). À xhigh — que --auto-effort donne à chaque tour de travailleur sessionnel (largeur 1) — un tour de lecture coûte ~1–1,5 M (mesuré : le premier tour d'un travailleur de parcours + une direction a déclenché un plafond de 2,5 M). Budget ≈ lecteurs × 500k + tours de lecture xhigh × 1,2 M + non-lecteurs × l'estimation du plan, avec une marge. Un plafond atteint est récupérable (--resume rejoue le préfixe gratuitement) mais coûte un aller-retour de supervision. Appliquez la Règle anti-surcharge à la flotte aussi : 2 variantes bien différenciées valent mieux que 4 variantes redondantes — chaque variante doit parier sur quelque chose que les autres ne font pas.

2 · Rédigez pour la supervision

Chaque variante reçoit des points de contrôle de supervision — des portes human() aux jonctions où un jugement externe peut rediriger l'exécution :

const directive = await human(
  `Tour ${round} résultats : ${summary}. Directive pour le prochain tour ?`,
  { id: `round${round}`, choices: ["continue", "stop"], default: "continue", timeoutMs: 240_000 })
if (directive === "stop") break
if (directive !== "continue") await worker.steer(directive)   // texte libre = une direction

C'est le canal de direction : une réponse en texte libre est la directive, et le script l'applique (session.steer(...), réorientant le tour suivant, réduisant la portée). Placez les portes entre les tours, avant les phases coûteuses et en cas d'incertitude. Les valeurs par défaut doivent être sûres — une porte sans réponse expire vers sa valeur par défaut et l'exécution se dégrade sans intervention, ne bloque jamais. (Cela utilise le canal human() journalisé, donc un --resume rejoue les réponses au lieu de redemander.)

3 · Lancez — un répertoire par flotte, chaque exécution en arrière-plan

Les variantes partagent un répertoire (c'est ce que fleet status <dir> supervise). Lancez chacune avec run_in_background, toujours avec --interactive (il active le canal de réponse sans tête) :

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
# même script, tranche différente → isolez avec --run-id :
node …/run-workflow.js hunt.workflow.js --args '{"slice":"auth"}' --run-id auth --interactive …

4 · Supervisez — la boucle

Interrogez le digest de la flotte entre autres travaux (et rapidement lorsque des portes peuvent être en attente —

…

[section tronquée pour la traduction]