Les agents lisent votre dépôt. Cela couvre la plupart de leurs besoins — mais pas les décisions qui résident dans l'esprit des personnes, dans un wiki ou lors d'une conversation datant de deux ans.
Contexte du projet combine les instructions du dépôt avec les directives que vous conservez dans Coroid.
Les instructions du dépôt constituent également du contexte.
Coroid lit les fichiers de mémoire tels que ceux situés à la racine AGENTS.md, CLAUDE.md et
GEMINI.md, ainsi que les règles de Cursor dans .cursor/rules. Les sources activées sont intégrées au contexte du projet de l'agent avant le début du travail. Le répertoire local @ peuvent intégrer d'autres fichiers d'instructions. Les imports répétés, les cycles et les corps d'instructions identiques ne sont inclus qu'une seule fois. Vous n'avez pas besoin de copier ces instructions dans une entrée de contexte d'application.
Dans Paramètres → Connaissances → Contexte, Sources du dépôt contrôle quels fichiers les agents reçoivent, tandis que Contextes d'application contient les notes manuelles et le contexte généré stocké dans Coroid. Les sources sont activées sauf si elles sont désactivées explicitement ; désactivez les instructions chevauchantes ou conflictuelles que vous ne souhaitez pas combiner.
Les instructions du dépôt accompagnent le code dans Git. Les contextes d'application sont utiles pour les directives et références que vous conservez en dehors du dépôt. Tous deux nécessitent une maintenance lorsqu'une convention évolue. Consultez Paramètres du contexte du projet pour connaître les chemins pris en charge, la détection de fichiers et les contrôles.
Ce que Coroid déduit automatiquement
À partir du seul dépôt, les agents peuvent voir :
- les langages, frameworks et bibliothèques utilisés
- la manière dont le projet est construit, testé et exécuté
- les modèles existants — comment les erreurs sont gérées, comment les modules sont structurés, comment les éléments sont nommés
- ce qui dépend de quoi
Vous n'avez pas besoin de documenter tout cela. Le reformuler représente un effort inutile et risque de devenir obsolète par rapport au code, qui constitue de toute façon la source la plus fiable.
Ce qu'ils ne peuvent pas déduire
Le code montre ce que vous avez fait, jamais pourquoi:
- une bibliothèque choisie plutôt qu'une alternative évidente pour une raison toujours valable
- un modèle qui ressemble à une duplication mais qui constitue une séparation délibérée
- un module que personne ne devrait modifier sans consulter une équipe spécifique
- les conventions que vous avez convenues mais pas encore appliquées nulle part
- les contraintes externes au code — conformité, contrats, une migration en cours
C'est ce qui doit figurer dans le contexte du projet. Le test est simple : quelqu'un pourrait-il travailler uniquement à partir du dépôt sans cette information ? Si oui, laissez-la de côté. Si non, notez-la.
Le dépôt indique ce qui
Les agents le lisent pour chaque tâche. Pas besoin de le répéter.
- Langages, frameworks et bibliothèques
- Comment il est construit, testé et exécuté
- Modèles et nomenclatures existants
- Ce qui dépend de quoi
Vous précisez pourquoi
Le contexte du projet contient ce qui existe dans l'esprit des équipes.
- Pourquoi une bibliothèque a été choisie plutôt qu'une alternative évidente
- La duplication qui constitue une interface volontaire
- Modules que personne ne devrait modifier sans l'accord d'une équipe spécifique
- Conventions convenues mais pas encore appliquées
- Contraintes externes : conformité, contrats, migration en cours
Le test : Quelqu'un qui ne consulte que le dépôt pourrait-il résoudre ce problème ? Si oui, ignorez cette instruction. Sinon, notez-le.
Ajouter du contexte
Joignez des documents, politiques et références sous la section Contexte du projet. Les notes d'architecture, registres de décisions, guides de style et contrats API conviennent tous.
Un bon contexte est court et précis. Un guide d'intégration de 40 pages destiné aux humains contient principalement du récit ; les trois paragraphes qui énoncent les contraintes réelles sont ceux qui comptent. Extrayez-les.
Contexte par tâche
Le contexte attaché au projet s'applique à tout. Pour ce qui concerne une partie du travail spécifique — un ticket, un document de conception, un rapport client — attachez-le à la tâche plutôt qu'au projet.
Conservez le contexte du projet pour ce qui reste véritablement stable. Une note spécifique à une tâche dans le contexte du projet devient un bruit parasite pour toutes les tâches ultérieures.
Maintenir l'exactitude
Un contexte obsolète est pire qu'aucun contexte, car les agents le considèrent comme faisant autorité. Lorsqu'une convention évolue, mettez à jour le contexte dans la même modification que le code.
Si vous devez constamment corriger la même chose dans les commentaires de retravail, c'est le signe qu'il manque quelque chose au contexte — ou qu'une information y est erronée.