Die Agenten lesen Ihren Code sowie die Anweisungsdateien des Repositories ein. Kontext vereint diese Speicherdateien mit Projektnoteingaben, generiertem Kontext und Referenzen.
Die Begründung für die hier geltenden Regeln finden Sie unter Projektkontext in den Konzepten. Diese Seite erläutert die Verwaltung desselben.
Repository-Speicherdateien
Öffnen Sie Einstellungen → Wissen → Kontext und schauen Sie unter Repository-Quellen. Coroid liest diese Dateien aus dem verbundenen Repository:
AGENTS.mdim Repository-Stammverzeichnis: allgemeine AgentenanweisungenCLAUDE.mdim Repository-Stammverzeichnis: Claude-AnweisungenGEMINI.mdim Repository-Stammverzeichnis: Gemini-Anweisungen.cursor/rules: die unterstützte Cursor-Regeldatei
Diese werden oft als Speicherdateien bezeichnet. Ihre aktivierten Inhalte werden vor Arbeitsbeginn in den Projektkontext der Agenten einbezogen. Die Namen beschränken sie nicht auf ein bestimmtes Modell: Aktivierte Quellen werden für die Agenten von Coroid kombiniert.
Vorhandene Dateien werden mit einem Bearbeiten Aktion versehen, zeigen eine geschätzte Tokenanzahl sowie einen Schalter zur Steuerung der Übermittlung an die Agenten. Quellen bleiben aktiv, es sei denn, Sie deaktivieren sie explizit. Falls mehrere Dateien übereinstimmen oder sich widersprechen, aktivieren Sie nur die Quellen, denen die Agenten folgen sollen, und deaktivieren Sie die anderen.
Erstellen bedeutet, dass die Datei in der Repository-Version von Coroid nicht vorhanden war. Fällt das Lesen fehl, bietet die Seite Wiederholenan; ein Zugriffsfehler bedeutet nicht zwingend, dass die Datei fehlt. Prüfen Sie, ob die Datei im verbundenen Repository-Branch committet wurde. Für die Aufgabenausführung liest der Agent die jeweilige Repository-Version, sodass Änderungen an den Anweisungsdateien in diesem Branch auch für die Aufgabe gelten.
Aktivierte Speicherdateien können Repository-Markdown über @pathimportieren, zum Beispiel
@AGENTS.md in CLAUDE.md oder @docs/conventions.md.
Die Pfade werden relativ zur Datei mit dem Verweis aufgelöst. Coroid verarbeitet verschachtelte Imports, stoppt Zyklen
und bindet jede Datei sowie jeden identischen Anweisungstext nur einmal ein. Imports innerhalb von Codebeispielen und E-Mail-Adressen werden dabei ausgelassen. Referenzen außerhalb des Repositories werden nicht geladen, und Imports können eine explizit deaktivierte Repository-Quelle nicht umgehen.
Nur die aufgeführten Stammquellen werden automatisch erkannt. Verschachtelte AGENTS.md und
einzelne .cursor/rules/*.mdc Dateien können über einen @ Import einbezogen werden; ihr Verzeichnisumfang wird nicht automatisch erkannt.
App-Kontexte
Unter App-Kontextekönnen Sie Anweisungen und Referenzen in Coroid speichern. Manuelle Notizen sowie generierter Projektkontext können unabhängig von Repository-Dateien aktiviert oder deaktiviert werden. Nutzen Sie diese Einträge für Informationen, die außerhalb von Git gehören.
Kontext hinzufügen
Wählen Sie Kontext hinzufügen aus und fügen Sie einen Eintrag hinzu. Jeder Eintrag enthält einen Titel und Textinhalt und kann später bearbeitet oder entfernt werden.
Gute Einträge sind kurz, spezifisch und langlebig. Architekturentscheidungen, Stilkonventionen, API-Verträge, Zuständigkeitsgrenzen und ausdrückliche Verbote gehören dazu. Onboarding-Narrative sowie alles, was bereits aus dem Repository ersichtlich ist, hingegen nicht.
Einträge getrennt halten und benennen
Ein Eintrag pro Thema, mit einem Titel, der seinen Inhalt beschreibt. „Fehlerbehandlungskonventionen“ und „Gefrorene Module“ sind leicht auffindbar; ein einziger Eintrag namens „Notizen“ mit beiden Inhalten ist es nicht.
Das ist wichtig, weil der Kontext selektiv je nach aktueller Aufgabe geladen wird – siehe Progressive Fähigkeiten. Gut getrennte Einträge sorgen dafür, dass für die jeweilige Aufgabe der richtige Kontext geladen wird.
Referenzen
Neben schriftlichen Einträgen können Sie auch Referenzen anfügen – Links und Dokumente, die auf Material außerhalb des Projekts verweisen. Nutzen Sie diese, wenn die autoritative Version in einer Wiki oder Design-Tool-Anwendung gespeichert ist und Sie keine zweite, veraltete Kopie erstellen möchten.
Kontext pro Aufgabe
Der Projektkontext gilt für alles im Projekt. Für Material, das nur zu einem bestimmten Arbeitsschritt gehört – etwa ein Ticket, ein Kundenbericht oder ein Entwurfsdokument – fügen Sie es stattdessen der jeweiligen Aufgabe hinzu. Ein aufgabenspezifischer Hinweis im Projektkontext wird sonst bei allen zukünftigen Aufgaben als unnötiger Ballast wirken.
Aktualität gewährleisten
Veralteter Kontext ist schlimmer als fehlender Kontext, da die Agenten ihn als autoritativ betrachten. Wenn sich eine Vorgehensweise ändert, aktualisieren Sie den entsprechenden Eintrag im selben Änderungszyklus wie den Code.
Vorhandenen Kontext überprüfen
Lesen Sie Ihren Kontext gelegentlich so, als wären Sie neu im Projekt. Einträge sammeln sich im Laufe der Zeit, und jene aus einer Migration vor einem Jahr können mittlerweile irreführend sein.