MM · Blog
Regelwerk für KI-Agenten

Kettenhemd

Der gemeinsame Harnisch für meine Projekte mit KI-Agenten: eine Quelle für Regeln, Vorlagen und Skripte. Jedes Projekt bekommt ihn als Plugin für Claude Code mit fester Version – was ich in einem Projekt lerne, kommt so in allen an.

Angefangen hat es am 18. Oktober 2026: Jedes meiner Projekte hatte seine eigene Anleitung für die KI, die Kopien liefen auseinander, und die Agenten machten überall dieselben Fehler. Seitdem gibt es eine Quelle. Vor jeder neuen Version prüft ein Agent das ganze Regelwerk auf Widersprüche, und die Projekte holen sie sich über ein Update.

Aktueller Stand

Version 20

Veröffentlicht am · 11 Projekte arbeiten danach

  • Große Dateien verhindern: Der Plan nennt je Datei eine Zuständigkeit (Dateikarte), neue Zuständigkeiten kommen in neue Dateien.
  • Große Dateien lesen: Agenten holen erst einen Umriss (Überschriften bzw. Symbole über einen Sprachserver) und lesen dann nur den nötigen Abschnitt.
  • Mechanische Prüfregeln des Reviewers laufen jetzt als Skript vor dem Review; Skripte melden falsche Aufrufe klarer.

Als Nächstes

  • 21 Titel steht noch nicht fest geplant
Von der Idee bis live

So läuft eine Aufgabe

Sieben Schritte von der Idee bis live. Umrandet sind die Schritte, die nur ich mache; aus dem Prüfen geht es zurück ins Umsetzen, bis der Reviewer zustimmt.
  1. Idee

    Ich erzähle dem Hauptchat, was ich brauche. Ist das Thema noch unklar, erkundet es vorher ein Spike.

  2. Issue

    Der Hauptchat legt eine Aufgabe als GitHub Issue an: Problem, Lösungsvorschlag und prüfbare Kriterien.

  3. Freigabe ich

    Ich setze die Aufgabe auf „bereit“. Vorher fängt kein Agent an.

  4. Umsetzen

    Eine Untersession baut auf einem eigenen Branch, schreibt Tests, die einmal rot waren, und zieht die Doku nach.

  5. Prüfen

    Automatische Code-Review, bei Bedarf eine Sicherheitsprüfung, die volle Testsuite – dann der Reviewer. Fällt er durch, geht es zurück ins Umsetzen, höchstens drei Runden.

  6. Abschluss

    Erst nach bestandenem Review kommt der Stand auf main und geht von selbst auf die Stage.

  7. Live ich

    Auf Prod geht eine Version nur auf mein ausdrückliches Wort.

So arbeiten die Agenten

Rollen

  1. Ich
  2. Hauptchat
    1. Untersession mit Reviewer
    2. Spike endet mit einer Aufgabe
Ich spreche nur mit dem Hauptchat. Er startet für jede freigegebene Aufgabe eine Untersession, die der Reviewer prüft, und für offene Themen einen Spike.
Hauptchat
Die einzige Session, mit der ich spreche. Er nimmt Ideen auf, legt daraus Aufgaben an und schärft sie mit mir.
Für jede freigegebene Aufgabe startet er eine Untersession – selbst setzt er nichts um.
Untersession
Setzt genau eine freigegebene Aufgabe um: Plan, Code, Tests, Doku bis zum Abschluss.
Sie beginnt mit frischem Verlauf; wird er zu lang, schreibt sie eine Übergabe und startet eine frische Nachfolgerin.
Spike
Erkundet ein offenes Thema mit mir: liest, recherchiert, fragt nach.
Er baut nichts und endet mit einer Aufgabe, die ich freigeben kann – oder mit dem Entschluss, es zu lassen.
Reviewer
Ein eigener Agent, der jede Arbeit als erfahrener Entwickler prüft, ohne den Verlauf der Umsetzung zu kennen.
Höchstens drei Runden; ist danach noch etwas offen, entscheide ich.
Was immer gilt

Grundsätze

  1. Aufgaben nur als GitHub Issue. Keine Listen oder Notizen daneben – so findet jede Session denselben Stand, auch die nächste.
  2. Umgesetzt wird nur, was ich freigebe. Agenten legen an, schärfen und fragen nach, fangen aber nicht von selbst an.
  3. Jede Arbeit wird geprüft. Ein Reviewer, höchstens drei Runden; dazu Tests, die einmal rot gewesen sein müssen, bevor sie als grün zählen.
  4. Nachfragen statt raten. Was Geld kostet, von außen sichtbar ist oder Daten betrifft, entscheide ich; übrige Technik entscheidet der Agent und vermerkt es im Issue.
  5. Produktion nur auf mein Wort. Das gilt auch für Kettenhemd selbst: Eine neue Version entsteht nur, wenn ich sie ausrolle.
  6. Wissen an drei Orten. Regeln (wie wir arbeiten), Stand-Doku (wie das System jetzt ist) und Issues (was zu tun ist).
1Issues2Freigabe3Prüfung4Nachfragen5Produktion6Wissen
Stand 11.11.2026

Zahlen

  • 40 s braucht die ganze Testsuite von Kettenhemd im Linux-Container – unter Git Bash auf Windows waren es 36 bis 49 Minuten.
  • 62 → 211 KB Regeltext von Version 1 bis heute; Ziel nach der Bewährung: 130 KB.
  • rund 5.300 $ für rund 960 Sessions in allen Projekten, davon rund 2.300 $ für Kettenhemd selbst.
  • rund 13 % davon entfallen auf den Reviewer.

