Qu'est-ce que /goal dans Claude Code ? Mode d'emploi, écriture des conditions et résultats d'un test concret

La commande /goal de Claude Code vous permet d'écrire une seule condition qui indique « quand c'est terminé » : Claude continue alors à travailler seul jusqu'à atteindre ce point. À la fin de chaque tour (une réponse de Claude), un petit modèle distinct vérifie si la condition est remplie. Si ce n'est pas le cas, Claude passe à l'étape suivante. Cet article présente l'utilisation de la commande et les conditions d'arrêt, d'après la documentation officielle (consultée le 24 octobre 2026). Il rapporte aussi les résultats de tests menés sur des tâches réelles de ce site, avec la consommation de tokens et la vérification de la qualité du résultat final.

1. Qu'est-ce que /goal : différences avec une demande ordinaire, /loop et les hooks Stop

Lorsque vous demandez un travail de façon ordinaire, Claude s'arrête dès qu'il juge le travail terminé, puis attend votre prochaine instruction. Si vous définissez un /goal, une vérification a lieu à la fin de chaque tour (une réponse de Claude). Si la condition n'est pas encore remplie, le tour suivant démarre même si vous n'envoyez rien. La documentation officielle donne comme exemples de travaux adaptés les tâches plus vastes dont l'état final peut être vérifié :

• migrer un module vers une nouvelle API, jusqu'à ce que tous les appels se compilent et que les tests passent
• implémenter un document de conception, jusqu'à ce que tous les critères d'acceptation soient satisfaits
• découper de gros fichiers, jusqu'à ce que chaque fichier soit à la taille fixée ou en dessous
• traiter une liste de tickets étiquetés jusqu'à ce qu'elle soit vide

Il existe trois mécanismes proches. La documentation officielle explique qu'il faut les distinguer selon « ce qui déclenche le tour suivant ».

En résumé, /goal est un « hook Stop qui juge au moyen d'une invite », et il ne fonctionne que dans cette conversation. Un hook Stop s'écrit dans un fichier de configuration et s'applique à toutes les conversations. /goal s'écrit sur le moment et ne s'applique qu'à cette conversation.

Source : Keep Claude working toward a goal (documentation officielle de Claude Code, consultée le 24 octobre 2026).

2. Utilisation : définir, vérifier l'état et désactiver

Une conversation ne peut contenir qu'un seul objectif. La même commande /goal sert à définir, à vérifier et à désactiver l'objectif, selon ce qui la suit.

1. Définir : tapez /goal suivi de la condition Exemple : /goal les tests de test/auth passent tous, et lint est propre aussi. Dès la définition, un tour démarre, et la condition sert elle-même d'instruction : il n'est pas nécessaire d'envoyer une demande séparée. Si un objectif existe déjà, la nouvelle condition le remplace. La condition peut contenir jusqu'à 4 000 caractères.
2. Vérifier l'état : tapez /goal seul Il affiche la condition, le temps écoulé, le nombre d'évaluations, les tokens utilisés et la raison de la dernière évaluation. Le nombre d'évaluations et la raison n'apparaissent qu'après la première évaluation.
3. Arrêter : /goal clear Cela supprime l'objectif avant qu'une évaluation ait lieu. stop, off, reset, none et cancel ont le même effet. Ouvrir une conversation neuve avec /clear supprime aussi l'objectif.

Si vous reprenez une conversation, un objectif non encore terminé revient. La condition est conservée, mais le décompte des tours, du temps et des tokens repart de zéro. La commande fonctionne dans l'application de bureau, en session à distance et avec les exécutions automatiques via claude -p. claude -p "/goal …" tourne jusqu'à la fin de l'objectif en une seule exécution. Si vous voulez suivre l'avancement, ajoutez --output-format stream-json --verbose.

3. Fonctionnement de l'évaluation et conditions d'arrêt

