/plan, /grill, /goal : le workflow des skills intégrés
Le pitch de Meta pour les skills livrés avec Muse Code tient en une ligne : tu entres une idée brute, tu ressors une fonctionnalité passée au gril et validée. Voici ce que fait vraiment chaque commande, et quand la dégainer.
/plan — rien ne change tant que tu n’as pas validé
/plan transforme la tâche demandée en un plan soumis à ton approbation. L’agent étudie le dépôt, décompose le travail, présente son approche — puis s’arrête. Aucune modification de code avant ton feu vert. Pour tout ce qui dépasse le correctif trivial, c’est le bon coup d’ouverture : ça convertit « j’espère que l’agent m’a compris » en un document que tu peux lire, et ça attrape les malentendus quand ils coûtent quelques secondes plutôt qu’une après-midi à détricoter un refactoring parti de travers.
/grill — la revue adversariale avant l’exécution
/grill met le plan à l’épreuve jusqu’à ce qu’il tienne. Le nom est bien choisi : au lieu d’accepter poliment le premier plan qui a l’air plausible, l’agent cuisine sa propre approche — cas limites, dépendances cachées, modes de défaillance — et la révise jusqu’à ce que le plan survive au passage sur le gril. Les ingénieurs humains font ça en design review. La plupart des agents de code sautent complètement cette étape et la paient en retries. Si un plan doit s’écrouler, autant qu’il s’écroule sur le papier.
/goal — la ligne d’arrivée, gardée en mémoire
/goal travaille à la réussite de l’objectif que tu spécifies — et maintient l’agent sur les rails jusqu’à ce que ce qui est mergé soit bien ce que tu voulais au départ. Les longues sessions d’agent ont un mode de défaillance bien connu : la dérive. Cinquante appels d’outils plus tard, l’agent polit consciencieusement quelque chose d’adjacent à — mais pas tout à fait — ce que tu avais demandé. Le conditionnement par objectif a été entraîné dans Muse Spark 1.2 précisément pour ça, et /goal est la poignée qui te permet de le tenir.
Les seconds rôles : /model et /effort
Deux commandes de plus gèrent le coût plutôt que le workflow. /model change le modèle sous-jacent en pleine session — par exemple vers muse-spark-1.2 au tarif standard de la Model API quand il te faut l’offre sans utilisation des données pour l’entraînement (les détails sont dans notre comparatif des deux offres). /effort règle la profondeur de raisonnement. Muse Spark réfléchit avant de répondre et ces tokens de réflexion sont facturés en sortie : ajuster l’effort à la difficulté de la tâche est l’optimisation de coût la plus simple qui existe.
Un workflow qui se compose
Les skills s’enchaînent naturellement : /plan pour la fonctionnalité, /grill pour le plan, approbation, puis /goal pour porter l’exécution — avec le fan-out qui parallélise les parties indépendantes et l’event log qui enregistre chaque étape pour la revue. Chaque étape verrouille la suivante, et c’est exactement comme ça qu’un système autonome devrait gagner ta confiance, cran par cran. La recette du cookbook consacrée aux skills intégrés montre tout le pipeline sur une vraie fonctionnalité ; tu la trouveras dans le cookbook.