Introduction

Utilisez /goal pour que Codex poursuive un même objectif dans la durée, au-delà d’un échange ordinaire. Cette commande convient aux tâches dont le résultat attendu est clair, pour lesquelles Codex peut vérifier ses progrès à chaque étape et avancer sans que vous ayez à le guider. Avec /goal, Codex peut travailler en autonomie pendant plusieurs heures sans intervention de votre part.

Définissez un objectif avec /goal <objective>, consultez l’objectif en cours avec /goal et utilisez /goal pause, /goal resume ou /goal clear pour agir sur son exécution.

Si /goal ne figure pas dans la liste des commandes slash, activez features.goals dans config.toml :

[features]
goals = true

Vous pouvez aussi exécuter codex features enable goals dans la CLI ou demander à Codex de le faire.

Choisissez une tâche adaptée

Un bon objectif dépasse ce qu’un seul prompt permet d’accomplir, mais reste plus circonscrit qu’une liste de tâches qui peut s’allonger indéfiniment. Précisez le résultat que Codex doit atteindre, ce qu’il doit laisser intact, comment il doit vérifier ses progrès et quand il doit s’arrêter.

Cette approche convient notamment aux travaux suivants :

• les migrations de code pour lesquelles la pile cible, les vérifications de parité et les contraintes sont clairement définies
• les refactorisations de grande ampleur pour lesquelles Codex peut exécuter des tests après chaque étape
• les expériences, les jeux ou les prototypes dont Codex peut améliorer progressivement une version fonctionnelle

Évitez de regrouper sous un même objectif des tâches sans lien entre elles.

Organisez le travail par étapes

L’essentiel est de convenir des critères de réussite. Avant de commencer, Codex doit savoir ce que signifie « terminé ». Pour une migration, « terminé » peut signifier que la nouvelle implémentation passe les tests de contrat et qu’il reste possible de revenir à l’ancienne. Pour un jeu ou un prototype, « terminé » peut signifier que l’application se compile, se lance et correspond à la référence fournie ou se comporte comme prévu.

Laissez Codex travailler en autonomie

Pendant que Codex poursuit un objectif, demandez-lui de brefs points d’avancement pour savoir où en est le travail. Un point d’avancement utile indique l’étape en cours, ce qui a été vérifié, ce qu’il reste à faire et les éventuels blocages. Si les comptes rendus deviennent vagues, précisez l’objectif plutôt que de multiplier les consignes ponctuelles. Indiquez à Codex la prochaine étape à valider, la commande qui permet de la valider et les circonstances dans lesquelles il doit se mettre en pause.

Lorsqu’il poursuit un objectif, Codex peut travailler en autonomie pendant de nombreuses heures sans que vous ayez à faire le point avec lui. Il s’arrête lorsqu’il estime avec suffisamment de certitude que le critère d’arrêt est rempli. Vous pouvez donc considérer /goal comme une tâche d’arrière-plan qui ne nécessite aucune surveillance de votre part.

Exemples d’objectifs

Migrations

Que vous portiez des jeux vers une nouvelle pile technologique, des applications mobiles vers une nouvelle plateforme ou une base de code vers un nouveau framework, utilisez /goal pour confier la migration à Codex :

Création de prototypes

Que vous partiez de zéro pour créer une application ou que vous développiez un nouveau jeu ou une nouvelle fonctionnalité, utilisez /goal pour demander à Codex de réaliser une première version soignée. Vous pouvez guider son travail à l’aide d’un fichier PLAN.md qui décrit précisément ce que vous souhaitez créer.

Optimisation des prompts

Si vous disposez d’une suite d’évaluations, utilisez /goal pour optimiser vos prompts en fonction des résultats. Codex peut analyser les échecs, modifier le prompt, relancer les évaluations et répéter le processus jusqu’à ce que le score s’améliore ou que votre critère d’arrêt soit rempli.