Prompt seed AGENTS.md pour faire tourner plusieurs agents de codage IA ensemble sur une ou plusieurs codebases (EstreGenesis)

Sur un même projet,

• Claude Code
• Cursor
• GitHub Copilot
• Gemini (Antigravity)
• Cline
• Windsurf
• Continue

Quand on fait tourner ensemble plusieurs agents de codage IA de ce type dans le but de répartir les tokens (et de minimiser les coûts),
CLAUDE.md, .cursor/rules/ et GEMINI.md commencent peu à peu à diverger.
EstreGenesis est une bibliothèque de prompts seed de bootstrap AI Native créée pour tenter de résoudre ce problème.

https://github.com/SoliEstre/EstreGenesis

Il suffit de fournir un fichier seed comme premier message dans le chat, en

• copiant-collant son contenu,
• indiquant son chemin local,
• le joignant en pièce jointe,
• ou en décrivant son emplacement dans le chat de manière indirecte, etc.

puis

l’agent peut

• soit bootstrapper un nouveau projet avec AGENTS.md comme source unique de vérité + une structure de fichiers bridge propre à chaque outil,
• soit examiner un projet existant déjà doté de fichiers de règles épars et le migrer vers la même structure.

Selon le niveau de profondeur souhaité, vous pouvez choisir l’un des 3 tiers (Master / Lite / Compact).

• Lite est le niveau par défaut.
• Si vous avez tendance à dépenser beaucoup de tokens (en utilisant uniquement des modèles haut de gamme comme Opus 4.7, GPT 5.5, etc. et en privilégiant la qualité),
  ou si vous voulez un cadre plus robuste avec des modèles plus légers (Sonnet, Haiku), utilisez le tier Master.
• À l’inverse, si vous voulez minimiser au maximum l’influence du seed, choisissez le tier Compact.

Le dépôt est fourni en paire anglais/coréen.
Les seeds dans les deux langues sont gérés de manière identique jusqu’aux phases, à la migration et au guide d’exploitation ; dans une équipe bilingue, on peut donc déployer les deux versions ensemble.

Les quatre patterns clés sont les suivants :

1. AGENTS.md comme SSoT + des bridges légers par outil pour éviter le chaos des règles.
2. .agent/_coordination/ pour éviter les conflits lors des modifications simultanées.
3. .agent/_lessons/ pour éviter les récidives, afin qu’un debug de 3 heures se transforme en résolution en 30 secondes à la session suivante.
4. Pour les décisions importantes, imposer une boucle Research → Report → Plan afin de piloter un développement robuste fondé sur la recherche.

Et ce qui a été ajouté dans cette v1.6.0, c’est une politique d’estimation agent-time vs human-time.
Comme la plupart des IA gonflent de 5 à 10× la durée prévue lors de la planification en se basant sur un rythme de développement humain,
dans le choix du mode de cadence d’exécution du bootstrap Phase 0, on peut définir à l’avance :

• Cautious 2~4×
• Proactive 5~6×
• Burst 6~8×
• Sprint 9~10×

Ainsi, toutes les estimations sont présentées en séparant temps de travail des agents + temps de revue humaine + durée calendaire réelle.
Il est aussi possible de changer de mode pendant l’avancement du projet, et _lessons/ permet d’ajuster ces estimations à partir des mesures réelles.

Parmi les politiques optionnelles importantes, il y a aussi un pattern qui consiste à séparer les repos des projets liés (comme FE/BE) et un repo distinct dédié uniquement à la documentation de développement qui les supervise.

** Antigravity ou GitHub Copilot, par exemple, ne peuvent pas accéder aux fichiers en dehors du dossier de travail ; l’idée est donc de placer chaque repo source sous le repo documentaire, puis d’enregistrer ces dossiers dans .gitignore afin de séparer le scope Git.

On obtient ainsi un repo documentaire principalement composé de .md ; même si le code source est dans un repo public, la documentation de développement peut rester privée, ce qui permet de mieux contrôler ce qui est exposé.

En particulier, si vous créez un projet dans Claude Project puis rattachez ce repo documentaire aux fichiers du projet via une connexion GitHub pour l’utiliser comme connaissance du projet, vous obtenez une configuration permettant non seulement le chat basé sur la documentation du projet, mais aussi la deep research. (À chaque push sur le repo, il faut cliquer sur le bouton d’actualisation dans le projet et attendre la synchronisation.)
En utilisant à la fois des agents de codage et des agents capables de deep research, dès qu’un sujet nécessite une recherche approfondie, il suffit de demander un prompt de commande de deep research, de lancer cette deep research dans Claude Project,
puis de déposer le résultat dans /archive/<date>_<sujet> du repo documentaire et de confier à l’agent de l’IDE la revue et la consolidation ; cela permet de faire progresser le développement du projet à un niveau élevé.
De plus, le chat de Claude Project permet aussi d’obtenir des conseils sur la monétisation et les sujets business (juridique, brevets, etc.), raison pour laquelle je recommande ce pattern.

Ce repo est une mise en forme sous forme de seed du savoir-faire accumulé en faisant fonctionner simultanément 3 agents — Antigravity + Claude Code + GitHub Copilot — sur mon deuxième véritable projet AI Native, en corrigeant au fil de l’eau les mêmes erreurs répétées et les points peu pratiques.
J’y agrège aussi des patterns d’usage utiles provenant de mes autres projets, et l’ensemble continue de faire boule de neige.

Et il ne s’agit pas forcément uniquement d’agents de codage : même si on le donne à un agent comme Hermes, il absorbe et applique correctement les parties qui lui conviennent, donc on peut pratiquement le considérer comme un seed universel.