À chaque fin de tour, Claude Code envoie la condition et la conversation jusque-là à un « petit modèle rapide ». Le jugement a trois issues, chacune accompagnée d'une courte raison. Dans l'environnement de ce site, le juge était Claude Haiku 5.5 (confirmé d'après les journaux de conversation).

Le juge n'utilise aucun outil, et il ne se prononce que sur ce qui figure dans la conversation. Il ne relit pas les fichiers et n'exécute pas les tests lui-même. Si Claude ne répond au juge que sans utiliser d'outil pendant plusieurs tours d'affilée, Claude Code arrête la boucle, affiche un avertissement et vous rend la main, l'objectif restant en place.

Lorsque l'arrêt est dû à une erreur

Lorsque des sous-agents ou des tâches en arrière-plan sont en cours

Si un sous-agent ou une commande en arrière-plan tourne encore à la fin d'un tour, le jugement de ce tour est reporté. Lorsque les résultats reviennent, ils parviennent à Claude sous la forme d'un nouveau tour. Si l'attente dure 30 minutes, une « vérification intermédiaire » a lieu. Elle lit la sortie du travail en cours : si l'avancement est normal, elle laisse attendre ; si le travail est bloqué, elle invite Claude à corriger le problème ou à arrêter. Par défaut, l'intervalle double à 30 minutes, 1 heure, puis 2 heures, et après cela, la vérification se répète toutes les 2 heures. Vous pouvez modifier le premier intervalle avec la variable d'environnement CLAUDE_CODE_GOAL_CHECKIN_MINUTES. La valeur 0 désactive à la fois les vérifications intermédiaires et les relances automatiques.

Cas où la commande ne peut pas être utilisée, et coût

Le juge fait partie du mécanisme des hooks. Comme pour les hooks, il ne peut donc pas être utilisé dans un dossier que vous n'avez pas déclaré de confiance. Il ne fonctionne pas non plus lorsque disableAllHooks est défini sur true dans les paramètres, ou lorsque allowManagedHooksOnly est activé dans les paramètres d'administration. Dans ces cas, la raison est affichée. Les tokens utilisés pour le jugement sont facturés au tarif du petit modèle rapide. Selon la documentation officielle, ce coût est « généralement très faible par rapport au travail principal ». Vous pouvez changer le modèle du juge avec ANTHROPIC_DEFAULT_HAIKU_MODEL, mais ce réglage touche aussi d'autres traitements qui utilisent le petit modèle, comme le résumé de conversation.

Source : Keep Claude working toward a goal (consultée le 24 octobre 2026).

4. Comment rédiger une condition

Le juge ne lit que la conversation. Il faut donc rédiger la condition de façon que la sortie de Claude elle-même puisse la prouver. La documentation officielle cite trois éléments d'une condition qui tient bien sur la durée.

Si vous voulez fixer une limite à la durée du travail, écrivez-la dans la condition, par exemple « ou arrêter après 20 tours ». La documentation officielle ne prévoit pas de réglage dédié, comme le budget de tokens de /goal dans Codex.

Une précaution issue de nos tests sur ce site : écrivez ce qui doit être préservé dans la condition elle-même, et non dans un fichier d'instructions séparé. Le juge se prononce littéralement sur la condition. Une consigne placée dans un autre fichier peut donc être comptée comme « atteint » même si elle n'a pas été suivie. C'est exactement ce qui s'est produit dans l'expérimentation de ce site (voir le chapitre 5).

5. Résultats de deux essais avec /goal (comparés à une demande ordinaire)

Nous avons utilisé /goal pour une tâche sur les articles de ce site : harmoniser les points de fin de phrase. Dans les articles japonais existants, 1 035 emplacements présentaient un « 。 » final présent ou absent (dénombrés par le script de vérification de ce site pour les points de fin de phrase). La règle de correction était fixée et l'état final était clairement « 0 élément à la vérification ». Nous avons donc choisi cette tâche comme adaptée à /goal. Nous avons lancé /goal deux fois, avec des périmètres différents, et, à titre de référence, nous avons placé à côté une demande ordinaire.

La référence correspond à un essai où nous avons collé la condition d'un bloc en tentant /goal. Comme décrit dans la précaution du chapitre 2, la commande n'a pas fonctionné comme une commande et le travail s'est déroulé comme une demande ordinaire. Nous la présentons dans le tableau comme valeur de référence pour le même type de tâche demandé de façon ordinaire (le périmètre et les nombres diffèrent, ce n'est donc pas une comparaison stricte). Pour les deux essais avec /goal, nous avons tapé /goal à la main et vérifié la ligne « Goal set: ». Les essais ont été réalisés le 23 octobre 2026 dans l'application de bureau Windows, avec Claude Code 2.1.308, Claude Opus 5.5 comme modèle de travail, et le mode auto comme mode d'autorisation.

