Die Agenten lesen Ihr Repository. Das deckt den größten Teil dessen ab, was sie benötigen – jedoch nicht die Entscheidungen, die sich im Kopf von Personen, in Wikis oder in Gesprächen aus vor zwei Jahren befinden.
Projektkontext kombiniert Repository-Anweisungen mit den Richtlinien, die Sie in Coroid speichern.
Repository-Anweisungen bilden ebenfalls den Kontext.
Coroid liest Speicherdateien wie die Dateien auf der obersten Ebene AGENTS.md, CLAUDE.md und
GEMINI.md, zusätzlich zu den Regeln von Cursor in .cursor/rules. Aktivierte Quellen werden vor Arbeitsbeginn in den Projektkontext des Agents einbezogen. Repository-spezifisch @ Importe
können weitere Anweisungsdateien einbinden. Wiederholte Importe, Zyklen und identische Anweisungsblöcke werden nur einmal berücksichtigt. Sie müssen diese Anweisungen nicht in einen App-Kontext-Eintrag kopieren.
In Einstellungen → Wissen → Kontext, Repository-Quellen steuern, welche Dateien die Agenten erhalten, während App-Kontexte manuelle Notizen sowie generierte Kontexte enthalten, die in Coroid gespeichert werden. Quellen bleiben aktiv, sofern sie nicht explizit deaktiviert werden; deaktivieren Sie überschneidende oder widersprüchliche Anweisungen, die Sie nicht kombinieren möchten.
Repository-Anweisungen reisen zusammen mit dem Code in Git mit. App-Kontexte eignen sich für Richtlinien und Referenzen, die Sie außerhalb des Repositories aufbewahren. Beide müssen bei Änderungen einer Konvention aktualisiert werden. Siehe Einstellungen zum Projektkontext zu unterstützten Pfaden, Dateierkennung und Steuerungen.
Was Coroid von selbst ermittelt
Allein aus dem Repository können die Agenten Folgendes erkennen:
- die verwendeten Programmiersprachen, Frameworks und Bibliotheken
- wie das Projekt gebaut, getestet und ausgeführt wird
- bestehende Muster – wie Fehler behandelt, Module strukturiert und Dinge benannt werden
- Abhängigkeiten zwischen Elementen
Sie müssen das nicht dokumentieren. Eine erneute Formulierung ist verschwendete Arbeit und birgt die Gefahr, dass der Text im Vergleich zum Code veraltet – schließlich ist der Code die zuverlässigere Quelle.
Was die Agenten nicht erschließen können
Der Code zeigt was Sie getan haben, niemals warum:
- Eine Bibliothek wurde aus einem bestimmten Grund statt einer offensichtlicheren Alternative gewählt – dieser Grund gilt weiterhin.
- Ein Muster, das wie Dopplung aussieht, aber eine bewusste Trennstelle darstellt.
- Ein Modul, das niemand ohne Rücksprache mit einem bestimmten Team bearbeiten sollte.
- Vereinbarungen, auf die man sich geeinigt hat, die aber noch nirgends umgesetzt wurden.
- Einschränkungen außerhalb des Codebestands – Compliance-Vorgaben, Verträge oder ein laufender Migrationsprozess.
Das gehört zum Projektkontext. Der Test ist einfach: Könnte jemand, der nur den Codebestand liest, das herausfinden? Wenn ja, lassen Sie es weg. Wenn nein, notieren Sie es.
Das Repository zeigt an, was
Agenten lesen es bei jeder Aufgabe. Eine Wiederholung ist nicht nötig.
- Sprachen, Frameworks und Bibliotheken
- Wie es gebaut, getestet und ausgeführt wird
- Bestehende Muster und Benennungen
- Abhängigkeiten zwischen Komponenten
Sie fügen den Grund hinzu
Projektkontext enthält das, was nur im Kopf der Beteiligten existiert.
- Warum eine Bibliothek statt einer offensichtlichen Alternative gewählt wurde
- Doppelungen, die bewusst als Schnittstelle dienen
- Module, die ohne Zustimmung des jeweiligen Teams nicht bearbeitet werden dürfen
- Vereinbarte Konventionen, die noch nirgends durchgesetzt sind
- Externe Einschränkungen: Compliance, Verträge, eine laufende Migration
Der Test: Kann jemand, der nur das Repository einsehen kann, das lösen? Wenn ja, lassen Sie es weg. Wenn nein, notieren Sie es.
Kontext hinzufügen
Hängen Sie Dokumente, Richtlinien und Referenzen unter den „Projekt“-Eintrag im Bereich Kontext ein. Architekturnotizen, Entscheidungsprotokolle, Stilrichtlinien und API-Verträge eignen sich dafür ebenfalls.
Guter Kontext ist kurz und präzise. Ein 40-seitiger Onboarding-Leitfaden für Menschen enthält hauptsächlich Erzählungen; die drei Absätze darin, die echte Einschränkungen beschreiben, sind entscheidend. Extrahieren Sie diese.
Aufgabenspezifischer Kontext
Der dem Projekt zugeordnete Kontext gilt für alles. Für Informationen, die nur für einen bestimmten Arbeitsauftrag relevant sind – ein Ticket, ein Entwurfsdokument oder ein Kundenbericht – weisen Sie diesen Kontext der Aufgabe zu.
Speichern Sie den Projektkontext für dauerhaft gültige Informationen. Eine auf ein bestimmtes Task bezogene Notiz im Projektkontext wird bei zukünftigen Tasks jedoch zum Störfaktor.
Transparente Pflege des Kontexts
Veralteter Kontext ist schlimmer als kein Kontext – die Agenten betrachten ihn nämlich als verbindlich. Wenn sich eine Konvention ändert, müssen Sie den Kontext im selben Schritt wie den Code aktualisieren.
Falls Sie immer wieder dieselbe Korrektur in den Rework-Kommentaren vornehmen müssen, deutet das darauf hin, dass dem Kontext etwas fehlt – oder dass darin falsche Angaben enthalten sind.