Einem Agenten nützlichen Repository-Kontext geben

Beginnen Sie mit dem aktuellen Checkout

Ein Agent muss wissen, welches Repository und welchen Branch er ändert. Er muss auch wissen, ob das Arbeitsverzeichnis aufgabenfremde Änderungen enthält. Diese Fakten beeinflussen, was er sicher bearbeiten kann und wie der endgültige Diff zu verstehen ist.

Bitten Sie den Agenten, vor der Implementierung die Projektanweisungen und Paketkonfiguration zu prüfen. Ein aus einem anderen Repository bekannter Befehl kann hier falsch sein. Ein vertrauter Framework-Name belegt weder die installierte Version noch die Projektkonventionen.

Stellen Sie für eine kleine Änderung das relevante Modul, seine Aufrufer, Tests und die Architekturentscheidung bereit. Ergänzen Sie Informationen, wenn die Untersuchung einen konkreten Bedarf zeigt.

Nutzen Sie Repository-Anweisungen für dauerhafte Regeln

Eine Anweisungsdatei kann unterstützte Befehle, Modulgrenzen, Review-Anforderungen und entscheidungspflichtige Aktionen beschreiben. Die AGENTS.md-Konvention bietet Coding-Werkzeugen einen erkennbaren Ort dafür. Werkzeugunterstützung und Rangfolge der Anweisungen können abweichen. Prüfen Sie daher das Verhalten Ihres Werkzeugs.

Bewahren Sie dauerhafte Projektregeln im Repository auf. Beschreiben Sie die aktuelle Aufgabe im Auftrag. Machen Sie die Anweisungsdatei weder zu einer Gesprächschronik noch zu einer Sammlung vorübergehender Pläne.

Eine nützliche Anweisung lautet: „Führen Sie die Autorisierungs-Integrationstests aus, wenn eine Route das Zugriffsverhalten ändert.“ Eine unklare Anweisung lautet: „Achten Sie immer auf Sicherheit.“ Die erste nennt einen Auslöser und eine Aktion, die ein Reviewer prüfen kann.

Gleichen Sie Anweisungen mit dem Code ab

Anweisungen veralten, wenn sich Befehle, Verzeichnisse oder Architektur ändern. Nennt ein Leitfaden ein fehlendes Skript, prüfen Sie die Paketkonfiguration. Behauptet ein Dokument, ein Dienst habe nur Lesezugriff, prüfen Sie die Berechtigungen, bevor Sie sich darauf verlassen.

Dokumentieren Sie den Widerspruch. Nutzen Sie unmittelbare Nachweise zur aktuellen Version, um das Implementierungsverhalten zu verstehen. Verwerfen Sie eine beabsichtigte Richtlinie nicht stillschweigend, weil alter Code dagegen verstößt. Richtlinie und aktuelles Verhalten beantworten unterschiedliche Fragen.

Ein Leitfaden könnte zum Beispiel direkte Schreibzugriffe auf einen gemeinsam genutzten Branch verbieten, während ein altes Skript sie noch ausführt. Die richtige Reaktion ist, die Richtlinie beizubehalten und das Skript zu korrigieren. Vorhandener Code erlaubt nicht, eine verbotene Aktion zu wiederholen.

Halten Sie den Kontext relevant und sicher

Ein vollständiges Repository kann Zugangsdaten, private Testdaten, Kundenexporte und alte Supportlogs enthalten. Repository-Zugriff macht nicht automatisch jede Datei für einen Modelldienst geeignet.

Verwenden Sie freigegebene Werkzeuge und Regeln zur Datenverarbeitung. Schließen Sie Secrets aus dem Kontext aus. Ersetzen Sie Kundenbeispiele nach Möglichkeit durch erfundene Daten. Prüfen Sie neben hochgeladenen Dateien auch angebundene Werkzeuge: Ein Suchkonnektor kann Informationen abrufen, die nie im ursprünglichen Prompt standen.

Eine Repository-Anweisung wie „Lesen Sie keine Secrets“ ist eine nützliche Vorgabe. Sie ersetzt nicht die Begrenzung des Zugriffs auf Secret-Speicher und sensible Verzeichnisse.

Hinterlassen Sie einen nützlichen Eintrag für die nächste Person

Halten Sie zum Abschluss geändertes Verhalten, Prüfung und ungeklärte Grenzen im Pull Request fest. Aktualisieren Sie die dauerhafte Projektdokumentation, wenn sich der unterstützte Ablauf ändert. Kopieren Sie nicht das gesamte Agentenprotokoll ins Repository.

Der Eintrag sollte der Person, die den Code später wartet, helfen, die Arbeit zu wiederholen, ohne ein langes Gespräch rekonstruieren zu müssen. Verlinken Sie maßgebliche Dokumente und halten Sie jede dauerhafte Regel an einer verbindlichen Stelle fest.

Guter Kontext verringert wiederholte Untersuchungen. Er macht Fehler auch leichter erkennbar, weil erwartetes Verhalten und funktionierende Befehle ausdrücklich beschrieben sind.