Pour référence, la licence est Apache 2.0.

Les retours, issues et propositions de bridges pour d’autres outils IA sont les bienvenus.

[kurthong]

Merci d’abord pour cette excellente présentation du projet. C’est aussi un domaine qui m’intéresse.
Vous avez bien structuré les patterns. En lisant l’article, je laisse ce commentaire parce que deux points m’ont intrigué.
Premier point — le coût cumulatif de _lessons/. Si le nombre de lessons s’accumule à 100 puis >500, le coût du grep puis de la lecture intégrale des fichiers augmentera proportionnellement ; dans un projet AI Native, à partir de quel seuil le coût de démarrage de chaque tâche a-t-il commencé à devenir contraignant ? S’il existe des mesures à ce sujet, cela m’intéresserait.
Comme la section d’optimisation de l’index RAG v1.3 semble au final relever de métadonnées Markdown, j’ai l’impression que ce n’est pas une solution fondamentale.

Deuxième point — lors de l’exploitation simultanée de plusieurs agents, l’endroit où un même fichier est chargé en doublon autant de fois qu’il y a d’agents. Le design est basé sur 3 agents, mais si, dans leurs sessions respectives, chacun lit AGENTS.md + rules.md + architecture.md + STATE.md + lessons, est-ce que l’objectif de répartition des tokens ne finit pas au contraire par être multiplié ? Je serais curieux de savoir comment vous avez abordé ce point, ou comment vous comptez le résoudre.

[soliestre]

La réponse ci-dessus est ce que j’ai indiqué directement dans le prompt lorsque je faisais du seed harness engineering, en répondant de mémoire sur ce dont j’étais certain,
et le détail précis de la manière de gérer l’accumulation concrète des lessons relève d’une partie que l’agent a lui-même examinée et enrichie avec des détails au cours du processus de build du seed pour l’intégrer, (une partie déjà avancée dans le projet sur lequel on travaillait avant la distillation en seed.)
Comme il me semblait plus pertinent de demander à l’agent qui a consolidé le seed, et qui connaît bien la configuration réelle, plutôt que de répondre moi-même directement, je lui ai demandé son avis sur les questions-réponses ci-dessus une fois rentré chez moi.

Voici la réponse qu’il a synthétisée :

1. grep par tags — recherche restreinte aux tags liés au contexte de travail, pas de lecture intégrale de l’ensemble des lessons.
2. Index _lessons/README.md — premier filtrage avant le grep avec le titre, les tags et un résumé d’une ligne.
3. Promotion des patterns — les lessons récurrents sont stabilisés dans docs/troubleshooting/, avec une régulation naturelle via un plafond de dossier d’indexation de plus de 50 entrées.

Pour la Q2, c’est dans la même logique :

• l’exploitation en concurrent a pour objectif principal non pas d’économiser des tokens, mais d’éviter les conflits et la dérive des règles.

C’est ce qu’il dit.

Si l’objectif est de répartir les tokens, alors la méthode que j’ai donnée plus haut en exemple serait effectivement le bon pattern.

[soliestre]

En examinant les projets sur lesquels je travaille actuellement, j’ai constaté que le maximum de lessons était de 16.
Et comme j’étiquette aussi la partie impact ainsi que la severity, cela devrait permettre d’absorber une certaine accumulation,
mais je pense qu’il faudra tout de même prévoir un plan pour le cas où cela s’accumulerait davantage.

Dans mon cas, je ne fais pas tourner de tests séparés sur le seed,
et comme je l’applique et l’ajuste en l’utilisant sur de vrais projets en cours de développement, plutôt que sur des projets de démonstration, il n’existe pas de données de mesure distinctes.
La partie optimisation de l’index RAG est, pour le moment, appliquée à ce niveau parce que la cible est un repo de documentation de développement principalement en Markdown.
(* Cette partie a été mise en place dans l’optique d’une optimisation lors de l’intégration d’un repo de documentation de développement dans Claude Project.)

Concernant le deuxième point, en pratique je ne recommande pas vraiment une exploitation simultanée en temps réel.
L’hypothèse de base est d’utiliser le modèle le plus efficace selon l’objectif,
et en dehors de cela, on peut les utiliser en parallèle lorsqu’ils travaillent clairement sur des parties différentes.
Par exemple, on peut d’abord confier à Claude le rôle de PM pour planifier la répartition du travail,
puis faire tourner en parallèle FE et BE respectivement sur Antigravity et Codex,
et ensuite le PM agrège les résultats avant de relancer la planification suivante.

Et pour l’instant, comme je ne suis pas dans une situation où je dois économiser mes tokens, je fais tout tourner sur des modèles haut de gamme dans le master seed,
et la répartition des tokens est abordée sous l’angle d’une extension horizontale, en choisissant pour chaque plateforme d’agent une offre au bon rapport qualité-prix, puis en souscrivant de la même manière à des offres rentables sur d’autres plateformes supplémentaires.
Si l’objectif est d’économiser les tokens de manière absolue, je n’aurais pas tendance à recommander l’usage de ce seed à l’heure actuelle.

[soliestre]

À titre de référence, la limite de capacité pour les fichiers de Claude Project (connaissances du projet) est d’environ 10 Mo, donc le dépôt doit nécessairement être principalement composé de texte.
Bien sûr, il est possible d’exclure certains fichiers via l’interface de Claude Project, donc cela peut aller si les fichiers sont séparés par dossier ou s’ils sont peu nombreux.