Mettre Claude Code en boucle : /goal, /loop et les hooks

Le loop engineering devient intéressant quand il quitte la théorie. Dans Claude Code, on peut maintenant demander à une session de poursuivre un objectif, de relancer une consigne à intervalles réguliers ou de consulter un évaluateur avant de s’arrêter.

Ces mécanismes se ressemblent à l’écran : Claude répond, puis une nouvelle action démarre. Mais ils ne répondent pas à la même question. Le premier attend une condition. Le deuxième attend une horloge. Le troisième attend une décision.

Trois mécanismes, trois déclencheurs

Cette distinction est le point de départ. Utiliser /loop pour un objectif de compilation n’est pas impossible, mais l’intervalle n’est pas le bon signal. Utiliser un hook pour une simple relance périodique est tout aussi disproportionné.

/goal : continuer jusqu’à une condition

/goal est le mécanisme le plus proche du loop engineering. On lui donne une condition de réussite mesurable, et Claude continue à travailler sans que l’utilisateur doive écrire « continue » après chaque tour.

/goal tous les tests de test/auth passent,
le lint retourne 0,
et aucun autre fichier de test n’est modifié

Après chaque tour, un modèle d’évaluation séparé vérifie si la condition est satisfaite. Si ce n’est pas le cas, la raison est renvoyée à Claude et un nouveau tour démarre.

Il faut toutefois écrire la condition comme quelque chose que la conversation peut démontrer. L’évaluateur ne lance pas lui-même les commandes et ne lit pas indépendamment votre dépôt. Claude doit donc exécuter les tests et faire apparaître leur résultat dans le transcript.

Une bonne condition contient généralement :

• un état final mesurable ;
• la commande ou la preuve attendue ;
• les contraintes qui ne doivent pas être violées ;
• une limite de tours ou de temps.

/goal npm test -- auth retourne 0,
les fichiers de production restent dans src/auth,
et arrête-toi après 12 tours maximum

Pour voir l’état de la boucle, utilisez /goal sans argument. Pour la supprimer, utilisez /goal clear.

/loop : relancer une tâche selon une cadence

/loop répond à une autre situation : une action doit être répétée à intervalles réguliers. C’est pratique pour surveiller un déploiement, vérifier une pull request ou suivre un build long.

/loop 5m vérifie si le déploiement est terminé et dis-moi ce qui s’est passé

L’intervalle et le prompt sont facultatifs. La documentation actuelle permet aussi de laisser Claude choisir dynamiquement le délai entre deux vérifications :

/loop vérifie la CI et traite les nouveaux commentaires de revue

La différence avec /goal est simple : /loop est déclenché par le temps, pas par l’échec d’une condition. Il reste lié à la session locale et n’est pas un ordonnanceur de production. Pour un travail nocturne ou durable, il faut plutôt utiliser une tâche planifiée, GitHub Actions ou une routine dédiée.

Le Stop hook : votre propre évaluateur

Le Stop hook intervient chaque fois que Claude termine une réponse. Il peut lancer un script déterministe, demander une décision à un modèle ou, avec un hook agent, inspecter le dépôt et exécuter des commandes avant d’autoriser l’arrêt.

Voici une version simplifiée d’un hook prompt :

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Vérifie si toutes les tâches sont terminées.
Si ce n’est pas le cas, réponds avec {\"ok\": false, \"reason\": \"ce qui reste à faire\"}."
          }
        ]
      }
    ]
  }
}

Si l’évaluateur répond que le travail n’est pas terminé, sa raison devient le prochain signal envoyé à Claude. Pour une vérification qui doit réellement lire les fichiers ou lancer les tests, un hook de type agent est plus adapté qu’un simple hook prompt.

Je réserverais toutefois les hooks aux règles transversales : empêcher un arrêt prématuré, imposer une vérification de sécurité ou protéger une branche. Pour une tâche ponctuelle, /goal est plus lisible et plus facile à contrôler.

Quel mécanisme choisir ?

• Vous voulez atteindre un état final vérifiable : utilisez /goal.
• Vous voulez regarder régulièrement un état externe : utilisez /loop.
• Vous voulez une règle qui s’applique à chaque fin de tour : utilisez un Stop hook.
• Vous voulez lancer une tâche hors session : utilisez un ordonnanceur ou votre CI.

Un premier workflow raisonnable

Pour une feature à ajouter dans une application, je commencerais simplement :

1. Écrire l’objectif et les critères d’acceptation dans un fichier de travail.
2. Lancer /goal avec une condition précise et une limite de tours.
3. Demander à Claude de montrer les commandes et les résultats de validation.
4. Lire la raison de l’évaluateur quand la boucle continue.
5. Interrompre si la prochaine étape demande une décision produit ou une modification risquée.

Une fois ce workflow maîtrisé, on peut ajouter des hooks. Pas avant. La complexité d’orchestration doit résoudre un problème réel, pas simplement rendre le système plus impressionnant.

Les exemples ci-dessus suivent la documentation officielle de /goal, celle de /loop et le guide des hooks.