agents-config
La configuration qui structure ma façon de travailler avec des agents IA de code : une seule source, rendue pour quatre outils en ligne de commande, avec les skills, les hooks et les contrôles de revue qui gardent la main quand plusieurs agents construisent en même temps.
Dépôt privé
01Ce que c’est
Un seul dépôt contient tout ce que je dis aux agents IA de code : instructions, skills, règles, définitions de sous-agents et scripts de hooks. Un script d’installation écrit en Node.js produit à partir de cette source unique la configuration de quatre outils, Claude Code, Codex, Cursor et Antigravity. Je modifie une règle une fois et chaque outil lit le résultat. Il compte 60 skills et 308 commits depuis le 25 mai 2026.
02Comment une fonctionnalité avance
Je décris une fonctionnalité à une session d’orchestration. Elle règle d’abord avec moi les décisions ouvertes, rédige une spécification avec des critères d’acceptation, puis la découpe en tranches. Chaque tranche part chez un agent constructeur, dans son propre worktree git, si bien que plusieurs peuvent travailler en même temps sans toucher aux fichiers des autres. Sur une fonctionnalité récente, cela a donné 18 décisions réglées avant la moindre ligne de code, une spécification de 25 critères d’acceptation, 14 tranches et jusqu’à cinq agents au travail simultanément.
03Qui contrôle le travail
Un constructeur ne fait que construire : il compile, lance les tests et rédige une note de passation qui liste ce qu’il faut vérifier dans un navigateur. Il ne relit jamais son propre travail. Une porte de contrôle examine ensuite la branche dans un contexte neuf, avec des agents relecteurs qui n’ont pas écrit le code, une seconde relecture par un modèle d’un autre éditeur, Codex notamment, et des vérifications automatisées. Une vérification qui n’a pas pu s’exécuter compte comme un échec, jamais comme une réussite.
04Là où je garde la main
Des scripts de hooks bloquent les commandes git destructrices, gardent un constructeur dans sa tranche et empêchent un agent de choisir un modèle plus coûteux que ne le permet son rôle. La fusion et le déploiement restent de mon ressort, et un push exige ma permission explicite, accordée exécution par exécution. Chaque changement du workflow commence par une note datée dans un dossier de recherche, avec la question, la méthode et ce qui n’a pas pu être confirmé.
“If you haven’t seen it run, it’s not a working system.”
Traduction« Si vous ne l’avez pas vu tourner, ce n’est pas un système qui fonctionne. »
Décider quoi construire et regarder le vrai écran, ça, c’est resté à moi.
Comment c’est construit
- Une demande de fonctionnalité, planifiée et distribuée
- Une tranche terminée, relue
- Une branche vérifiée, remise à moi
- Configuration produite pour les outils
- Actions vérifiées avant exécution
Vous
Décide et approuve
Orchestrateur
Planifie le travail
Constructeurs
Écrivent le code
Contrôle
Vérifie le résultat
Configuration
Une source, quatre outils
Sélectionnez un élément du schéma pour voir son rôle. Chaque couleur est un flux à travers le système.