Wie findet ein KI-Agent die Konventionen eines Projekts?

Ein Projekt schreibt seine Regeln an mehreren Stellen im Repository auf. In der CLAUDE.md steht, welcher Befehl die Tests startet. Unter .claude/agents liegen die Unteragenten des Projekts, daneben seine Skills und seine Kommandos.

Wer das Terminal im Repository öffnet, bekommt das alles ohne Zutun.

Ein Agent, der nachts allein arbeitet, öffnet kein Terminal. Sein Lauf startet im Arbeitsverzeichnis der Aufgabe, also in /home/agent/scratch/<task-id>, und HOME zeigt auf /home/agent.

Der Quelltext liegt woanders. Die Checkout-Aktion des GitLab-Plugins packt ihn nach ~/repos/<projekt>-<ref>/ aus. Claude Code sucht das Projektgedächtnis aber relativ zum Arbeitsverzeichnis. Aus dem Home heraus liegt all das außerhalb seines Blickfelds.

Das kostet zweimal. Der Agent leitet sich die Projektstruktur bei jedem Heartbeat-Lauf neu her, mit frischem Prozess und gedeckeltem Zugbudget. Und die Konventionen des Projekts bleiben für das Ergebnis ohne Wirkung.

Auf Hacker News steht die Frage in ihrer Alltagsform. Unter einem Faden über KI-Nutzung in Entwicklungsteams schreibt lukebitts im August 2026, die Konventionen des Codebestands zu befolgen sei Regel Nummer eins in der claude.md des Teams. Die Erinnerung daran brauche das Modell in der täglichen Arbeit trotzdem regelmäßig.

Der Sub-Run beginnt im Checkout, mit eigenem Rahmen und eigenem Zugbudget

RunSpec trennt deshalb Arbeitsverzeichnis und Home: WorkDir setzt das Verzeichnis des Unterprozesses, HomeDir bleibt HOME. Darauf baut der Sub-Run auf.

Er ist ein geschachtelter Lauf desselben Adapters in derselben Sandbox. Er startet im Checkout und findet dort den Harness des Projekts vollständig vor. Der Agent stößt ihn über die Aktion dev:agent an, ausgeführt wird er vom Daemon.

Was die Plattform zum Prompt des Sub-Runs beiträgt, bleibt absichtlich knapp: das Regelwerk des Projekts soll dominieren. Der Rahmen nennt drei Dinge.

Zielsysteme gibt es keine und pushen darf der Sub-Agent nicht, lokale Commits im Checkout sind in Ordnung. Der Rahmen verlangt Build und Tests des Projekts, bevor etwas als fertig gemeldet wird. Die letzte Nachricht ist der Bericht: Ursache, geänderte Stellen als Datei und Zeile, die Prüfbefehle samt Ergebnis, und was offen blieb.

Für die eigentliche Arbeit fällt das Zugbudget größer aus. Ohne eigenen Wert bekommt ein Sub-Run sechzig Züge und höchstens zweihundert, während für den äußeren Lauf dreißig voreingestellt sind.

Der äußere Agent redet, der innere programmiert

Die Rollenteilung ist der Kern der Sache. Der äußere Lauf triagiert, kommuniziert, committet, stellt den Merge Request und schreibt sein Gedächtnis. Der Sub-Run versteht den Code, ändert ihn und prüft ihn mit Build und Tests.

Dazu erreicht er kein einziges Zielsystem. In seiner Umgebung fehlt COVEY_ACTION_PORT, und damit kommt er an kein Zielsystem, etwa das Ticketsystem oder die Post.

Die Variablen des Daemons selbst bleiben aus dieser Umgebung ebenfalls draußen. COVEY_WS_URL und COVEY_DAEMON_TOKEN würden eine eigene Verbindung zur Control Plane erlauben und damit den Weg zum Broker öffnen; der Adapter filtert sie aus der Umgebung jedes Laufs. Auch die git-Aufrufe, mit denen der Daemon hinterher die Dateiliste holt, laufen so.

Zurück kommt eine Differenz gegen einen Commit

Der Checkout legt ein Git-Repository mit dem Upstream-Stand als Basis-Commit an und markiert ihn mit dem Tag covey-baseline. Gegen diesen Commit meldet der Sub-Run seine Arbeit zurück, als changed_files und deleted. Genau diese beiden Listen erwartet die commit-Aktion des äußeren Agenten.

Gemessen wird gegen einen Commit und nicht gegen einen Schnappschuss von vorher. Der Sub-Agent darf im Checkout lokal committen, und viele Projekte verlangen das in ihrer CLAUDE.md ausdrücklich. Nach einem lokalen Commit zeigt git status im Checkout nichts mehr an. Die Listen sind deshalb kumulativ: sie beschreiben den ganzen Stand gegen Upstream, einschließlich der Arbeit eines früheren Sub-Runs derselben Aufgabe.

Je Checkout läuft höchstens ein Sub-Run. Ein zweiter Auftrag mit demselben Verzeichnis wird abgelehnt, solange der erste arbeitet, mit dem Hinweis, erst dessen Bericht zu lesen. Aufträge in zwei verschiedenen Verzeichnissen laufen dagegen weiter nebeneinander.

Im Mitschnitt bleibt der Sub-Run ein eigener Block

Die Zeilen des Sub-Runs fließen in denselben Mitschnitt wie die des äußeren Laufs. Jede trägt einen zusätzlichen Schlüssel covey_sub_agent im Objekt, mit dem Verzeichnis und einer Kennung des Laufs. Die Zeitleiste faltet alles unter einer Kennung zu einem Block zusammen, mit Checkout, Auftrag, Status, Werkzeugaufrufen, Zügen, Dauer und Kosten im Kopf.

Die Kosten gehen denselben Weg und damit durch dieselbe Budgetprüfung. Der Deckel wird dabei gröber. Claude Code liefert total_cost_usd erst mit dem Ergebnis, also nach bis zu zweihundert Zügen des Sub-Runs. Für einen Sub-Run bleibt das Budget damit verbindlich, überschreiten kann er es trotzdem.

Repo-Inhalt wird zu Code, der läuft

Der Preis steht an derselben Stelle wie der Nutzen. Die Auto-Discovery, die den Sub-Run brauchbar macht, lädt ausführbare Konfiguration aus dem Repository: Hooks, MCP-Server-Definitionen, Skills, Unteragenten. Zusammen mit --dangerously-skip-permissions heißt das, Repo-Inhalt ist Code, der in der Sandbox läuft. Der äußere Lauf im Home hat das nie getan.

Die Zielsysteme bleiben sauber außer Reichweite. In Reichweite bleiben drei Dinge: der gebrokerte LLM-Schlüssel, das Netz innerhalb der Egress-Allowlist und das Home des Agenten mit seiner Wiki-Arbeitskopie und den übrigen Checkouts.

Im Juli 2026 stand auf Hacker News der Bericht über ein Bewerbungsprojekt, in dessen Git-Hook Schadcode saß, mit 482 Punkten. Im Faden hält Groxx fest, ein Clone sei für sich genommen ungefährlich, weil Git-Hooks nicht automatisch installiert werden, und wünscht sich eine Prüfpflicht für Hooks und ausführbare Konfiguration vor dem ersten Lauf. Der Sub-Run tut planmäßig das Gegenteil.

Für Repositories der eigenen Organisation ist das der richtige Handel. Für ein fremdes gehört der Sub-Run hinter eine Freigabepflicht oder ein Verbot über die Guard Rule auf dev:agent, und die Egress-Allowlist gehört eng gezogen. Heute fehlt ein feinerer Schalter, der den Harness ohne Hooks und MCP lädt.