concava/skills

Guide de la compétence 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 aucune préférence, utilisez par défaut gpt-6-astra avec high.
   • Modèle — défaut gpt-6-astra :
     • GPT-6 : gpt-6-astra (frontière / le plus capable — défaut)
     • GPT-5.6 : gpt-5.6-sol (cheval de bataille agentique fiable), gpt-5.6-terra (équilibré, quotidien), gpt-5.6-luna (rapide et économique)
     • Anciens (conservés pour compatibilité) : gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, gpt-5.3-codex
   • Effort de raisonnement — 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 est limité à max) ; les anciens modèles sont limités à xhigh.
     • ultra = raisonnement maximal avec délégation automatique de tâches (le plus lent et le plus coûteux — 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 l'utilisateur.
2. Sélectionnez le mode sandbox 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 prompt ici" (comme dernier argument positionnel)
4. Utilisez toujours --skip-git-repo-check.
5. Lorsque vous reprenez une session précédente, utilisez codex exec --skip-git-repo-check resume --last via stdin. Lors de la reprise, n'utilisez aucun flag 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). Syntaxe de reprise : echo "votre prompt ici" | codex exec --skip-git-repo-check resume --last 2>/dev/null. Tous les flags 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 tokens de réflexion (stderr). N'affichez stderr que si l'utilisateur demande explicitement à voir les tokens de réflexion ou si un débogage est nécessaire.
7. IMPORTANT (stdin) : codex exec lit toujours stdin et le concatène avec le prompt positionnel — même lorsque le prompt est entièrement fourni comme argument positionnel. Si stdin n'est pas fermé, codex bloque indéfiniment. Lors de l'appel depuis un environnement d'exécution (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 en sortie standard, zéro CPU accumulé, processus semblant bloqué indéfiniment.
8. Exécutez la commande, capturez stdout/stderr (filtrés comme approprié) et résumez le résultat pour l'utilisateur.
9. Une fois Codex terminé, 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. »

Aide-mémoire

Cas d'utilisation	Mode sandbox	Flags 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'original	`echo "prompt"
Exécuter depuis un autre répertoire	Correspondre aux besoins de la tâche	-C <DIR> plus autres flags 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 préférée : exécution 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, transmettez le nouveau prompt via stdin : echo "nouveau prompt" | codex exec resume --last 2>/dev/null. La session reprise utilise automatiquement le même modèle, effort de raisonnement et mode sandbox que la session d'origine.
• Récapitulez le modèle choisi, l'effort de raisonnement et le mode sandbox lorsque vous proposez des actions de suivi.

Évaluation critique de la sortie de Codex

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

Directives

• Faites confiance à vos propres connaissances lorsque vous êtes confiant. Si Codex affirme quelque chose que vous savez être incorrect, contestez directement.
• Recherchez les désaccords à l'aide de WebSearch ou de 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 connaissance — 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 changements d'API
  • Les meilleures pratiques qui peuvent avoir évolué

Lorsque Codex a tort

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

   echo "C'est Claude (<nom de votre modèle actuel>) qui assure le suivi. Je ne suis pas d'accord avec [X] car [preuves]. Que pensez-vous de ceci ?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
   

4. Cadrez les désaccords comme des discussions, pas des corrections — l'une ou l'autre IA pourrait avoir tort
5. Laissez l'utilisateur décider de la marche à suivre 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 non nul ; demandez une direction avant de réessayer.
• Avant d'utiliser des flags à fort impact (--full-auto, --sandbox danger-full-access, --skip-git-repo-check), demandez l'autorisation à l'utilisateur avec AskUserQuestion, sauf si elle a déjà été donnée.
• Lorsque la sortie contient des avertissements ou des résultats partiels, résumez-les et demandez comment ajuster à l'aide de AskUserQuestion.