skills-directory/codex

Guide du skill Codex

Exécution d'une tâche

1. Pour une nouvelle session (les reprises héritent du modèle/effort précédent — voir étape 5), demandez à l'utilisateur (via AskUserQuestion) quel modèle ET quel effort de raisonnement utiliser, dans une seule invite avec deux questions. Lorsque l'utilisateur n'exprime pas de préférence, utilisez par défaut gpt-6-astra à high.
   • Modèle — par défaut gpt-6-astra :
     • GPT-6: gpt-6-astra (frontière / le plus capable — par défaut)
     • GPT-5.6: gpt-5.6-sol (cheval de bataille agentif fiable), gpt-5.6-terra (équilibré, quotidien), gpt-5.6-luna (rapide et abordable)
     • Legacy (conservé pour compatibilité) : gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, gpt-5.3-codex
   • Effort de raisonnement — par défaut high : low, medium, high, xhigh, max, ultra.
     • max/ultra nécessitent un modèle GPT-6 ou GPT-5.6 ; ultra est uniquement sur astra/sol/terra (luna plafonne à max) ; les modèles legacy plafonnent à xhigh.
     • ultra = raisonnement maximal avec délégation automatique de tâches (le plus lent et le plus cher — réservez-le pour les tâches les plus difficiles).
     • Si l'effort choisi dépasse le maximum du modèle sélectionné, revenez à l'effort le plus élevé pris en charge par ce modèle et informez-en l'utilisateur.
2. Sélectionnez le mode bac à sable requis pour la tâche ; utilisez par défaut --sandbox read-only sauf si des modifications ou un accès réseau sont nécessaires.
3. Assemblez la commande avec les options appropriées :
   • -m, --model <MODEL>
   • --config model_reasoning_effort="<low|medium|high|xhigh|max|ultra>" (max/ultra uniquement sur les modèles GPT-6 / GPT-5.6 ; ultra uniquement sur astra/sol/terra — voir étape 1)
   • --sandbox <read-only|workspace-write|danger-full-access>
   • --full-auto
   • -C, --cd <DIR>
   • --skip-git-repo-check
   • "votre invite ici" (comme argument positionnel final)
