Les agents lisent votre code et les fichiers d'instructions de votre dépôt. Contexte rassemble ces fichiers de mémoire avec les notes de projet, le contexte généré et les références.
Pour en savoir plus sur la raison d'être de cette section, lisez Contexte du projet dans la rubrique Concepts. Cette page explique comment le gérer.
Fichiers de mémoire du dépôt
Ouvrir Paramètres → Connaissances → Contexte et consulter la section Sources du dépôt. Coroid lit ces fichiers dans le dépôt connecté :
AGENTS.mdà la racine du dépôt : instructions générales pour les agentsCLAUDE.mdà la racine du dépôt : instructions pour ClaudeGEMINI.mdà la racine du dépôt : instructions pour Gemini.cursor/rules: règles de projet de Cursor, que ce soit le répertoire de.mdcfichiers de règles (y compris les sous-dossiers) ou un seul fichier hérité
On les appelle souvent des fichiers de mémoire. Leur contenu activé est inclus dans le contexte du projet des agents avant le début du travail. Leur nom ne les limite pas à un modèle particulier : les sources activées sont combinées pour les agents de Coroid.
Les fichiers existants s'affichent avec une Modifier action, un compteur estimé de tokens et un sélecteur permettant de contrôler si les agents les reçoivent. Les sources sont activées sauf si vous les désactivez explicitement. Si plusieurs fichiers se répètent ou se contredisent, conservez activées les sources que vous souhaitez que les agents suivent et désactivez les autres.
Enregistrer une modification dans un projet avec un dépôt GitHub ou GitLab connecté ouvre une demande pull request avec cette modification, sur une nouvelle branche à partir de la branche de base du projet pull request. Coroid n'effectue pas de validation sur votre branche par défaut, et les agents lisent la nouvelle version une fois la demande pull request fusionnée. Un projet dont le dépôt est hébergé par Coroid reçoit quant à lui une validation. L'éditeur vous en informe avant l'enregistrement.
Coroid lit les règles de Cursor de la même manière que Cursor les applique :
| Règle | Ce que reçoivent les agents |
|---|---|
alwaysApply: true | La règle complète |
globs ensemble | La règle complète, avec les fichiers auxquels elle s'applique |
Seul un description | Le chemin et la description de la règle, afin que l'agent la lise lorsque c'est pertinent |
| Aucun de ces éléments | Rien : Cursor ne l'applique que lorsqu'on la mentionne |
Un simple .md fichier dans .cursor/rules est ignoré, tout comme Cursor l'ignore. Les règles du
répertoire sont modifiées dans le dépôt, donc cette ligne ne comporte pas d'action Modifier .
Créer signifie que le fichier était absent de la copie de travail du dépôt de Coroid. Si une lecture échoue, la page propose Réessayer; une erreur d'accès ne signifie pas que le fichier est manquant. Vérifiez que le fichier est validé dans la branche du dépôt connecté. Pour l'exécution des tâches, l'agent lit la copie de travail de la tâche, donc les modifications apportées aux fichiers d'instructions sur cette branche s'appliquent à la tâche.
Les fichiers de mémoire activés peuvent importer du Markdown du dépôt grâce à @path, par exemple
@AGENTS.md dans CLAUDE.md ou @docs/conventions.md. Les chemins sont résolus par rapport au
fichier contenant la référence. Coroid gère les imports imbriqués, arrête les boucles,
et inclut chaque fichier ainsi que chaque corps d'instruction identique une seule fois. Les imports dans les exemples de code et les adresses e-mail ne sont pas traités. Les références externes au dépôt ne sont pas chargées, et les imports ne peuvent pas contourner une source de dépôt explicitement désactivée.
Seules les sources listées sont détectées automatiquement. Un import AGENTS.md peut
être inclus via un @ ; son périmètre de répertoire n'est pas inféré.
Contextes d'application
Sous Contextes d'application, conservez les instructions et références stockées dans Coroid. Les notes manuelles et le contexte de projet généré peuvent être activés ou désactivés indépendamment des fichiers du dépôt. Utilisez ces entrées pour les informations qui n'appartiennent pas à Git.
Ajouter du contexte
Sélectionnez Ajouter du contexte et ajoutez une entrée. Chacune comporte un titre et un corps, et peut être modifiée ou supprimée ultérieurement.
Les bonnes entrées sont courtes, spécifiques et durables. Les décisions d'architecture, les conventions de style, les contrats API, les limites de propriété et les interdictions explicites en font partie. Le récit d'intégration et tout ce qui est déjà évident dans le dépôt n'y ont pas leur place.
Gardez les entrées séparées et nommées
Une entrée par sujet, intitulée en fonction de son contenu. « Conventions de gestion des erreurs » et « Modules figés » sont facilement retrouvables ; une seule entrée appelée « Notes » contenant les deux ne l'est pas.
Cela est important car le contexte est chargé sélectivement en fonction du travail en cours — voir Compétences progressives. Des entrées bien séparées permettent de charger la bonne pour la bonne tâche.
Références
En plus des entrées écrites, vous pouvez joindre des références : des liens et des documents qui pointent vers du contenu stocké ailleurs. Utilisez-les lorsque la version officielle se trouve dans une wiki ou un outil de conception et que vous ne souhaitez pas avoir une copie dépassée.
Contexte par tâche
Le contexte du projet s'applique à tout son contenu. Pour le matériel relatif à une tâche précise – un ticket, un rapport client, un document de conception –, attachez-le à cette tâche plutôt qu'au contexte du projet. Une note spécifique à une tâche insérée dans le contexte du projet devient un bruit superflu pour toutes les tâches ultérieures.
Maintenir l'exactitude
Un contexte obsolète est pire qu'un contexte manquant, car les agents le considèrent comme faisant autorité. Lorsqu'une convention change, mettez à jour l'entrée en même temps que le code.
Examiner ce qui existe
Lisez votre contexte occasionnellement comme si vous étiez nouveau. Les entrées s'accumulent, et celles rédigées lors d'une migration terminée il y a un an sont désormais trompeuses.