Lass es seinen Käfig mit eigenen Händen bauen.
Du behältst eines— die Freigabe.

Auch ein Harness ist Code

DELEGATE · 2026

Die fünf Dateien aus Teil 02 musst du nicht von Hand erstellen. Harness-Bauteile sind Textdateien und Shellskripte; genau deren Herstellung beherrscht die Maschine. Auch die meisten untersuchten Harnesses entstanden so: Ein Mensch bestimmte die Richtung, die Maschine baute Dateien, ein Mensch prüfte sie.

Doch die Reihenfolge entscheidet. Auf ein unvermitteltes „Bau mir einen Harness“ erfindet die Maschine ein plausibles Gerüst aus anderswo gesehenen Mustern. Ein aus Vermutungen gebauter Harness ist gefährlicher als solcher Code: Ein Codefehler beschädigt eine Funktion, ein Regelfehler führt jede künftige Session in die Irre. Dazu gibt es Zahlen. Vollständig automatisch erzeugte Regelwerke senkten laut einer Messung die Leistung um 3%, weil sie nur Allgemeinplätze wie „Halte den Code sauber“ enthielten: Platzverbrauch ohne Signal. Gute Regeln entstehen aus den Fehlererfahrungen dieses Repositories. Deshalb ist die Reihenfolge verbindlich: erst messen, was vorhanden ist; dann einen Vorschlag als Tabelle statt Dateien erhalten; menschliche Freigabe; erst danach bauen lassen.

Auftragsbeispiele

DELEGATE · 2026

Erstaufbau: „Erfasse die Struktur und Risikostellen dieses Repositories tatsächlich. Schlage auf dieser Grundlage ① einen Entwurf von sechzig Zeilen für CLAUDE.md und ② eine Agentenliste mit Rollen, gewährten und entzogenen Werkzeugen sowie Modellklassen vor. Erstelle noch keine Dateien, zeige nur Tabellen.“ Der letzte Satz ist entscheidend. Wer Vorschlag und Ausführung trennt, schafft Platz für Prüfung.

Prüf-Gate: „Erstelle einen Skill, der vor jeder Fertigmeldung Typprüfung, Tests und Build verlangt, sowie einen Git-Hook, der dieselben drei Stufen vor dem Push ausführt und bei Fehlern blockiert. Baue danach absichtlich einen Typfehler ein, prüfe durch Ausführung, ob der Hook den Push tatsächlich verweigert, und zeige die Ausgabe.“ Die gerade gebaute Schutzvorrichtung wird sofort probeweise ausgelöst. Diese Disziplin entstand, nachdem in mehreren Werkstätten gebaute, aber nie ausgelöste Vorrichtungen gefunden wurden.

Übertragung: „Passe den Skill zur Fertigstellungsprüfung jenes Projekts an dieses Repository an. Notiere im Dateikopf die ursprüngliche Quelle und deine Änderungen.“ Solche Herkunftsangaben stehen tatsächlich in den untersuchten Skripten. So bleibt die Abstammung geprüfter Bauteile nachvollziehbar.

Und der gemeinsame Abschluss jedes Auftrags: „Melde nicht nur, dass du es gebaut hast. Füge die Ausgabe einer tatsächlichen Funktionsprüfung bei.“ Dieser Satz ist die halbe Anweisung.

Die Freigabe nicht abgeben

DELEGATE · 2026

Auch bei delegiertem Harness-Bau darf eines nicht delegiert werden: die Freigabe. Die größte untersuchte Werkstatt verankert das strukturell. Versucht die Maschine den Harness-Ordner direkt zu bearbeiten, blockiert ein Hook und erzwingt die Übergabe an einen zuständigen Arbeiter. Regeländerungen müssen durch einen Vorschlagsordner und werden ohne Nutzerfreigabe nicht übernommen. Das Tier darf den Käfig bauen. Den Schlüssel hält ein Mensch.

Die Prüfung für Anfänger ist nicht aufwendig. Öffne die entstandenen Dateien selbst. Lies sie vollständig. Kopiere unverständliche Zeilen und frage: „Was tut diese Zeile? Was passiert ohne sie?“ Ist die Antwort unbefriedigend, lass sie entfernen. Nur gelesene und verstandene Regeln sind deine Regeln. Unverstandene Regeln gehören der Maschine. Sie sind Dekoration, kein Harness.

Auch der Umfang braucht Freigabe. In Maschinenhand wächst ein Harness leicht aus: zehn Arbeiter und dreißig Skills an einem Tag sind keine Kunst. Die Bestandsaufnahme lehrt das Gegenteil. Beginne klein und ergänze bei jedem Vorfall ein Bauteil. Wie Teil 04 zeigt, sind die meisten Teile eines guten Harness Narben wirklicher Vorfälle. Ein ohne Narben gewachsener Harness passt nicht zum Körper.

Die Größe folgt dem Risiko — auch Abwesenheit ist Entwurf

DELEGATE · 2026

Die Harness-Größen der neun Werkstätten folgen ihren Risiken. Der Zahlungsdienst mit echten Geldflüssen hat allein siebenundfünfzig Sensoren: Zahlungsidempotenz, atomare Rückerstattung und Geheimnisabfluss sind alle instrumentiert. Eine statische Werbeseite besitzt dagegen nur einen Hook, der direkt nach Dateiänderungen Typen prüft. Beides ist richtig. Ein Harness kostet tatsächlich: Mehr Kontrollposten verlangsamen jeden Commit. Ein überdimensionierter Harness bei geringem Risiko schafft Reibung statt Sicherheit.

Am eindrücklichsten war eine Dokumentzeile bei einem internen Werkzeug: „Null Agenten, null Hooks. Bewusst entfernt. Nutzerentscheidung.“ Keine Bauteile zu haben ist etwas völlig anderes, als sich gegen sie zu entscheiden und das festzuhalten. Letzteres verhindert sogar den Fehlschluss der nächsten Session: „Warum gibt es hier keine Agenten? Ich sollte welche anlegen.“ Abwesenheit zu dokumentieren ist ebenfalls Harness-Arbeit.

Bestimme die Anfangsgröße deshalb so: Was ist das Teuerste, das dieses Repository beschädigen kann? Geld, Ruf oder deinen Abend? Baue nur so viel, wie diese Antwort verlangt. Den Rest ergänzt du, wenn ein Vorfall mit seiner Rechnung eintrifft.