Ein Repository kann einem Coding-Agenten Produktionsdeployments verbieten und ihm gleichzeitig den Produktionsbefehl samt Zugangsdaten zugänglich lassen. Der Satz vermittelt Absicht, entzieht aber keine Fähigkeit. Tessls vierteiliges Modell ist hilfreich, weil es diese beratende Funktion von Verfahren und Kontrollen mit unterschiedlichem Lade- und Durchsetzungsverhalten trennt.
Es gliedert teamverwaltete Dateien in dauerhaften Kontext, pfadbezogene Regeln, wiederverwendbare Skills und Lifecycle-Hooks. Die konkreten Beispiele verwenden Claude Code, kein universelles Konfigurationsformat. Die Architekturfrage lautet: Welches Wissen muss immer vorliegen, welches Verfahren nur bei Bedarf, und welche gefährliche Operation muss außerhalb des Modellurteils blockiert werden?
Vier Ebenen sind verschiedene Verträge, nicht vier Kopien einer Richtlinie
CLAUDE.md liefert aufgabenübergreifenden Projektkontext: Build-Befehle, Verzeichnisregeln, Architekturgrenzen und Testerwartungen. Der Paketmanager eines Dienstes oder ausschließlich ergänzende Migrationen können dort stehen. Die Wurzeldatei eignet sich eher als Überblick oder Index denn als vollständiges Handbuch sämtlicher Ausnahmen.
Gezielte Regeln unter .claude/rules/ können Anweisungen anhand von Pfadmustern laden. Eine API-Validierungsregel muss bei einer Dokumentationsänderung nicht um Aufmerksamkeit konkurrieren. Eine übergreifende Regel kann Handler oder Migrationen mehrerer Pakete abdecken, ohne denselben Absatz in verschiedene Verzeichnisse zu kopieren.
Wiederverwendbare Fähigkeiten bündeln längere Verfahren in einem Ordner mit SKILL.md, Metadaten, Anweisungen und ergänzenden Skripten oder Referenzen. Der Überblick verweist etwa auf den Release-Prozess, während der Release-Skill dessen geordnete Prüfungen enthält. Claude Code lädt zunächst Namen und Beschreibung; die vollständigen Anweisungen gelangen bei Relevanz oder ausdrücklichem Aufruf in den Kontext.
Hooks verbinden Verhalten über Einstellungen oder verwandte Konfiguration mit Lifecycle-Ereignissen. Vor einer Werkzeugausführung lässt sich eine geplante Operation prüfen, nach einer Änderung formatieren oder validieren und vor dem Abschluss ein Nachweis verlangen. Das ist etwas anderes als eine weitere Anweisung, an die sich das Modell erinnern soll.
Tessls Eigentumsargument: Dieses Wissen wird zu einem versionierten Repository-Asset. Entwickler können Diffs prüfen, Verantwortliche benennen, Änderungen begutachten, schlechte Regeln zurücknehmen und neuen Sitzungen denselben Kontext geben. Das gehostete Modell und die Laufzeit gehören weiterhin zum Verantwortungsbereich des Anbieters. Eigene Dateien bedeuten nicht Eigentum an jedem Durchsetzungsmechanismus.
Dauerhafter Kontext wird teuer, wenn er zur Richtliniendatenbank wächst
Teams beginnen oft mit einer Anweisungsdatei, weil sie Befehlswahl und Benennung unmittelbar verbessert. Dann sammeln sich Sicherheitsregeln, Release-Schritte, Frontend-Konventionen und persönliche Ausnahmen, bis jede Sitzung alles lädt. Ständig vorhandenes Material konkurriert mit Aufgabendetails, Quellcode, Werkzeugergebnissen und Gesprächsverlauf. Mehr Text bedeutet nicht automatisch bessere Befolgung.
Die zitierte Anthropic-Anleitung empfiehlt weniger als 200 Zeilen für CLAUDE.md, einen Verantwortlichen und Reviews wie bei Code. Entscheidend sind Aufmerksamkeit und Wartung, keine an eine Zeilenzahl gebundene Garantie. Auch eine kurze Anweisung kann missverstanden werden; eine wichtige Einschränkung wird nicht dadurch erzwingbar, dass sie weiter oben steht.
Verschachtelte Anweisungsdateien können geladen werden, wenn der Agent auf den betreffenden Teil des Baums zugreift. Pfadregeln behandeln einen anderen Fall: Ein Anliegen erstreckt sich über mehrere Verzeichnisse. Beides reduziert irrelevanten Kontext, verlangt aber Verständnis der tatsächlichen Lade-, Abgleich- und Vorrangregeln der eingesetzten Laufzeit.
Die Einteilung ist funktional: Projektfakten und urteilsabhängige Konventionen gehören in Kontext, wiederholbare mehrstufige Abläufe in Skills, verbotene Aktionen in Berechtigungen, blockierende Prüfungen oder stärkere Isolation. Lange Sitzungen, Widersprüche und feindlicher Text können die Befolgung beeinflussen. Ein Richtliniensatz beweist seine Existenz, nicht seine Durchsetzungsquote.
Ein Hook kann immer auslösen, ohne jede Entscheidung deterministisch zu machen
Das Modell interpretiert dauerhafte Anweisungen, gezielte Regeln und Skill-Verfahren. Ein Hook unterscheidet sich dadurch, dass die Laufzeit ihn am konfigurierten Ereignis startet, statt auf das Erinnern einer Checkliste zu warten. PreToolUse kann den vorgeschlagenen Werkzeugaufruf vor der Ausführung prüfen und bei einem Richtlinienverstoß ein blockierendes Ergebnis zurückgeben.
Wie entschieden wird, bestimmt allerdings der Handler. Befehlshandler führen Skripte aus; Prompt- und Agent-Handler können Modellurteile nutzen. Ein zuverlässig gestarteter Hook kann trotzdem zu einer probabilistischen Schlussfolgerung kommen. Direkt durch Software prüfbare Bedingungen eignen sich eher für befehlsbasierte Kontrollen als für die Meinung eines weiteren Modells.
Bei generierten Dateien erklärt die Anleitung, warum Änderungen unerwünscht sind, während eine zielbewusste Vorabprüfung den verbotenen Schreibzugriff ablehnt. Beim Deployment beschreibt ein Skill den genehmigten Weg, während Berechtigungen oder Hooks die direkte Abkürzung sperren. Erklärung und Barriere ergänzen sich, weil sie verschiedene Probleme lösen.
Berechtigungen erlauben oder verweigern Werkzeuge und Befehle; bei den zitierten Claude-Code-Kontrollen haben passende Verweigerungen Vorrang vor Erlaubnissen. Hooks können komplexere Bedingungen prüfen. Weder ein erlaubtes Werkzeug noch eine erfolgreiche Prüfung bedeutet jedoch uneingeschränkten Betriebssystemzugriff. Eingeschränkte Zugangsdaten, Container, geschützte Branches und schreibgeschützte Mounts bleiben bei schwerwiegenden Folgen relevant.
Auch Automatisierung nach Änderungen braucht Verhältnismäßigkeit. Formatierer oder gezielte Validatoren sind womöglich nach jedem Edit günstig genug, die gesamte Testsuite kann dann aber behindern. Größere Prüfungen passen zu Commits oder zum Abschluss. Ein Stop-Hook darf nicht ohne sinnvollen Fortschritt immer weiter Arbeit verlangen, sonst wird das Gate zur teuren Schleife.
Die Steuerungsebene ist selbst potenziell schädlicher Code
Hooks sind ausführbare Infrastruktur. Ein fehlerhaftes Skript kann Daten offenlegen, legitime Arbeit blockieren oder jedes passende Ereignis verzögern. Repository-Eigentum schafft Wartungsverantwortung, macht unbekannte Konfiguration aber nicht vertrauenswürdig. Workspace-Vertrauen, Review und isolierte Ausführung bleiben notwendig.
Veränderbarkeit schafft ein zusätzliches Grenzproblem. Darf der Agent dieselben Dateien bearbeiten, die ihn einschränken, kann eine Routineänderung eine benachbarte Regel abschwächen oder eine Prüfung deaktivieren. Kritische Einstellungen brauchen stärkere Zuständigkeit und Reviews, geschützte Branches oder schreibgeschützte Ausführungsbedingungen statt Vertrauen in die Bereitschaft des Agenten, eigene Grenzen zu bewahren.
Eine Sperre für Befehlsmuster kann einen gleichwertigen Paket-Task, ein indirektes Skript oder ein anderes Werkzeug mit gleicher Wirkung übersehen. Tests sollten verbotene Aktionen über alternative Wege versuchen, nicht nur das ursprünglich entworfene Beispiel wiederholen. Auch legitime Arbeit braucht Tests: Zu breite Verbote fördern Ausnahmen, Umgehungen oder vollständiges Abschalten.
Nicht vertrauenswürdige Issue-Texte, Dokumentation, Abhängigkeiten und generierte Artefakte können Prompt Injection enthalten. Das Modell könnte diese Anweisungen zusammen mit Repository-Vorgaben interpretieren. Deterministische Berechtigungen und isolierte Ausführung begrenzen daraus entstehende Fähigkeiten. Prosa allein bildet diese Sicherheitsgrenze nicht.
Skills bewahren Verfahren nur, wenn sie gepflegt und aktiviert werden
Skills machen Release-, Migrations-, Abhängigkeits- und Incident-Wissen über den Chat eines einzelnen Entwicklers hinaus überprüfbar. Ein repositoryeigener Validator kann eine deterministische Teilaufgabe erledigen, während der Agent urteilt. Eine durchsuchbare technische Wissensbasis bewahrt unterstützende Entscheidungen und Dokumente; der Skill definiert, wie ausgewähltes Wissen zum Verfahren wird.
Vorhandensein ist keine Aktivierung. Beschreibungen müssen den Einsatzfall erklären; Evaluationen müssen prüfen, ob das richtige Verfahren tatsächlich geladen wird. Ausdrücklicher Aufruf kann bei sensibler Arbeit Mehrdeutigkeit reduzieren. Weil Befehle und Architektur wechseln, sind Verantwortliche, Beispiele und Überprüfungszyklen Wartungsanforderungen, kein optionaler Feinschliff.
Dieselbe Regel in Wurzeldatei, mehreren Pfaddateien und Skills erzeugt konkurrierende Autoritätsversionen. Ein primärer Ort je Fakt mit Links oder kurzen Indizes anderswo erleichtert spätere Reviews. Persönliche und zentral verwaltete Organisationseinstellungen können ebenfalls mit dem Repository kollidieren. Betreiber müssen erkennen können, welche Dateien geladen wurden und welche Regeln oder Rechte eine Aktion beeinflussten.
Portabilität und Governance müssen sich im Verhalten zeigen
Andere Coding-Agenten besitzen ähnliche Anweisungs-, Workflow- und Ereigniskonzepte, aber andere Verzeichnisse und Semantik. Tessls Produktinteresse an wiederverwendbarem Kontext macht konkrete Claude-Code-Pfade nicht zum portablen Standard. Selbst ein gemeinsames Markdown-Format muss Auslösung, Geltungsbereich, Vorrang und Blockierverhalten erhalten, um sinnvolle Portabilität zu bieten.
Wiederholbare Evaluationen sollten sauber starten, dieselben Aufgaben über mehrere Durchläufe stellen und geladene Konfiguration, Werkzeugentscheidungen und Ergebnisse dokumentieren. Sie müssen Befolgung, korrekte Skill-Aktivierung, gesperrte Operationen und gewöhnliche erfolgreiche Arbeit prüfen. Unabhängige Wiederholung ist wichtiger als eine überzeugende Einzelvorführung.
Drei Entwicklungen würden das Modell stärken: praktische Anweisungsevaluationen, Fähigkeitsformate mit präziser laufzeitübergreifender Semantik und Oberflächen, die Rat, garantierte Auslösung und tatsächliche Verweigerung unterscheiden. Protokolle müssen Gründe für erlaubte oder abgelehnte Operationen verständlich machen. Dateizahl und Dokumentationsumfang ersetzen diese Ergebnisse nicht.
Das nützliche Ergebnis ist eine erklärbare Kontrollkarte. Ein anderer Entwickler sollte den entscheidungsleitenden Kontext, das bei Bedarf erscheinende Verfahren und die externe Grenze identifizieren können, die einen folgenreichen Fehler stoppt. Teamverwaltete Dateien machen diese Karte überprüfbar und wiederherstellbar. Sichere Autonomie hängt weiterhin von getesteter Durchsetzung und umgebender Infrastruktur ab.
Quellen und weiterführende Lektüre
Tessls Vier-Ebenen-Modell · Anthropics Steuerungsanleitung · Projektgedächtnis und Laden · Hook-Handler · Werkzeugberechtigungen · Skill-Pakete und Aufruf · Weiterführend: durchsuchbare technische Wissensbasen