Le guide ultime de /goal

/goal n'est pas une fonctionnalité. C'est une primitive.

HTTP est une primitive. JSON est une primitive. /goal devient une primitive pour les agents de codage.

Il y a quelques semaines, Codex CLI d'OpenAI a ajouté /goal comme moyen de donner au travailleur de codage une tâche avec un état « terminé » défini. Claude Code l'a ajouté cette semaine.

Hermes Agent, l'orchestrateur que j'exécute sur un Mac Mini pour coordonner le travail entre les travailleurs de codage, intègre /goal depuis un moment.

J'ai donc désormais un constructeur, un relecteur et un orchestrateur qui acceptent tous le même format d'instruction, même s'ils ne partagent rien d'autre.

Si vous n'avez vu /goal utilisé que comme une invite plus sophistiquée, vous avez manqué ce qu'il change.

Ce qu'est réellement /goal

Une invite classique demande à un agent la réponse suivante. Vous lisez ce qui revient, décidez si c'est juste et poussez l'agent vers l'étape suivante. Vous guidez chaque tour.

/goal inverse cela. Vous écrivez à quoi ressemble « terminé », vous le soumettez une fois, et l'agent travaille vers cet objectif jusqu'à ce qu'il l'atteigne. En voici un réel :

1/goal Construire l'application décrite dans SPEC.md. Terminé signifie que les tests passent,
2la compilation passe, le README est exact, et git status ne montre que
3les fichiers de projet pertinents.

L'objectif reste actif jusqu'à ce qu'il soit atteint, mis en pause, bloqué, effacé, ou qu'il ait épuisé son budget.

C'est différent du fait de mettre le mot « goal » dans une commande unique normale. Si vous écrivez codex exec 'goal: build the app', c'est toujours une invite avec une étiquette. La vraie primitive vit dans une session de travail interactive. Vous lancez le CLI, vous soumettez /goal, et vous vous éloignez.

Le changement est le passage du prompting (vous conduisez) à l'assignation (l'agent conduit vers une cible que vous avez définie).

GIF

Les trois outils qui parlent actuellement /goal

Les trois outils acceptant /goal ne sont pas tous le même type de chose, il vaut donc la peine d'être précis.

Codex est le CLI de codage d'OpenAI. Fort en implémentation, surtout quand on lui donne un cahier des charges clair. /goal est la façon dont vous lui donnez ce cahier.

Claude Code est le CLI de codage d'Anthropic. Fort dans l'inverse : trouver ce qui ne va pas dans un code qui semble correct. Conformité au cahier des charges, problèmes de sécurité, états d'erreur, failles de sécurité. /goal est la façon dont vous le pointez vers du code et lui demandez une relecture.

Hermes Agent est un type d'outil complètement différent. Pas un travailleur de codage, mais un orchestrateur qui coordonne le travail entre des travailleurs de codage comme les deux précédents. /goal est la façon dont Hermes délègue des tâches à l'outil approprié, et aussi la façon dont je dis à Hermes ce que je veux en premier lieu.

Ce qui compte, ce n'est pas que l'un d'eux ait livré /goal. C'est que trois équipes différentes ont convergé vers la même primitive, et cette convergence rend possible leur composition.

GIF

Configuration

La première fois que j'ai eu besoin de Codex et Claude Code sur le Mac Mini qui exécute Hermes, je ne les ai pas installés manuellement. J'ai envoyé un message à Hermes pour lui demander de les installer tous les deux et de me connecter. Il s'est occupé du reste.

Voilà le flux de travail maintenant. Vous ne tapez pas de commandes d'installation. La configuration est juste un autre objectif.

Si vous n'avez pas encore d'orchestrateur en fonctionnement, les pages d'installation de Codex et Claude Code sont assez faciles à suivre. Mais une fois que vous en avez un, vous ne devriez plus configurer un autre outil à la main. L'intérêt d'avoir un orchestrateur est que le travail mécanique cesse d'être le vôtre.

Ce qu'Hermes ajoute par-dessus /goal

Un /goal brut est utile en soi. Mais il vous laisse avec un problème de coordination.

Si Codex tourne dans un terminal et Claude Code dans un autre, vous devez vous souvenir quel processus fait quoi. Vous devez vérifier les logs. Vous devez transmettre manuellement les résultats de relecture d'un outil à l'autre.

Hermes transforme ces exécutions lâches en un flux de travail :

1. Vous envoyez un message à Hermes (dans mon cas, via Telegram depuis mon téléphone)
2. Hermes crée des cartes d'objectif sur un tableau Kanban
3. Hermes choisit le bon travailleur pour chaque carte
4. Le travailleur exécute l'objectif en arrière-plan
5. La carte stocke l'ID de processus, le PID, le dépôt et les critères de fin
6. Quand la construction est prête, Hermes remet le dépôt au relecteur
7. Si la relecture bloque, Hermes renvoie les résultats comme un objectif de correction
8. Hermes vérifie la sortie finale en inspectant le système de fichiers, les tests, la compilation et l'état git

Le tableau est ce que devient /goal quand il y a un orchestrateur par-dessus. Chaque objectif a une carte, chaque carte a un statut, chaque transfert laisse une trace. Au lieu de chasser dans les terminaux, vous regardez le travail se déplacer à travers les colonnes sur votre téléphone.

Les trois rôles

Les outils changent. Les rôles, non.

Orchestrateur. Possède la boucle de contrôle. Décomposition des tâches, sélection des travailleurs, cartes Kanban, processus d'arrière-plan, dépendances, vérification finale, résumé destiné à l'utilisateur. Dans ma configuration, Hermes.

Constructeur. Prend un cahier des charges et produit du code fonctionnel. L'implémentation est le goulot d'étranglement que ce rôle résout. Codex est généralement fort ici.

