Les assistants de vos développeurs, tels que Claude Code, Codex et Cursor, ainsi que les agents de Coroid lisent le même AGENTS.md. La plupart de ces instructions servent aux deux : les commandes, les conventions et les limites. La partie qui ne s'applique pas concerne le workflow Git, car Coroid crée lui-même la branche, la validation et la demande de fusion.
Ce que lisent les agents de Coroid
Avant chaque tâche, les agents de Coroid lisent les fichiers de mémoire situés à la racine du dépôt : AGENTS.md, CLAUDE.md, GEMINI.md et les règles de Cursor dans
.cursor/rules. Ils suivent @ les imports, et les instructions identiques sont incluses une seule fois. Choisissez quelles sources les agents reçoivent sous
Paramètres → Connaissances → Contexte. Consultez Contexte du projet.
Une tâche lit les fichiers de son propre checkout, donc une modification apportée à AGENTS.md
applique aux tâches qui démarrent après avoir atteint la branche de base.
Ce qui sert aux deux
Écrivez ces instructions une fois, pour chaque agent :
- Commandes: install, build, test, et le test le plus restreint et utile, comme un seul paquet ou un seul fichier. Vérifiez-les depuis une copie propre du projet, et indiquez le répertoire où les exécuter ainsi que les services nécessaires aux tests.
- Conventions non visibles dans le code: nommage, gestion des erreurs, manière dont les chaînes de caractères sont traduites,quels motifs sont interdits.
- Limites: modules figés, chemins appartenant à une équipe, dépendances à ne pas ajouter, fichiers jamais à modifier manuellement.
Gardez-le bref. Chaque ligne est lue pour chaque tâche, par chaque agent. Liez vers un document plus long plutôt que de le coller, et omettez ce que le code montre déjà.
Ce que fait Coroid lui-même
Les agents de Coroid modifient les fichiers dans un bac à sable. Coroid s'occupe du reste :
| Étape | Dans Coroid |
|---|---|
| Branche | Coroid crée une branche par tâche : feature/coroid-<id>-<title>, ou bugfix/, refactor/, test/ ou docs/ selon le type de travail. Les voies d'un plan utilisent coroid/factory/… |
| Validation | Coroid rédige le message de validation et ajoute des en-têtes de provenance tels que Coroid-Task. Lorsque votre compte connecté est l'auteur, il ajoute Co-authored-by: Coroid <ai@coroid.ai> |
| Envoi | Coroid envoie la branche. Le bac à sable refuse git push, git pull, git fetch et git clone, et ne conserve aucun identifiant pour votre fournisseur. |
| Demande de fusion | Coroid l'ouvre, avec un titre issu de la tâche, et une description qui lie la tâche, ses critères d'acceptation ainsi que les résultats des tests et de la révision. |
Des instructions telles que « travailler sur une ws/ branche», « ouvrir pull request avec
gh pr create» ou « terminer chaque validation par une ligne de co-auteur » ne s'appliquent pas au sein de Coroid. Seuls les fichiers modifiés par un agent quittent le bac à sable ; une branche ou une validation créée là-bas est donc supprimée. Coroid informe ses agents de cela avant même la lecture de vos fichiers d'instructions : ils ignorent ces étapes et suivent le reste.
Rien n'est validé dans votre branche de base : consultez Paramètres du dépôt et de la branche.
Indiquez quelles parties s'appliquent où
Les agents de Coroid ignorent déjà votre workflow Git. Le mentionner dans le fichier aide tous les lecteurs, y compris les personnes concernées, et permet de regrouper en un seul endroit une étape propre à Coroid, comme une vérification à effectuer avant de terminer. Placez une courte section en haut :
## Working in Coroid
When you run inside Coroid, Coroid creates the branch, commits, pushes and
opens the pull request. Change files only, and skip "Git workflow" below.
Before you finish, run `npm run validate`.Ensuite, marquez le workflow local pour ce qu'il est :
## Git workflow (local agents)
- Branch: `ws/<nn>-<name>` from `main`, in your own worktree.
- Commit messages end with your assistant's co-author line.
- Run `npm run check:local`, then open the pull request with `gh pr create`.Les assistants de vos développeurs conservent leur workflow, et personne n'aura à deviner quelles étapes appartiennent à qui.
Vérifications que chaque pull request doit passer
Une vérification écrite uniquement dans AGENTS.md s'exécute lorsqu'un agent décide de la lancer.
Les validations de Coroid ignorent également les hooks Git de votre dépôt, comme Husky ou Pre-commit. Une vérification obligatoire pour chaque modification doit figurer dans
Contrôle qualité sous forme de Commande de dépôt vérification :
- Coroid l'exécute sur les modifications apportées par ses agents.
- Avec les vérifications de pull request activées, elles s'exécutent également sur les demandes de fusion ouvertes par votre équipe, y compris celles créées avec Claude Code, Codex ou Cursor.
Les deux modes de travail respectent alors le même standard. Consultez Politiques et portes de qualité.
Pour les règles anti-slop, un assistant de développeur peut les demander à Coroid via MCP. anti_slop_rules renvoie un extrait précisant les règles du projet pour
AGENTS.md: consultez
Règles anti-slop depuis votre éditeur.
CI qui s'exécute uniquement pour certaines branches
Si votre CI ou la protection des branches ne s'exécute que pour certains noms de branche, ajoutez celles de Coroid :
feature/coroid-*
bugfix/coroid-*
refactor/coroid-*
test/coroid-*
docs/coroid-*
coroid/factory/**Sinon, les demandes de fusion de Coroid seront ouvertes sans les vérifications dont votre équipe dépend.
Un fichier pour chaque outil
Gardez les instructions en un seul endroit, dans AGENTS.md:
- Codex et Cursor lire
AGENTS.md. - Claude Code lit
CLAUDE.md. En fait, ce sera une seule@AGENTS.mdligne, plus tout ce dont Claude Code a besoin. - Cursor lit également ses règles dans
.cursor/rules. Coroid les lit alors que Cursor les applique : voir Contexte du projet.
Coroid lit CLAUDE.md grâce à son mécanisme d'importation et inclut AGENTS.md une fois.
Vérifiez ce que Coroid lit
Sous Paramètres → Connaissances → Contexte, Sources du dépôt liste chaque fichier avec un comptage estimé de tokens et un commutateur. Modifier ouvre un fichier à cet endroit. L'enregistrement ouvre une demande pull request sur un dépôt connecté, afin que la modification suive la même procédure de révision que toute autre.