Squelette de projet multi-agent (reposable entre outils)

Installation en une phrase (l'utilisateur exécute quand vous lui dites "installe cette compétence")

Dépôt source : https://github.com/aduhappy/multi-agent-project-skill. Clonez-le dans le répertoire skills de votre outil pour l'installer (aucune autre dépendance).

Le répertoire skills diffère selon l'outil, choisissez le bon chemin :

Outil	Répertoire skills utilisateur	Répertoire skills projet
ZCode / Codex CLI	`~/.agents/skills/`	`<projet>/.agents/skills/`
Claude Code	`~/.claude/skills/`	`<projet>/.claude/skills/`
Cursor	N/A (utiliser les règles)	`.cursor/rules/` (format moderne) ou `.cursorrules` (legacy)

Principes généraux :

Sous Windows, ~ = %USERPROFILE%.
En cas de doute entre utilisateur et projet, choisir par défaut utilisateur (installé une fois, disponible partout).
Si le répertoire n'existe pas, créez-le d'abord, puis clonez. Une fois le clonage terminé, dites à l'utilisateur d'ouvrir une nouvelle session pour activer cette compétence.

À quoi sert cette compétence

Elle génère à la racine du projet un squelette de collaboration en Markdown pur, indépendant de tout outil — un point d'entrée faisant autorité + plusieurs pointeurs fins + des fiches de tâches autonomes + des règles de fin de tâche. Changez d'outil (Claude / Cursor / Gemini / ZCode / Copilot), l'agent suivant lit la même entrée et reprend le travail du précédent, sans perte de contexte ni écrasement mutuel.

Quatre principes fondamentaux :

Une seule source de vérité : AGENTS.md est l'entrée faisant autorité ; les fichiers de configuration des autres outils (CLAUDE.md / GEMINI.md / .cursorrules / copilot-instructions.md) ne sont que des pointeurs fins de 3 lignes, pointant vers AGENTS.md.
Détails en lien, entrée concise : AGENTS.md tient en 1 à 2 écrans — chaque nouvel agent doit le lire en entier. Les détails sont délégués à des documents spécialisés dans le dossier docs/ ; l'entrée ne contient que des pointeurs.
Markdown pur + chemins relatifs : aucune syntaxe propre à un outil ; pas de rupture lors d'un changement d'outil.
Confiance mais vérification : l'auto-vérification par l'agent ne suffit pas — les livrables clés doivent être validés indépendamment par l'agent principal ou un autre agent (conservation des sommes, limites, nombre d'éléments, ordres de grandeur, cohérence) avant de passer à l'étape suivante. C'est le fondement de la fiabilité des chaînes multi-agent.

Quand déclencher

L'utilisateur dit "nouveau projet / nouveau sujet", "comment organiser la documentation pour faire collaborer l'IA", "comment écrire AGENTS.md", "plusieurs agents en relais".
Dans un projet existant, les agents posent souvent les mêmes questions, ne trouvent pas l'état, écrasent les productions des autres.
L'utilisateur veut solidifier une "expérience de collaboration résumée manuellement" en une structure réutilisable.

Comment utiliser (deux modes)

Mode A : Générer un squelette à partir de zéro