Zu den Kosten: Ich nutze Claude Code über das Abo Claude Ultra, bezahlt wird also nicht nach Verbrauch. Die Beträge sind der Gegenwert, den Claude Code je Session selbst anzeigt – keine echte Rechnung, aber ein guter Richtwert.

Blogreihe

Beiträge zu Kettenhemd

  1. Ein Kettenhemd für meine Agenten
  2. Wachsen, messen – und der Blick von außen
  3. Umzug nach Linux – und entschlacken
  4. Ein Tag für den Bühnenmonitor – und halb so viele Regeln
  5. Große Dateien, die mein Regelwerk selbst gebaut hat
Neueste zuerst

Verlauf

  1. Version 20

    Große Dateien verhindern: Der Plan nennt je Datei eine Zuständigkeit (Dateikarte), neue Zuständigkeiten kommen in neue Dateien.

    Große Dateien lesen: Agenten holen erst einen Umriss (Überschriften bzw. Symbole über einen Sprachserver) und lesen dann nur den nötigen Abschnitt.

    Mechanische Prüfregeln des Reviewers laufen jetzt als Skript vor dem Review; Skripte melden falsche Aufrufe klarer.

  2. Version 19

    Temporäre Dateien liegen je Session in einem eigenen Ordner – parallele Sessions überschreiben sich keine Kommentare und Review-Urteile mehr.

    Die Stand-Doku wird im selben Commit wie die Änderung mitgezogen statt am Ende nachgetragen; Spielprojekte führen ihren Spielentwurf in fester Gliederung.

    Mechanische Prüfungen wandern aus dem Regeltext in Skripte; Prüfpunkte, die in über 500 Review-Urteilen nie gegriffen haben, sind gestrichen.

  3. Version 18

    Regeltext je Rolle etwa halbiert; neue Regeln nur mit belegtem Vorfall, mechanische Prüfungen wandern aus dem Text in Skripte und Rechte.

    Neue Session-Art Design-Chat: Entwürfe gemeinsam auf einer Design-Fläche gestalten, danach Issue und Umsetzung.

    Denkaufwand und Modell je Rolle einstellbar (Sessions mittel, Reviewer hoch); eigenes Plugin für Spielprojekte.

  4. Version 17

    Alle Agenten-Sessions laufen unter Linux; die Sonderregeln für Windows entfallen.

    Hotfix und Freigabe nach Produktion ohne Sackgassen, die Freigabe nimmt nur noch einen geprüften Stand.

    Konsistenzprüfung: Widersprüche im Wortlaut aufgelöst, ohne neue Pflicht.

  5. Version 16

    Untersessions und Spikes immer auf dem stärksten Modell.

    Vorprüfung günstiger, Schwelle für eigene Issues.

  6. Version 15

    Konsistenzprüfung und Reparaturen an Hinweisen und Skripten.

    Einmalige Sicherheitsprüfung des ganzen Codes vor dem ersten Live-Stand.

  7. Version 14

    Umbau des Arbeitsprozesses: kleiner Kern und Rollenpakete für Hauptchat, Untersession und Spike.

    Staffel: Eine volle Session übergibt an eine frische.

  8. Version 13

    Messbare Kriterien mit Ausgangs- und Zielwert, höchstens drei Versuche je Zielwert.

    Skripte des Plugins sicher auffindbar.

  9. Version 12

    Erste große Konsistenzprüfung: Widersprüche aufgelöst, Kern unter der Grenze.

    Review-Urteile und Kosten aller Sessions an einem Ort.

  10. Version 11

    Kettenhemd kommt als Plugin für Claude Code in die Projekte, mit fester Version.

    Ein eigenes Plugin für den Betrieb.

  11. Version 10

    Hauptchat und Untersession als getrennte Rollen.

    Skripte für feste Abläufe statt Anweisungen im Text.

  12. Version 9

    Der immer geladene Kern schrumpft von rund 49 KB auf höchstens 30.000 Byte.

    Der Rest lädt als Pfadregel erst, wenn eine passende Datei berührt wird.

  13. Version 8

    Plan vor größerer Arbeit, ohne Halt weiterarbeiten, Anhalten nur aus Gründen.

    Querverweise über das ganze Repo abgleichen.

  14. Version 7

    Kleinigkeit: Ohne Werkzeug für die Aufgabenliste entfällt die Liste.

  15. Version 6

    Der Reviewer prüft in fester Rolle als erfahrener Entwickler.

    Regeln für die CI auf eigenen Runnern: ein Commit, ein Testlauf.

  16. Version 5

    Vorlagen für den Steckbrief jedes Projekts und ein Rückkanal zwischen den Projekten.

  17. Version 4

    Reine Doku-Aufgaben laufen wie Code durch den Reviewer; gepusht wird erst nach bestandenem Review.

  18. Version 3

    Eigenes Profil für den Betrieb von Servern, mit Stufen der Selbstständigkeit und eigenem Reviewer.

  19. Version 2

    Kleine Schärfungen: Status beim Schließen, Pfadfilter der CI, der Reviewer läuft im Vordergrund.

  20. Version 1

    Erste Fassung: gemeinsame Regeln für alle Projekte, Aufgaben nur als Issue mit Status und Freigabe, ein gemeinsamer Reviewer.