Comet : je l’ai testé sur un vrai workflow agent

Comet est un harnais de Skills pour agents de code: il transforme une idée vague en workflow suivi, vérifié et reprenable. Après un essai sur un mini projet Node, mon verdict est simple: ça marche pour structurer un agent, mais ce n’est pas un outil magique ni léger.

Comet, c’est quoi ?

Comet, le projet GitHub de rpamis, se présente comme un « Agent Skill Harness For Turning Ideas Into Evaluated Workflows ». En clair, il ne remplace pas votre agent de code. Il lui donne un cadre: brief, phases, garde-fous, état, preuves, reprise, dashboard et évaluation.

Le produit vise surtout les tâches longues où un assistant peut perdre le fil: ajouter une fonctionnalité, faire évoluer une spec, vérifier des critères d’acceptation, archiver ce qui a été fait. Comet propose deux workflows:

• Native, plus direct, pensé pour les modèles forts et les boucles courtes.
• Classic, plus cadré, inspiré OpenSpec et Superpowers.

Il sait aussi installer des Skills dans des plateformes de coding agent, par exemple Claude Code, et fournir des scripts de guard pour bloquer les transitions trop rapides.

Élément	Ce que j’ai constaté
Version testée	0.4.0-beta.14 depuis le dépôt GitHub
Stack	Node.js 22 requis, pnpm, TypeScript, Vite pour le dashboard
Interface	CLI + dashboard web local
Cas testé	Ajout d’un endpoint HTTP /healthz dans un mini projet Node
LLM	Proxy OpenAI exporté comme demandé, pas nécessaire pour le runtime CLI testé
Résultat	Workflow Native créé, brief suivi, artefacts hashés, test réel exécuté, dashboard exploitable

Installation de Comet

J’ai cloné le dépôt dans /tmp/comet, lu le README, le package.json et le README d’eval. Première friction: mon environnement avait Node 20, alors que Comet demande Node 22+. J’ai donc lancé les commandes avec Node 22 via npx.

Autre détail très concret: /tmp était limité à 512 Mo. Le clone devait rester dans /tmp, mais les dépendances pnpm ne tenaient pas dedans. J’ai contourné proprement en mettant le store et le virtual store pnpm dans un dossier temporaire hors du clone, puis j’ai supprimé ces fichiers à la fin.

Les commandes de base ressemblaient à ceci:

git clone https://github.com/rpamis/comet /tmp/comet
cd /tmp/comet
npx -y -p node@22 -p pnpm@10.18.3 pnpm install --ignore-scripts
npx -y -p node@22 -p pnpm@10.18.3 pnpm build
npx -y -p node@22 -p pnpm@10.18.3 pnpm test:runtime-smoke

Le build a compilé les runtimes Classic, Native, Entry, TypeScript et le dashboard Vite. Le test smoke runtime a ensuite passé 237 tests, avec 1 test ignoré. Ce n’est pas juste un binaire qui répond à une commande de version, le dépôt embarque une vraie suite de validation.

Comet à l’usage sur un vrai cas

Pour éviter le faux test, j’ai créé un mini projet Node jetable: une fonction health(), puis une demande réaliste d’opérateur, exposer un endpoint /healthz sans dépendance externe.

J’ai initialisé Comet en mode Native, scope projet, plateforme Claude Code:

comet init . --yes --workflow native --platform claude --scope project --language en --json
comet doctor . --json
comet workflow resolve . --json

Ce que Comet a produit:

• .comet/config.yaml, avec le workflow Native sélectionné.
• .claude/skills/comet, .claude/skills/comet-native et .claude/skills/comet-any.
• une règle .claude/rules/comet-workflow-guard.md.
• un hook router dans la config Claude locale.
• un dossier docs/comet/changes/add-health-endpoint/ pour la demande.

Ensuite, j’ai lancé un changement Native:

comet native new add-health-endpoint --language en
comet native status add-health-endpoint --details

Première bonne surprise: Comet a refusé d’avancer tant que le brief était vide. Le status signalait brief-section-empty sur la section Outcome. J’ai donc rempli le brief avec outcome, scope, non objectifs, exemples d’acceptation et attentes de vérification.

Après confirmation, Comet a avancé en phase build. J’ai alors réellement modifié le mini projet: serveur HTTP Node natif, route GET /healthz, réponse JSON { "status": "ok" }, test qui démarre le serveur sur un port éphémère, appelle l’endpoint, vérifie le statut et ferme le serveur.

Le test réel:

npm test

Sortie utile:

> test
> node test.js

health endpoint ok