Les chiffres ont été totalisés à partir des journaux de chaque conversation (fichiers JSONL que Claude Code enregistre). Le montant équivalent est celui que Claude Code a calculé et enregistré au tarif de l'API. Il n'est pas facturé pour un usage par abonnement. Chaque résultat ne provient que d'un seul essai, et le périmètre et les nombres diffèrent d'un essai à l'autre. Les chiffres changeraient avec un autre type de tâche ou un autre modèle. L'écriture de cache de l'évaluateur correspond à la quantité de conversation chargée pour le jugement. Le montant équivalent est le total du modèle de travail et de l'évaluateur.

Les conditions que nous avons réellement rédigées

Voici les conditions écrites après /goal dans les deux essais. Les noms propres à ce site (le script de vérification, le fichier de notes de travail et les outils de mise à jour des enregistrements) ont été remplacés par des termes qui indiquent leur fonction. Les étapes détaillées du travail (les précédents pour les corrections et les fichiers à ne pas toucher) figuraient dans un fichier de notes de travail (au format Markdown), et la condition renvoyait vers ce fichier.

# Petit essai
Pour le texte japonais des articles 200 à 209 (9 articles), le script de vérification des points de fin de phrase signale 0 élément (afficher dans la conversation le résultat de vérification de chacun des 9 articles), et les commit et push sont faits selon les étapes du fichier de notes de travail. Arrêter après 30 tours.

# Grand essai
Pour le texte japonais des articles 100 à 199, le script de vérification des points de fin de phrase signale 0 élément. À respecter : suivre les étapes du fichier de notes de travail (ne corriger que la ponctuation, selon les précédents décidés ; ne pas modifier les mots, le sens, les traductions, les métadonnées ni les outils). À la fin de chaque tour, écrire une ligne « reste ○ éléments (○ articles) ». À la fin, afficher dans la conversation les résultats de vérification des 48 articles concernés, la liste des fichiers modifiés (seulement le texte et les enregistrements de cohérence), la réussite de la vérification des balises et le résultat de la mise à jour des enregistrements de cohérence, puis faire le commit et le push par chemin. Ne pas déployer. Arrêter après 40 tours.

Dans le petit essai, « écrire le nombre restant à chaque tour » n'était écrit que dans les notes de travail. Claude a terminé sans l'écrire, et le juge a déclaré l'objectif « atteint », en indiquant dans sa raison que « l'instruction de la procédure n'a pas été suivie, mais la condition ne l'exige pas ». Nous avons reporté cette leçon (chapitre 4) dans la condition du grand essai.

Vérification du résultat final

Nous n'avons pas pris le « atteint » du juge pour argent comptant. À chaque fois, nous avons contrôlé les différences ligne par ligne dans une conversation séparée, puis refait les vérifications.

6. Ce que nous avons appris : tâches adaptées et tâches non adaptées

Les tâches mécaniques se terminent en un seul tour

Chaque essai a terminé son travail en un seul tour. Dans un même tour, Claude peut utiliser des outils des dizaines de fois (le grand essai a utilisé Bash 32 fois). Une tâche qu'un script peut traiter est donc achevée d'un coup, même pour 321 éléments. C'est pourquoi l'avantage principal de /goal, « si cela ne suffit pas, continuer au tour suivant », ne s'est jamais manifesté pour ce type de travail. Les résultats ne proviennent que d'un essai par périmètre, mais entre la demande ordinaire de référence et les deux essais avec /goal, nous n'avons pas vu de grande différence de durée ni de qualité finale. Le surcoût se réduisait à une évaluation par essai, de 5,6 secondes et 9,0 secondes (le travail complet a pris environ 6 minutes et environ 10 minutes).

Le juge lit la conversation entière

Dans le grand essai, le juge a lu 114 410 tokens, c'est-à-dire la conversation de travail entière, transmise telle quelle. Plus la conversation s'allonge, plus chaque évaluation est lourde. Pour un travail qui s'étend sur de nombreux tours, ou pour lancer /goal au milieu d'une conversation déjà longue, le coût de l'évaluation sera probablement plus élevé que dans le présent essai.

Le juge vérifie si la condition est remplie

Le juge vérifiait avec précision les éléments de la condition, comme les résultats de vérification ou l'existence d'un commit. En revanche, il ne contrôle pas les qualités qui n'apparaissent pas en chiffres, comme le naturel d'une phrase. « Atteint » signifie que ce qui était écrit dans la condition est apparu dans la conversation. Cela ne remplace pas la vérification du résultat final.

Cette expérimentation n'a testé que les « travaux qui se terminent en un seul tour ». Nous distinguons ci-dessous les exemples de la documentation officielle et l'avis de l'auteur sur les tâches adaptées.

7. Différences avec /goal de Codex

