oh-my-agent : le harnais qui vérifie les artefacts plutôt que le récit des agents
first-fluke/oh-my-agent offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.
En bref
- De quoi s’agit-il ?
- Ce projet TypeScript impose une vérification mécanique aux agents de codage IA : un hook de fin de session, un juge indépendant, un journal d'événements inaltérable, et un répertoire .agents/ porté par une douzaine de runtimes.
- À qui s’adresse-t-il ?
- oh-my-agent concerne les équipes qui enchaînent des agents IA sur des workflows réels et veulent des preuves plutôt que des récits de succès. Il ne concerne pas ceux qui cherchent un simple prompt enhancer sans discipline de vérification.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Rendre falsifiable le récit de l'agent
Le point de départ du README est un constat de méfiance : les agents racontent leur succès. « Les tests passent, tous les critères sont satisfaits » ne coûte rien à déclarer, et rien dans la même session ne peut le contredire. oh-my-agent, écrit en TypeScript sous licence MIT avec 1 253 étoiles, répond en rendant cette affirmation falsifiable : chaque mécanisme de vérification est mécanique, une commande sort 0 ou non, un fichier est sur le disque ou non, et aucun LLM n'est interrogé pour savoir si le travail « paraît correct ».
Le projet se décrit comme un harnais d'agents portable et indépendant du fournisseur, pour des compétences, des workflows et des équipes d'agents alignés sur une base de code et ses conventions. Le rythme de publication est soutenu : la CLI v12.8.0 est sortie le 28 août 2026, la veille de la consultation du dépôt, avec une branche web versionnée séparément (v4.2.5).
Le Stop-hook et la barrière anti-contournement
Le premier mécanisme est un Stop-hook : il refuse de terminer la session tant qu'un workflow persistant est actif, et exécute le script de porte configuré avant d'autoriser l'arrêt. Seuls typecheck, test et lint sont exécutables ; tout ce qu'un agent écrit d'autre dans le fichier d'état est ignoré, jamais exécuté. Le système est plafonné à cinq renforts pour qu'une porte définitivement rouge ne piège pas l'utilisateur.
La seconde barrière, la porte anti-contournement, se lance par oma ralph:verify --json et contrôle quatre artefacts qu'un raccourci ne peut pas fabriquer : les enregistrements de phases du workflow ultrawork, le plan JSON, le fichier de résultat d'un agent QA distinct et celui d'un agent de refactoring distinct. Des artefacts manquants signifient que la phase n'a pas tourné, quoi que dise le récit. Les budgets suivent la même logique : session.quota_cap plafonne jetons, nombre de spawns et dépense par fournisseur, et quand le budget horaire s'épuise, le Stop-hook s'arrête honnêtement avec un statut partiel inscrit au journal.
Un juge indépendant et un journal d'événements
Contre l'aveuglement de session, oh-my-agent spawn un juge séparé, avec un contexte neuf, briefé sur les critères et jamais sur ce que l'implémenteur prétend avoir corrigé. Ce juge revérifie chaque critère à chaque itération, y compris les passes précédents, le README rappelant que corriger C2 est justement la façon dont C1 régresse en silence. Chaque décision de porte, réussite ou échec, atterrit dans un journal d'événements.
Ce journal est append-only : une ligne JSON par événement dans .agents/state/sessions/{sid}/events.jsonl, horodatée du fournisseur et de l'identifiant de session du runtime, auditable après coup et lisible quel que soit le vendeur. À cela s'ajoute oma verify <agent>, une batterie de vérifications déterministes par agent, avec un noyau commun, violation de périmètre, alignement de charte, secrets en dur, recherche de marqueurs de tâches oubliés, sorties déclarées, et des vérifications spécifiques au type, du TypeScript strict à Flutter analyze en passant par le SQL brut et les styles en ligne.
.agents/ : une source de vérité projetée dans chaque runtime
La portabilité suit un principe unique : le répertoire .agents/ détient compétences, workflows, règles et portes, et se projette dans la disposition native de chaque runtime. Changer de fournisseur devient un changement de configuration, pas une migration. Le tableau d'intégration distingue les modes : natif plus adaptateur pour Claude Code, Codex CLI et Cursor ; SSOT natif pour Antigravity ; dispatch natif pour Qwen Code ; natif-compatible pour Reasonix, Pi, OpenCode et Amp ; compétences liées par symlink pour GitHub Copilot ; hooks natifs pour Grok Build ; hooks natifs et agents pour Kiro CLI.
La commande oma emit pousse la même source vers des formats ouverts : dossiers de compétences conformes à Agent Skills, .claude-plugin/marketplace.json, AGENTS.md, avec une vérification de dérive branchable dans l'intégration continue. Le README met en garde contre le mélange des canaux de distribution : APM de Microsoft ne livre que les compétences, tandis que workflows, règles, oma-config.yaml, hooks de détection et la CLI oma agent:spawn passent par bunx oh-my-agent@latest. Une seule distribution par projet, pour éviter la dérive.
Trente-deux agents, dix préréglages, des commandes slash
Le registre compte 32 agents nommés, chacun spécialisé : oma-architecture pour les compromis entre modules, oma-backend pour les API en Python, Node.js ou Rust, oma-frontend pour React et Next.js avec TypeScript et Tailwind CSS v4, oma-db pour schéma et migrations, oma-debug pour l'analyse de causes racines, oma-mobile pour Flutter, oma-qa pour les revues de sécurité et performance, oma-scm pour les branches et commits conventionnels. Dix préréglages assemblent ces agents par profil, de Backend à Research en passant par Fullstack et DevOps.
Le pilotage passe par la conversation ou par des commandes slash structurées : /deepinit cartographie la base de code dans AGENTS.md, ARCHITECTURE.md et docs, /ultrawork et /ralph orchestrent les longs workflows, /review et /deepsec couvrent la revue et la sécurité. La détection automatique des mots-clés fonctionne en 11 langues, et le README chiffre sa fiabilité via oma verify triggers sur un corpus étiqueté de 171 invites, avec zéro raté et moins de 10 % de faux positifs, critère bloquant en CI. Ce sont des mesures auto-déclarées, vérifiables en relançant la commande.
Installation, dépendances bun et uv, et monorepos
L'installation passe par un script qui installe automatiquement bun, uv et serena s'ils manquent : curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash sur macOS et Linux, l'équivalent PowerShell sous Windows, ou bunx oh-my-agent@latest à la main avec les trois dépendances préalables. Après installation, un préréglage suffit à déployer le jeu d'agents choisi.
Côté projets complexes, le routage automatique des monorepos s'appuie sur detectWorkspace, qui lit pnpm, nx, turbo et lerna pour acheminer chaque agent vers son espace de travail. Le README avance aussi des chiffres d'économie, environ 75 % de jetons grâce à une conception de compétences en deux couches, et décrit une boucle d'exploration qui, après deux tentatives ratées, génère des variantes d'hypothèses en parallèle pour garder le meilleur résultat. Ces affirmations de performance restent à confronter à votre propre consommation, le journal d'événements fournissant justement la matière pour le faire.
Conclusion éditoriale
oh-my-agent concerne les équipes qui enchaînent des agents IA sur des workflows réels et veulent des preuves plutôt que des récits de succès. Il ne concerne pas ceux qui cherchent un simple prompt enhancer sans discipline de vérification. Avant de l'adopter, lancez le script d'installation officiel, activez un workflow persistant, et provoquez volontairement un échec de typecheck : le comportement du Stop-hook et le contenu du journal events.jsonl vous diront si cette rigueur tient dans votre projet.
Notes de la communauté