4. Utilisez toujours --skip-git-repo-check.
5. Lorsque vous poursuivez une session précédente, utilisez codex exec --skip-git-repo-check resume --last via stdin. Lors de la reprise, n'utilisez aucun indicateur de configuration sauf demande explicite de l'utilisateur, par exemple s'il spécifie le modèle ou l'effort de raisonnement lors de la demande de reprise d'une session. Syntaxe de reprise : echo "votre invite ici" | codex exec --skip-git-repo-check resume --last 2>/dev/null. Tous les indicateurs doivent être insérés entre exec et resume.
6. IMPORTANT : Par défaut, ajoutez 2>/dev/null à toutes les commandes codex exec pour supprimer les jetons de réflexion (stderr). N'affichez stderr que si l'utilisateur demande explicitement à voir les jetons de réflexion ou si un débogage est nécessaire.
7. IMPORTANT (stdin) : codex exec lit toujours stdin et le concatène avec l'invite positionnelle — même lorsque l'invite est entièrement fournie comme argument positionnel. Si stdin n'est pas fermé, codex se bloque indéfiniment. Lors de l'invocation depuis un harnais (tâches d'arrière-plan, hooks, scripts où stdin n'est pas un TTY mais n'est pas non plus fermé), redirigez explicitement stdin : ajoutez </dev/null à la commande, par exemple codex exec ... "prompt" </dev/null 2>/dev/null. Symptôme de cette erreur : zéro octet de sortie standard, zéro CPU accumulé, le processus semble bloqué indéfiniment.
8. Exécutez la commande, capturez stdout/stderr (filtré si approprié) et résumez le résultat pour l'utilisateur.
9. Après la fin de Codex, informez l'utilisateur : "Vous pouvez reprendre cette session Codex à tout moment en disant 'codex resume' ou en me demandant de continuer avec des analyses ou modifications supplémentaires."

Référence rapide

Cas d'utilisation	Mode bac à sable	Indicateurs clés
Révision ou analyse en lecture seule	read-only	--sandbox read-only 2>/dev/null
Appliquer des modifications locales	workspace-write	--sandbox workspace-write --full-auto 2>/dev/null
Permettre l'accès réseau ou large	danger-full-access	--sandbox danger-full-access --full-auto 2>/dev/null
Reprendre une session récente	Hérité de l'originale	echo "prompt" | codex exec --skip-git-repo-check resume --last 2>/dev/null (aucun indicateur autorisé)
Exécuter depuis un autre répertoire	Correspondre aux besoins de la tâche	-C <DIR> plus autres indicateurs 2>/dev/null

Délais d'exécution

Codex ne produit aucune sortie intermédiaire — il écrit le résultat uniquement à la fin. Si le processus est tué avant la fin, le fichier de sortie est silencieusement vide (aucune erreur).

Approche privilégiée : exécuter de manière synchrone — élimine complètement le risque de délai d'attente et la conversation attend de toute façon le résultat.

Si exécuté en arrière-plan, définissez le délai d'exécution en fonction de l'effort de raisonnement :

Effort de raisonnement	Délai d'attente
low	150s
medium	300s
high	600s
xhigh	1200s
max	1800s
ultra	1800s

Suivi

• Après chaque commande codex, utilisez immédiatement AskUserQuestion pour confirmer les prochaines étapes, recueillir des clarifications ou décider de reprendre avec codex exec resume --last.
• Lors de la reprise, pipez la nouvelle invite via stdin : echo "nouvelle invite" | codex exec resume --last 2>/dev/null. La session reprise utilise automatiquement le même modèle, le même effort de raisonnement et le même mode bac à sable que la session d'origine.
• Réitérez le modèle, l'effort de raisonnement et le mode bac à sable choisis lors de la proposition d'actions de suivi.

Évaluation critique de la sortie Codex

Codex est propulsé par des modèles OpenAI avec leurs propres dates de coupure et limitations. Traitez Codex comme un collègue, pas comme une autorité.

Directives

• Faites confiance à vos propres connaissances lorsque vous êtes sûr. Si Codex affirme quelque chose que vous savez être incorrect, contestez-le directement.
• Recherchez les désaccords en utilisant WebSearch ou la documentation avant d'accepter les affirmations de Codex. Partagez les résultats avec Codex via une reprise si nécessaire.
• Souvenez-vous des dates de coupure - Codex peut ne pas connaître les versions récentes, les API ou les changements survenus après ses données d'entraînement.
• Ne vous fiez pas aveuglément - Codex peut se tromper. Évaluez ses suggestions de manière critique, en particulier concernant :
  • Les noms et capacités des modèles
  • Les versions récentes de bibliothèques ou les modifications d'API
  • Les meilleures pratiques qui ont pu évoluer

Quand Codex se trompe

1. Exposez clairement votre désaccord à l'utilisateur
2. Fournissez des preuves (vos propres connaissances, recherche web, documentation)
3. Optionnellement, reprenez la session Codex pour discuter du désaccord. Identifiez-vous comme Claude afin que Codex sache qu'il s'agit d'une discussion IA entre pairs. Utilisez votre nom de modèle réel (par exemple, le modèle sous lequel vous exécutez actuellement) au lieu d'un nom codé en dur :

   echo "Ici Claude (<votre nom de modèle actuel>) qui fait un suivi. Je ne suis pas d'accord avec [X] parce que [preuve]. Quel est votre avis là-dessus ?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
   

4. Présentez les désaccords comme des discussions, pas des corrections — l'une ou l'autre IA pourrait avoir tort
5. Laissez l'utilisateur décider comment procéder en cas d'ambiguïté réelle

Gestion des erreurs

• Arrêtez-vous et signalez les échecs chaque fois que codex --version ou une commande codex exec se termine avec un code de sortie non nul ; demandez une orientation avant de réessayer.
• Avant d'utiliser des indicateurs à fort impact (--full-auto, --sandbox danger-full-access, --skip-git-repo-check), demandez l'autorisation à l'utilisateur en utilisant AskUserQuestion, sauf si elle a déjà été donnée.
• Lorsque la sortie inclut des avertissements ou des résultats partiels, résumez-les et demandez comment ajuster en utilisant AskUserQuestion.