Demandez (en une seule fois, pas au compte-gouttes) : répertoire racine du projet, objectif en une phrase, quels outils IA doivent être compatibles, répertoire de synchronisation cloud (si applicable), sources de données impliquées.
Ajoutez une question sur les contraintes strictes : "Listez les dimensions qui ne doivent pas être mélangées dans ce domaine (définition, unité, système de coordonnées, résolution, période, strate d'âge, etc.). Écrivez-les comme des règles strictes que tous les agents devront respecter." — C'est la règle la plus souvent ignorée mais dont la violation entraîne les erreurs les plus graves.
Copiez AGENTS.md depuis assets/ vers la racine du projet, en remplissant avec les informations fournies par l'utilisateur.
- Règle pour les espaces réservés (important) : remplissez directement ce que l'utilisateur a donné ; pour ce qu'il n'a pas donné, donnez d'abord une valeur par défaut raisonnable (déduite du sujet du projet) avec une brève mention "valeur par défaut, modifiable" ; seuls les détails propres à l'utilisateur qu'il est impossible de déduire raisonnablement (DOI spécifique, mot de passe, identifiant de compte) laissez 【à remplir】. Critère : dans le corps de AGENTS.md, moins il y a de 【à remplir】, mieux c'est ; idéalement 0.
En fonction des outils sélectionnés par l'utilisateur, copiez les fichiers pointeurs fins correspondants (CLAUDE.md, GEMINI.md, copilot-instructions.md, etc.), tous avec le contenu unifié "Se référer à AGENTS.md" ; pour les utilisateurs de Cursor, recommandez .cursor/rules/multi-agent.mdc (format moderne), .cursorrules comme solution de secours legacy. Ne générez pas pour les outils non sélectionnés.
Créez docs/planification_tâches_<sujet>.md (copié depuis assets/planification_tâches_modèle.md). Si le projet a plusieurs fiches de tâches, copiez aussi assets/tâche_README.md (modèle d'index du répertoire des tâches, listant les dépendances et l'état actuel). Chaque fiche de tâche se termine par un bloc 『📋 Prompt de délégation (copier-coller prêt)』 — remplissez les champs de la fiche, l'utilisateur peut copier et coller pour un démarrage à froid de n'importe quel agent, sans avoir à réécrire le texte de délégation à chaque fois. Remplissez ce bloc lors de la création de la fiche.
(Optionnel) Créez selon les besoins : docs/modèle_délégation_tâche.md (copié depuis assets/modèle_délégation_tâche.md, pour que l'agent principal délègue), docs/registre_décisions/ (pour les ADR), docs/glossaire.md (termes du projet). Attention : ce sont des modèles optionnels — pour les petits projets, sautez-les, ne gonflez pas l'entrée.
Déduisez les répertoires des ensembles de données : à partir des sources de données décrites par l'utilisateur, séparez en catégories — un répertoire par catégorie (ex. : l'utilisateur dit "MODIS + Landsat" → créez les répertoires MODIS/ et Landsat/ ; l'utilisateur dit "questionnaire + mesures terrain" → créez les répertoires Questionnaire/ et Mesures/). Dans chaque répertoire d'ensemble de données, placez source.txt (copié depuis assets/source.txt). Ignorez cette étape si aucun source de données n'est clairement définie.
Organisation du code : créez le répertoire scripts/ + scripts/README.md (copié depuis assets/scripts_README.md). Remplissez la liste des scripts existants de l'utilisateur (si applicable), ou laissez vide pour que les agents suivants la remplissent. Copiez également check_handoff.py (depuis assets/check_handoff.py) — le script d'auto-vérification de fin de tâche ; chaque agent exécute python scripts/check_handoff.py à la fin pour valider la mise à jour des §3/§4/STATUS. Dans la règle §5 de AGENTS.md, convenez que "les scripts ne traînent pas à la racine".
Créez STATUS.md (copié depuis assets/STATUS.md) — modèle vide, rempli par le premier agent à la fin avec un transfert incrémental (ce que l'agent a fait, quels fichiers modifiés, pièges rencontrés).
Ajoutez l'environnement et les contraintes de l'utilisateur sous les § Règles strictes et § Conventions de chemins.
Une fois terminé, dites à l'utilisateur : quels fichiers ont été générés, quelles sont les "valeurs par défaut" à confirmer, et quels 【à remplir】 il doit compléter.

Mode B : Diagnostiquer un projet existant

B1 : Réparer un projet mal organisé (zéro documentation ou documentation chaotique)

L'utilisateur a un projet existant mais la collaboration est chaotique — les agents posent des questions répétées, s'écrasent mutuellement, ne trouvent pas l'état. Lisez d'abord le README / toute documentation / structure de répertoire existants, comparez avec § Structure de fichiers et § Sections d'AGENTS.md pour identifier les lacunes, puis donnez une liste complète de réparation (pointeurs fins manquants ? entrée absente ? fiches de tâches non autonomes ? pas de source.txt ? pas de règles de fin de tâche ?). L'utilisateur confirme, puis comblez. Lisez d'abord, modifiez ensuite, ne remplacez jamais directement les fichiers existants.

B2 : Améliorer un projet bien documenté (bonne documentation, seuls les pointeurs fins manquent)

L'utilisateur a déjà une bonne documentation de projet (ex. AI_COLLABORATION_PLAN.md / README.md / wiki détaillé), mais les outils IA ne la lisent pas automatiquement (Codex/Claude lisent AGENTS.md par défaut, ne découvrent pas les noms de fichiers personnalisés). Ajoutez uniquement un AGENTS.md pointeur fin (3 lignes), pointant vers la documentation existante ; puis, en fonction des outils sélectionnés par l'utilisateur, ajoutez les fichiers pointeurs fins correspondants (CLAUDE.md, etc.). Ne modifiez aucun document existant. Critère : une fois ajouté, un nouvel agent arrive → lit AGENTS.md → accède à la documentation existante → obtient le contexte complet, sans que l'utilisateur ait besoin de dire "lis d'abord le fichier XX".

Structure de fichiers (après génération)

<racine du projet>/
├── AGENTS.md                          ← Entrée unique faisant autorité (TL;DR 3 lignes en haut + sept sections, lue par défaut par tous les outils)
├── STATUS.md                          ← Transfert incrémental (ce que l'agent a fait, fichiers modifiés, pièges rencontrés, enregistré à la fin)
├── CLAUDE.md                          ← Pointeur fin → "Se référer à AGENTS.md"
├── GEMINI.md                          ← Pointeur fin (même chose, optionnel)
├── .cursorrules                       ← Pointeur fin (pour Cursor, optionnel)
├── .github/copilot-instructions.md    ← Pointeur fin (pour Copilot, optionnel)
├── docs/
│   ├── planification_tâches_<sujet>.md ← Fiche de tâche autonome (contient la liste "à faire avant livraison" + modèle de suggestion optionnel)
│   ├── tâche_README.md                ← Index du répertoire des tâches (dépendances + tableau d'état, optionnel)
│   ├── modèle_délégation_tâche.md     ← Texte standard de délégation à un agent IA (copier-remplir, optionnel)
│   ├── registre_décisions/            ← Décisions techniques clés (optionnel, voir advanced.md)
│   └── glossaire.md                    ← Termes du projet (optionnel)
├── <nom_ensemble>/                     ← Un répertoire par ensemble de données
│   ├── source.txt                     ← DOI/URL/date/définition/unité
│   └── ...
├── scripts/                            ← Organisation du code (recommandé : scripts pas éparpillés à la racine)
│   ├── README.md                      ← Chaque script en une ligne : quoi/entrée/sortie/auteur
│   └── check_handoff.py               ← Script d'auto-vérification de fin de tâche (exécutez ceci pour valider la mise à jour de §3/§4/STATUS)
└── journal_avancement.md             ← Journal chronologique des changements avec date (optionnel)

Sections d'AGENTS.md (l'ordre reflète la priorité)

Suivez le modèle assets/AGENTS.md pour remplir. En haut, un bloc TL;DR (3 lignes : stade actuel / prochaine étape / blocage) pour qu'un nouvel agent comprenne l'état en un coup d'œil ; en dessous, 8 sections (modèle numéroté 1 à 7, la convention de chemin étant numérotée séparément §5.5 car trop importante pour être mélangée aux règles) :

TL;DR (lecture rapide à l'arrivée) — 3 lignes : stade actuel, prochaine étape, blocage. Mis à jour à chaque fin de tâche. Un nouvel agent n'a pas besoin de lire tout le document pour savoir où on en est.
Étoile polaire en une phrase — quel est l'objectif du projet, pour qui, quel ton (registre, cible de soumission / livraison, ne pas gêner quelle ligne directrice).
Histoire / méthode actuelle — la direction la plus récente fixée + méthode centrale + ce qui a été changé récemment et pourquoi.
Où on en est maintenant — mis à jour à chaque fin de tâche, 1 à 5 instantanés cumulatifs avec date. C'est le point de transfert le plus critique pour la relève. Les détails incrémentaux descendent dans STATUS.md ; cette section ne garde que l'état cumulé.
Tableau des tâches — [ ]/[x] + responsable + dépendances (T1→T2, quelles tâches parallélisables) + risques connus.
Règles strictes / conventions — ce qui entraînerait une reprise : appels à l'environnement, règles de traçage / de données, nommage, définition, règles de fin de tâche. Inclure "Un nouvel agent (y compris sous-agent) doit, en arrivant, lire d'abord AGENTS.md avant d'agir". 5.5. Conventions de chemins — où vont les gros fichiers, où reviennent les petits artefacts (éviter les collisions entre agents, éviter les explosions de synchronisation cloud). Section séparée, à ne pas noyer dans les règles strictes.
Pointeurs de lecture approfondie — dans quel document trouver les détails (détails des tâches, registre des décisions, glossaire, index des tâches).
Environnement / outils — comment appeler les outils complets, verrouillage de l'environnement.

Répartition STATUS.md vs §3 d'AGENTS.md (éviter les chevauchements) : STATUS.md enregistre l'incrémental (ce que l'agent a fait dans ce tour, fichiers modifiés, pièges rencontrés) ; §3 d'AGENTS.md enregistre l'instantané cumulé (progression globale actuelle, 1 à 5 lignes). Les deux ne se répètent pas — STATUS.md est "les changements depuis la dernière fois", §3 est "où on en est globalement maintenant".

Tableau de décisions (fortement recommandé, pas seulement avancé) : rassemblez les décisions contraignantes dans un tableau borné, greppable — une ligne par décision : ID | Décision | Valeur / Définition | Raison | Date | Lien preuve | Remplace qui. Placez-le sous le pointeur §6 d'AGENTS.md, ou juste à proximité de §3. Il diffère des ADR libres dans les longues narrations de STATUS : borné (une ligne par décision, toujours lisible), consultable (grep d'un mot-clé trouve immédiatement la ligne faisant autorité), traçable (chaîne de supersedes). C'est le niveau clé pour éviter que les décisions soient "enterrées dans de longs journaux" ou "silencieusement écrasées par un script obsolète". Voir le modèle dans references/advanced.md §1.

Exigences strictes pour la reprise entre outils (7 règles)

Markdown pur + chemins relatifs + noms de fichiers standard — n'utilisez pas de syntaxe propre à un outil, n'encodez pas en dur des chemins absolus.
Données avec source.txt (DOI/URL/date de téléchargement/définition/unité/problèmes connus) — changez de personne ou d'agent, la traçabilité reste possible.
Règles de fin de tâche écrites dans les règles strictes — chaque agent, avant de se retirer, met à jour la § Où on en est maintenant + § Tableau des tâches + écrit/met à jour STATUS.md (transfert incrémental : ce que l'agent a fait dans ce tour, fichiers modifiés, pièges rencontrés, sans répéter l'instantané complet de §3). À la fin, exécutez python scripts/check_handoff.py pour l'auto-vérification — valide que la date de §3 est fraîche, que le TL;DR est rempli, que STATUS.md n'est pas le modèle, que la date de STATUS ≥ date de §3, que les pointeurs fins existent ; inclut également deux avertissements (existence du tableau de décisions, dérive des constantes de définition entre scripts). La transition est jugée acceptable seulement si tout est valide.
Discipline des chemins — "gros fichiers sur le disque de travail, petits artefacts dans le dépôt" "copier, ne pas couper, ne pas toucher aux chemins que d'autres utilisent".
Première action d'un nouvel agent (y compris sous-agent) — lire AGENTS.md (y compris STATUS.md) avant d'agir, ne pas compter sur l'historique de la conversation, ne pas deviner de mémoire. STATUS.md devient de plus en plus long et personne ne le lit en entier — donc toute décision contraignante (définition, liste d'exclusion, paramètre choisi) doit remonter au niveau de AGENTS.md §3 ou du tableau de décisions, un niveau borné, à lire obligatoirement — ne pas rester uniquement dans la longue narration de STATUS. Avant d'extraire/modéliser/reproduire, vérifiez d'abord ce niveau, ne faites pas confiance à un encodage en dur dans un script.
Source unique pour les chiffres clés et les paramètres de définition, éviter la dérive — les chiffres clés (moyenne, pourcentage, superficie, etc.) ne sont écrits qu'à un seul endroit : STATUS.md ou AGENTS.md §3 ; ailleurs, on les cite sans les répéter. Les paramètres de définition / échantillons / listes d'exclusion (quels points utiliser, quels points exclure, quel seuil) de même : extrayez-les dans un unique config (config/paramètres.yaml ou un tableau faisant autorité), tous les scripts le lisent, interdiction d'encoder en dur dans plusieurs scripts — deux scripts avec des encodages différents pour le même ensemble est la source la plus insidieuse d'incidents de relais (auto-vérification ne le détecte pas, vérification de format non plus). Avant de finir, vérifiez la cohérence entre tous les documents et les scripts ; le même chiffre avec plus de 1% d'écart, ou des membres d'un même ensemble différents, est considéré comme un bug, à aligner avant transfert.
Mise au rebut et isolation des artefacts erronés et des scripts obsolètes ensemble — si une production d'un agent est erronée (données, graphique, chiffre), immédiatement :① renommez le répertoire avec le suffixe _DEPRECATED ou placez-le dans un sous-répertoire _abandonné/ ;② dans AGENTS.md §5, en haut de la section Règles strictes, marquez en rouge > ⚠️ 【Abandonné】<chemin> (ne le mettez pas dans §3 — §3 est l'instantané cumulé, la marque de pièce erronée doit être dans la même section que les règles strictes / normes) ;③ mettez à jour l'état de §4 en [x] + mention "abandonné" ;④ mettez à jour STATUS.md pour refléter l'abandon ;⑤ les anciens scripts / méthodes remplacés par une décision sont également retirés — ajoutez en haut du script un commentaire # _DEPRECATED → voir <script/décision faisant autorité>, ne laissez pas un script obsolète attirer le prochain agent. Ne jamais se contenter de dire "n'utilise pas ça" de mémoire — un agent aval qui réutilise silencieusement un artefact erroné, ou qui copie le paramètre d'un script obsolète, est plus fatal qu'aucune production.

💡 Une leçon réelle de relais (d'où viennent ces 3 règles) : Un agent devait retracer une courbe, a copié un ensemble d'échantillons depuis un script obsolète — ce script contenait encore des points aberrants qui auraient dû être exclus, et la décision "exclure ce point" était enfouie dans 600 lignes de STATUS, avec deux scripts ayant des encodages opposés. Résultat : le point a fait chuter le R² de 0,5 à 0,27, et la présentation externe a été annulée. Après coup, trois barrières auraient pu l'arrêter : la décision n'a pas remonté au niveau borné et obligatoire (règle 5), les définitions des ensembles étaient encodées en dur dans plusieurs scripts au lieu d'un unique config (règle 6), et l'ancien script remplacé n'avait pas de marque de retrait (règle 7). Faire confiance à un script obsolète plutôt qu'à l'enregistrement des décisions est la cause racine commune de ce type d'incident.

Flux de travail principal (processus complet de relais agent)

Un cycle de vie typique de passage entre agents comprend 5 étapes explicites. Sauter l'étape ③ "Révision indépendante" est la cause racine de la plupart des contaminations de la chaîne.

① Délégation → ② Exécution + auto-vérification → ③ Révision indépendante → ④ Réception et intégration → ⑤ Transfert enregistré

Détail des étapes

① Délégation (contrôleur → agent exécutant) Utilisez un texte standard (voir modèle ci-dessous ou assets/modèle_délégation_tâche.md) pour préciser : quoi lire, quoi faire, quoi ne pas toucher, où placer les sorties, où noter les doutes.

② Exécution + auto-vérification (agent exécutant) Exécutez la tâche, puis passez la liste DoD (critères d'acceptation) pour confirmer que la sortie est complète, le format correct, aucune erreur.

③ Révision indépendante (contrôleur ou autre agent vérifie les chiffres clés) Ne faites pas confiance à l'auto-vérification — l'agent exécutant peut passer tous les DoD alors que la production est erronée (cela a été prouvé à maintes reprises insuffisant).

Le contrôleur ou un troisième agent vérifie les chiffres clés : conservation (somme entrée ≈ somme sortie ?), limites (hors de portée / pas entièrement rogné ?), nombre d'éléments (lignes/pixels conformes aux prévisions ?), ordre de grandeur (unité décalée de 10³ ?), cohérence (même chiffre cohérent entre documents ?).
Si OK → étape ④ ; sinon → retour à l'agent exécutant pour correction, avec enregistrement ADR.
Critère : "Révision indépendante approuvée" est la porte d'entrée pour l'étape suivante, pas une option.

④ Réception et intégration Placez les artefacts vérifiés à l'emplacement définitif, mettez à jour source.txt (si nouvelles données) et scripts/README.md (si nouveau script).

⑤ Transfert enregistré Mettez à jour AGENTS.md §3 (état actuel) + §4 (tableau des tâches) + écrivez STATUS.md. Garantissez que le prochain agent peut reprendre uniquement avec le Markdown du dépôt.

💡 Pour les chaînes courtes (1 à 2 agents, artefacts simples), l'étape ③ peut être sautée ; pour les productions impactant les conclusions d'un article ou les pipelines aval, obligation de passer les 5 étapes.

Deux niveaux de reprise (indispensables tous les deux)

Reprise dure (dépendance principale) : le Markdown dans le dépôt, indépendant de l'outil, lisible par tout agent / personne. C'est la source de vérité.
Reprise souple (amélioration) : couche mémoire (Cursor memory / Claude memory) pour accélérer la recherche, mais ne laissez pas les conclusions clés vivre uniquement en mémoire — elles doivent être écrites dans le Markdown.

Critère : effacez toutes les couches mémoire, le prochain agent ne doit pouvoir reprendre qu'avec le Markdown du dépôt → acceptable.

Texte standard de délégation à un agent IA

À chaque délégation d'un nouvel agent, commencez par un format unifié — bien plus efficace qu'une rédaction libre. Suivez assets/modèle_délégation_tâche.md :

Veuillez d'abord lire AGENTS.md (y compris STATUS.md pour comprendre l'état actuel). Ne modifiez pas les données brutes () ni le code principal existant (). Cette tâche ne traite que la phase X. Si vous découvrez des points douteux ou de nouveaux problèmes, enregistrez-les dans <document spécifié>, ne les corrigez pas directement. Les sorties doivent être placées dans <chemin spécifié>. Pièges connus de cette tâche : [lister les risques connus] Auto-vérification avant livraison : [conservation / limites / nombre d'éléments / ordre de grandeur…, vérifier un par un]

La valeur fondamentale de ce modèle : permettre à un nouvel agent de savoir immédiatement quoi lire, quoi ne pas toucher, et où signaler un problème lors d'un démarrage à froid. Les deux colonnes "pièges connus" et "auto-vérification" sont des incréments clés validés par l'expérience — elles guident l'agent pour intercepter les types d'erreurs courantes avant de déclarer la tâche terminée, réduisant considérablement le taux de défauts.

Pour les tâches clés impactant les conclusions d'un article ou les pipelines aval, ajoutez en fin de texte l'instruction « prévoir une révision indépendante après livraison » (un exemple avancé figure à la fin du modèle).

Prompt de délégation intégré à la fiche (recommandé) : n'obligez pas l'utilisateur à réécrire ce texte à chaque fois — chaque fiche de tâche intègre en fin un bloc 『📋 Prompt de délégation (copier-coller prêt)』 (voir la fin de T1 dans assets/planification_tâches_modèle.md). Lors de la création de la fiche, remplissez l'objectif / les limites / les entrées-sorties / les pièges connus / l'auto-vérification / la fin de tâche ; l'utilisateur n'a qu'à copier ce bloc et le coller à n'importe quel agent (y compris inter-outils, inter-compétences) pour la délégation, sans aucune rédaction en direct. modèle_délégation_tâche.md n'est qu'une référence pour la signification des champs.

Sections avancées (activer selon les besoins, voir references/advanced.md)

En dehors des sept sections principales, celles-ci sont utiles quand le projet grandit, ne les empilez pas toutes dès le début :

Registre des décisions (ADR) — notez "pourquoi on a abandonné telle méthode", pour empêcher le prochain agent de retomber dans le piège et de remettre en question ce qui a été décidé.
Glossaire — termes / abréviations spécifiques au projet, le nouvel agent n'a pas à deviner.
Journal d'avancement — journal chronologique des changements avec date, plus détaillé que § Où on en est maintenant.
Critères d'acceptation concret — DoD écrit sous forme de commande vérifiable, pas "c'est fait".
Résumé de transfert standard — état actuel / prochaine étape / risques non résolus / chemins de fichiers clés.
Conventions de nommage + idempotence — fichiers de sortie avec _v1/date/système de coordonnées ; scripts réexécutables idempotents (cache pour sauter).
Verrouillage d'environnement — conda env figé dans environment.yml, éviter les dérives lors de la reconstruction sur une autre machine.
Instantané de données / entrées immuables — données brutes en lecture seule avec hash, tout le monde travaille sur des copies.
Exemple rempli d'AGENTS.md — references/example_filled_AGENTS.md, un exemple complet (projet fictif). Remplir en suivant cet exemple est bien plus intuitif qu'un modèle vide.

Rappels personnalisés

Ce squelette provient de projets de recherche réels (multi-agent, multi-ensemble de données, long pipeline, synchronisation cloud). Adaptez-le à votre domaine : un projet purement frontal peut supprimer la partie "disque de travail" des § Conventions de chemins ; un petit projet de script mono-agent peut simplifier le § Tableau des tâches.
Les espaces réservés du modèle sont unifiés en 【à remplir】 ; supprimez-les une fois remplis.
Le contenu des fichiers pointeurs fins est unifié (voir assets/CLAUDE.md), n'écrivez pas de règles différentes dans chacun — cela briserait le principe "une seule source de vérité".
N'écrasez pas un AGENTS.md existant ; en mode B diagnostic, lisez d'abord, modifiez ensuite, comblez par incréments.

aduhappy/multi-agent-project-skill

Qu'est-ce que multi-agent-project-skill ?

Demander à votre IA préférée

Documentation