Comet a enregistré un checkpoint avec les artefacts index.js, test.js et package.json, leurs tailles et leurs hash. Le dashboard a ensuite montré la demande en phase verify, l’implémentation complète, 3 artefacts déclarés, 2 critères d’acceptation et un bloc de risques Git.

Ce que Comet produit vraiment

Le produit ne se contente pas de mettre des consignes dans un README. Il fabrique un système de suivi autour de la tâche.

Dans mon test, Comet a produit:

1. un brief structuré, contrôlé par des checks,
2. un état machine avec phase, révision, approbation et résultat de vérification,
3. des checkpoints avec manifest hashé,
4. une page d’acceptance extraite du brief,
5. un dashboard JSON et web,
6. des receipts de vérification.

Le point le plus intéressant, côté DevOps et sécu, c’est la traçabilité. Quand un agent dit « j’ai fini », Comet pousse à répondre: quel artefact, quel test, quelle preuve, quelle phase, quel hash ? C’est exactement le genre de discipline qui manque souvent dans les workflows agentiques.

Les limites de Comet

Mon essai a aussi montré des limites nettes.

D’abord, la courbe d’apprentissage est réelle. Le vocabulaire est dense: Native, Classic, Shape, Build, Verify, receipts, fences, contract hash, implementation scope. Pour un freelance qui veut juste lancer un agent sur une petite correction, c’est trop lourd.

Ensuite, la phase de vérification est stricte. Dans mon projet jetable, les receipts automatisés ont bien lancé npm test avec exit code 0, mais Comet les a marqués blocked, car le fence de snapshot après commande ne correspondait pas. Sur le fond, c’est plutôt sain: l’outil évite de valider une preuve si l’environnement a bougé. Sur l’expérience utilisateur, c’est frustrant si le repo n’a pas été préparé avec une baseline Git propre dès le début.

Enfin, Comet n’est pas un agent autonome prêt à produire du code tout seul depuis la CLI. Il sert surtout de harnais autour d’un agent compatible Skills. Le LLM se situe dans la plateforme de coding agent, pas forcément dans la commande comet elle-même.

Est-ce que Comet marche vraiment ?

Oui, pour ce que j’ai testé: installation, build, tests du dépôt, initialisation d’un projet, création d’un workflow Native, blocage d’un brief incomplet, suivi d’artefacts, dashboard et vérification d’une tâche réelle.

Non, si on attend un bouton magique qui prend une idée et livre une app validée sans comprendre le protocole. Comet impose une méthode. Cette méthode peut faire gagner du temps sur des tâches longues, mais elle en coûte au départ.

Ce que j’aime:

• les garde-fous avant de passer d’une phase à l’autre,
• le dashboard local, utile pour voir où en est une tâche,
• les hashes et manifests, bons signaux pour l’audit,
• la séparation Native et Classic,
• la volonté d’évaluer les Skills avec des métriques plutôt qu’au feeling.

Ce que j’aime moins:

• documentation abondante mais intimidante,
• Node 22 obligatoire,
• messages parfois très internes,
• receipts stricts difficiles à débloquer dans un repo sale ou mal initialisé,
• valeur maximale surtout avec un agent déjà intégré à une plateforme compatible.

Faut-il adopter Comet ?

Mon verdict: à essayer si vous faites déjà travailler des agents de code sur des tâches longues, surtout en équipe ou sur des projets où la preuve compte. Pour un usage freelance sécu/DevOps, je le vois bien sur des changements infra, des refactors risqués, des correctifs avec critères d’acceptation et des workflows où il faut reprendre après interruption.

Je ne l’adopterais pas partout. Sur une petite correction de config Nginx ou un script de 30 lignes, Comet ajoute trop de protocole. Sur un agent qui doit livrer du contenu, modifier du code, tester, puis laisser un journal exploitable, il devient beaucoup plus intéressant.

En bref: Comet n’est pas le moteur, c’est le rail. Si votre problème est que vos agents déraillent, il mérite un vrai essai.

FAQ

Comet remplace-t-il Claude Code ou un autre agent ?

Non. Comet installe des Skills, des règles, des hooks et des runtimes autour d’un agent. Il cadre le travail, mais il ne remplace pas le modèle ni l’outil de coding agent.

Peut-on utiliser Comet sans clé OpenAI ?

Pour les commandes CLI que j’ai testées, oui. Le LLM devient nécessaire quand l’agent compatible Skills exécute réellement le workflow de génération ou quand vous lancez certaines évaluations.

Comet est-il adapté à un débutant ?

Pas vraiment. Le concept est puissant, mais il suppose déjà de comprendre Git, les agents de code, les phases de livraison et les preuves de test. Pour un débutant, je conseillerais de commencer par le mode Native sur un projet très simple.