OpenAI Codex possède aussi une commande /goal du même nom. Le principe (continuer à travailler en respectant une condition de fin) est le même, mais les opérations et la manière de fixer les limites diffèrent. Pour le détail de Codex, voir Comment utiliser /goal dans Codex.

Sources : pour Claude Code, Keep Claude working toward a goal ; pour Codex, Using Goals in Codex (OpenAI Cookbook) et l'article de ce site « Comment utiliser /goal dans Codex ». Les deux sources sont à jour au 24 octobre 2026.

Résumé

• /goal est une commande dans laquelle vous écrivez une condition de fin ; un modèle distinct la juge à chaque fin de tour, et Claude continue de travailler jusqu'à ce qu'elle soit remplie. Une même commande sert à définir, à vérifier l'état et à désactiver.
• Le juge ne lit que la conversation. Rédigez la condition de façon que son état final, la manière de le vérifier et ce qu'il faut préserver puissent être prouvés par la sortie de Claude, et incluez-y aussi la limite.
• Le mode d'autorisation ne change pas : si vous voulez confier le travail, combinez /goal avec le mode auto.
• Dans l'expérimentation de ce site, une tâche mécanique s'est terminée en un tour, même avec 321 éléments. Pour cette tâche en un tour, le surcoût se limitait à une évaluation. Selon l'avis de l'auteur, l'intérêt apparaît dans les travaux qui ne peuvent pas se terminer en un tour.
• « Atteint » signifie que ce qui était écrit dans la condition est apparu dans la conversation. Vérifiez séparément la qualité du résultat final, comme le naturel des phrases.
• Si vous collez une condition complète dans l'application de bureau, elle peut ne pas fonctionner comme une commande. Vérifiez avec la ligne « Goal set: ».

Étapes pour commencer : passez en mode auto → rédigez la condition selon la forme du chapitre 4 (état final, manière de le vérifier, ce qu'il faut préserver, limite) → tapez /goal à la main, collez la condition et vérifiez « Goal set: » → après « atteint », relisez vous-même les différences.

FAQ

Q. L'utilisation de /goal augmente-t-elle le coût ?

Oui, à hauteur des évaluations. Les évaluations sont faites par un petit modèle rapide, et la documentation officielle indique que le coût est « généralement très faible ». Dans l'expérimentation de ce site, la tâche terminée en un tour n'a comporté qu'une évaluation, qui a duré quelques secondes. Toutefois, comme le juge lit toute la conversation, plus elle est longue, plus chaque évaluation est lourde.

Q. Comment arrêter en cours de route ?

Supprimez l'objectif avec /goal clear. stop et cancel fonctionnent de la même manière. Si vous l'exécutez avec claude -p, arrêtez-le avec Ctrl+C. Supprimer l'objectif n'annule pas les modifications déjà faites.

Q. Le juge peut-il dire « pas encore » alors que Claude affirme avoir terminé ?

Oui, c'est pour cela qu'un modèle distinct juge. Si le juge dit « pas encore », le tour suivant démarre en utilisant sa raison comme indice. À l'inverse, dès que des résultats conformes à la condition apparaissent dans la conversation, l'objectif est « atteint ». La qualité que vous n'avez pas écrite dans la condition n'est donc pas garantie.

Q. Au bout de combien de tours s'arrête-t-il ?

Il n'y a pas de limite fixe. Il s'arrête lorsque la condition est remplie, lorsqu'elle est jugée impossible à remplir, lorsqu'une erreur à corriger apparaît, ou lorsque vous la supprimez. Si vous voulez une limite, écrivez-la dans la condition, par exemple « ou arrêter après 20 tours ». Le juge ne lisant que la conversation, il est utile d'inscrire aussi dans la condition quelque chose comme « à la fin de chaque tour, indiquer le nombre de tours écoulés ». (Aucun essai de cette expérimentation ne s'est terminé en un tour, donc nous n'avons pas testé l'arrêt à la limite.)

Q. Faut-il utiliser /loop ou /goal ?

Utilisez /goal si l'état final est défini. Utilisez /loop si vous voulez vérifier la même chose à intervalles réguliers. Par exemple, « vérifier toutes les 5 minutes jusqu'à la fin du déploiement » convient à /loop, tandis que « corriger jusqu'à ce que tous les tests passent » convient à /goal.

Références : Keep Claude working toward a goal, Run prompts on a schedule et Hooks guide (documentation officielle de Claude Code) ; Using Goals in Codex (OpenAI Cookbook). Consultées le 24 octobre 2026.