Ein Satz von 34 Skills für Claude Code, gebaut für Enterprise-Codebases. Die Idee dahinter: Autonomie entsteht nicht durch bessere Implementierungs-Prompts, sondern dadurch, dass die menschliche Entscheidung aus der Mitte an die Ränder wandert - Spec und Akzeptanzkriterien vorher, Review und Evidence-Paket nachher, dazwischen ein Ledger statt einer Rückfrage. Denn jede Rückfrage mitten in der Umsetzung hat genau zwei Ursachen: fehlender Kontext oder eine Spec, die vorher schon offen war. Vier der Regeln sind als Hooks installierbar und werden damit erzwungen statt erbeten.
Das Problem
Ein Agent, der mitten in der Umsetzung fragt, kostet mehr als die Antwort wert ist: der Lauf steht, und der Mensch muss sich in einen Kontext zurückdenken, den er vor zwei Stunden verlassen hat. Sieht man sich die Fragen einzeln an, haben sie immer dieselben zwei Ursachen. Entweder weiß der Agent nicht, wie dieses Repo Dinge tut, oder die Frage war in der Spec schon offen und wurde nur weitergereicht.
Beides lässt sich vorher erledigen, aber nicht durch längere Prompts. Es braucht Artefakte: eine Karte des Repos mit den Kommandos, die dort wirklich gelten; eine Spec mit Akzeptanzkriterien und Blast Radius; einen Ort, an dem eine Entscheidung landet, die der Agent selbst trifft.
Der unbequeme Teil ist die Durchsetzung. Eine Regel, die als Prosa im Kontextfenster steht, ist ein Vorschlag, und die Befolgung sinkt mit der Sessionlänge - also genau unter der Bedingung, die unbeaufsichtigtes Arbeiten erst herstellt.
Randbedingungen
Jede Skill-Beschreibung ist in jedem Turn geladen: der Satz hat ein Kontextbudget
Keine Annahme über die Repo-Struktur, von NX bis Einzelpaket
Hooks und Permissions gehören ins Ziel-Repo, weil sie dessen Blast Radius prüfen
Keine Abhängigkeit zu fremden Plugins, die sich unter einem ändern können
Entscheidungen
Ledger statt Rückfrage
Der Agent entscheidet und schreibt Entscheidung, Alternative, Begründung und Reversal Cost auf
Anhalten und fragen, wie man es von einem vorsichtigen Kollegen erwartet
Fragen ist nur dann höflich, wenn jemand da ist. Nachts ist es ein Abbruch. Die Entscheidung wandert deshalb in `docs/specs/<id>.assumptions.md` und der Lauf geht weiter; geprüft wird die Liste im Review, wo Prüfen billig ist. Wichtig ist die Reversal Cost in jedem Eintrag: sie sagt dem Menschen, welche Entscheidungen er wirklich ansehen muss und welche er mit einem Satz umdrehen kann.
Hooks statt Prosa
Vier Regeln als installierbare Hooks pro Ziel-Repo
Die Regeln in den Skills beschreiben und darauf vertrauen
Die Regeln, die beim unbeaufsichtigten Arbeiten wehtun, sind genau die, die ein Modell unter Druck aufweicht: nichts außerhalb des Blast Radius anfassen, keine Abkürzung, die ein grünes Gate vortäuscht, keine Behauptung ohne Beleg. Als Hook prüft das der Harness statt des Modells. Installiert wird pro Repo und nicht global, weil ein Hook den Blast Radius genau dieses Repos kennen muss; die mitgelieferte Allowlist lässt einen Lauf durchlaufen, ohne Permissions ganz abzuschalten.
Ein Ort für die geteilten Regeln
Alles Gemeinsame steht in `agentic-guardrails`, alle anderen verweisen per Name
Jeder Skill trägt die Regeln, die er braucht, selbst
Bei 34 Skills ist eine kopierte Regel eine Regel, die in 34 Fassungen auseinanderläuft, und der Agent liest irgendwann zwei widersprüchliche Sätze über dieselbe Sache. Der zweite Grund ist das Kontextbudget: die model-invoked Beschreibungen sind in jedem Turn geladen, zusammen rund 8,4 KB. Was nur einmal dasteht, kostet auch nur einmal.
Die Kommandos lesen statt raten
`repo-cartograph` schreibt Workspace-Art, Gates, Grenzen und Changed-Set-Befehl in eine Map
Eine Repo-Struktur annehmen und `npm test` probieren
Ein geratenes Gate-Kommando ist schlimmer als gar keins: es läuft, es ist grün, und es hat nicht das geprüft, was der Lauf angefasst hat. Die Map wird deshalb einmal erhoben und von allen anderen gelesen - NX, Turborepo, pnpm-, npm- und yarn-Workspaces, Lerna, Rush, Einzelpaket, Polyrepo, Maven, Gradle, .NET, Go, Cargo. Wo es kein Affected-Tooling gibt, greift eine Leiter von `git diff` über die Manifest-Zuordnung bis zu „bei Root-Config läuft alles". Bei Frontend und Backend bekommt jedes Repo seine eigene Map, und die Verbindung dazwischen steht als Seam darin.
Nach jeder Unterbrechung ein Postmortem
`autonomy-postmortem` nimmt jede Unterbrechung auseinander und schreibt eine Zeile in den Trend
Die Frage beantworten und weitermachen
Ohne diesen Schritt bleibt der Satz so autonom wie am Installationstag. Mit ihm entfernt jede Unterbrechung dauerhaft eine ganze Klasse von Unterbrechungen, weil die Ursache dorthin wandert, wo sie hingehört: fehlender Kontext in die Repo-Map oder das Glossar, eine unentschiedene Spec in die Vorlage, mit der die nächste geschrieben wird.
Gebaut
Drei Primitive an genau einer Stelle: Assumption Ledger, Repair Budget, Evidence
Vier Regeln als Hooks, weil Prosa im Kontextfenster nur ein Vorschlag ist
repo-cartograph erkennt die Workspace-Art und schreibt Gates und Grenzen in eine Map, aus der alle anderen lesen
Die Morgen-Review: ein Board für den Überblick, der Eingriff im Gespräch