Relecteur. Lit ce que le constructeur a produit et trouve ce qui ne va pas. La correction est le goulot d'étranglement. Claude Code est généralement fort ici.

Une exécution réelle, de bout en bout

J'ai donné à l'agent Hermes l'objectif de faire ceci :

1/goal Construire un outil en CLI qui trouve X mentions de moi et m'envoie une notification
2quand quelque chose explose.

Hermes a décomposé la demande en six cartes.

Shubham Saboo

@Saboo_Shubham_

·

12 mai

Codex /goal le construit.

Claude Code /goal le relit et l'affine.

Hermes /goal gère l'orchestration et le transfert.

Le tout suivi sur un seul tableau Kanban et les agents continuent de tourner en boucle.

58

61

852

88K

Carte 1 : Cahier des charges. Hermes a écrit SPEC.md lui-même, capturant la stack, le chemin du dépôt, les contraintes en lecture seule, les exigences du mode simulé, les tests et les commandes de vérification. Propriété du rôle de chef de produit.

Carte 2 : Codex construit. Codex a exécuté /goal par rapport à SPEC.md. Il a créé les fichiers du projet, implémenté l'interface utilisateur et le backend, ajouté des tests et amené l'application à un état fonctionnel. Environ 15 minutes. Quand il a fini, npm test passait, npm run build passait, et git status ne montrait que les nouveaux fichiers pertinents.

Carte 3 : Claude Code relit. Claude Code a exécuté /goal pour relire ce que Codex a construit. Vérification de la conformité au cahier des charges, sécurité en lecture seule, gestion des clés API, états d'erreur, tests, utilité de l'interface, bugs et problèmes de sécurité. Résultat : RÉUSSI, aucun problème bloquant.

Carte 4 : Boucle de correction Codex. Sautée, car la relecture a réussi. La carte compte toujours quand elle est sautée. Cela montre qu'Hermes peut modéliser un travail conditionnel. Si Claude Code avait bloqué, Hermes aurait renvoyé les résultats à Codex comme un nouvel objectif /goal.

Carte 5 : Vérification finale Claude Code. Sautée pour la même raison.

Carte 6 : Résumé final Hermes. Application fonctionnelle au chemin local, interface utilisateur et API vérifiées en mode simulé. Codex l'a construite avec /goal. Claude Code l'a relue avec /goal et a renvoyé RÉUSSI.

Tout cela venait d'un seul message. Trois outils différents ont fait le travail réel, mais je n'ai jamais parlé qu'à Hermes.

La règle de vérification

Hermes n'a jamais fait confiance à l'auto-évaluation de Codex. Après que Codex a marqué la construction comme terminée, Hermes a exécuté les commandes lui-même :

1npm test         # 17 tests passés
2npm run build    # compilation vite passée

Le vérificateur est ce qui fait d'un /goal un contrat au lieu d'une promesse. Ne faites pas confiance à l'auto-évaluation du travailleur comme définitive. Faites confiance au vérificateur.

Les agents de codage sont confiants. Ils vous diront que la compilation passe alors qu'elle n'a jamais été exécutée. Ils vous diront que les tests passent alors qu'ils ont écrit des tests qui ne se sont jamais exécutés. Le vérificateur comble cet écart.

Sans vérification, /goal n'est qu'une invite plus sophistiquée. Avec vérification, il devient un contrat.

GIF

Exécuter plusieurs objectifs

Vous pouvez exécuter plusieurs /goal en parallèle, mais vous ne pouvez pas pointer plusieurs travailleurs de codage vers les mêmes fichiers sans y réfléchir d'abord.

Mon paramètre par défaut est un constructeur principal par dépôt. Si je veux du parallélisme, je l'ajoute sur des limites claires. Dépôts différents, branches différentes, worktrees git, packages séparés, documentation vs code, tests vs implémentation. Partout où deux travailleurs ne peuvent pas se marcher sur les pieds.

Le mauvais schéma est trois travailleurs modifiant tous le même fichier dans le même dépôt. Vous obtenez des conflits, des écrasements partiels, et un travailleur qui annule silencieusement le travail d'un autre.

Le meilleur schéma est un seul rédacteur à la fois sur un fichier donné. Le constructeur écrit, le relecteur lit seulement, les objectifs de correction restent circonscrits à la correction. Ou exécutez trois constructeurs dans trois worktrees sur trois approches concurrentes et laissez l'orchestrateur choisir la meilleure.

Le tableau est ce qui rend cela pratique. Sans lui, les travailleurs parallèles en arrière-plan deviennent un chaos terminal.

Ce qui change pour moi

Le cadre utile ici n'est pas « Je peux exécuter des agents en arrière-plan ».

C'est qu'un seul message se transforme en un pipeline à travers trois outils de codage différents, et je regarde l'ensemble se déplacer sur un seul tableau.

Vous arrêtez de rester assis dans un terminal à attendre qu'un agent finisse, et vous commencez à gérer une file de travail avec un état visible.

Si Codex et Claude Code avaient chacun inventé leur propre format de transfert de tâche, aucun orchestrateur ne pourrait router entre eux. Le tableau est impressionnant, mais la primitive rend le tableau encore plus utile.

Les travailleurs peuvent changer, mais la primitive reste la même. Le prochain outil de codage qui adoptera /goal rejoindra ce pipeline sans que je n'aie rien à changer. Je me contenterai de lui router du travail.

C'est ce que font les bonnes primitives.

Pour plus de conseils sympas et d'idées intéressantes autour d'Hermes, OpenClaw, Claude Code, Codex et autres équipes d'agents 24/7.

Suivez → @Saboo_Shubham_