5. Hooks und Automatisierung — was das System erinnert, wenn der Betreiber vergisst

Dies ist Teil 5 der Alice Way-Serie. Teil 4 Skills und Slash-Befehle verdichtete wiederkehrende Geistbewegungen in einzeilige Namen. Dieser Beitrag handelt von der anderen Hälfte — Verfahren auch dann zum Feuern zu bringen, wenn der Betreiber den Namen nicht aufruft.

0. Ein Hook lagert vergesslichen Geist ans System aus

Der Betreiber vergisst. Gestrige Entscheidungen, der Zustand kurz vor dem Öffnen einer neuen Sitzung, die Verifikation, die kurz vor dem Berichten hätte stattfinden sollen — einmal täglich, leicht.

Skills blockieren einen Teil dieses Vergessens — den Namen aufrufen und das Verfahren läuft. Aber wenn der Aufruf selbst vergessen wird, feuert der Skill nicht. Es gibt Momente, in denen selbst ein einziges Wort nicht auftaucht.

Hooks decken diese Momente ab. Ohne auf das Bewusstsein des Betreibers angewiesen zu sein, feuert das System das Verfahren automatisch bei einem bestimmten Ereignis. Es ist der Akt, einen Teil des Geistes des Betreibers ans System auszulagern.

Was es wert ist auszulagern, ist begrenzt: „darf nicht vergessen werden, aber leicht zu vergessen", „Bedingung ist klar genug zum automatischen Urteilen", „Feuerzeitpunkt lässt sich an ein Ereignis knüpfen." Dieser Beitrag ist eine Aufzeichnung der Kriterien für diese Auslagerung und der tatsächlichen Hooks im Betrieb.

Der Hook-Mechanismus selbst ist aus dem Hooks-System von Anthropic Claude Code entlehnt. Dieser Beitrag ist die Aufzeichnung, wie dieser Mechanismus verwendet wird — keine Erfindung davon.

1. Es gibt Momente, in denen das Bewusstsein erlischt

Was der Betreiber am häufigsten vergisst, liegt nicht daran, dass das Verfahren schwer ist. Es liegt daran, dass das Verfahren einen Moment unterbrechen muss, in dem die Aufmerksamkeit anderswo ist.

In jedem dieser Fälle ist der Geist des Betreibers anderswo. Ein Prinzip wie „vergiss nicht" kann das nicht verhindern. Es muss auf Systemebene feuern.

Hooks sind das Auslösegerät. Sie unterbrechen Momente, in denen das Bewusstsein erlischt, und erzwingen das Verfahren.

2. Die Grenze zwischen Skills und Hooks

Diese beiden werden oft verwechselt. Die Kernunterscheidung ist eine — wer ruft es auf.

Ein Skill benötigt die explizite Entscheidung des Betreibers „tue das", um zu feuern. Ein Hook feuert ohne sie. Damit ist der größte Wert eines Hooks — das Verfahren ist auch in Momenten garantiert, in denen der Betreiber nicht bewusst entschieden hat.

Dasselbe Verfahren kann auf beide Arten exponiert werden. /verify kann direkt als Slash-Befehl aufgerufen oder kurz vor einem „fertig"-Bericht automatisch gefeuert werden. Betreiberbewusstes Aufrufen = Skill; System-Auto-Fire = Hook — zwei Eingänge zum selben Verfahren.

3. Promotionskriterien — welche Verfahren gehooked werden

Nicht jedes Verfahren sollte ein Hook werden. Nur die, die alle fünf davon bestehen, verdienen das Auto-Fire-Privileg.

3.1 Hoher Verlust beim Überspringen, leicht zu überspringen

Ein Hook hat kognitive Kosten — das System tut etwas, während der Betreiber es nicht bemerkt. Um diese Kosten zu rechtfertigen, muss der Verlust durch Überspringen groß genug sein. Ein Push ohne Verifikation, eine Sitzung ohne frische Gedächtnissynchronisation — das sind sofort spürbare Verluste. Hook-Territorium.

Komfort-Verfahren bleiben als Skills, nicht als Hooks.

3.2 Feuerbedingung ist ein klares Ereignis

Ein Hook ist an ein bestimmtes Ereignis gebunden. „Sitzungsstart", „vor Tool-Verwendung", „vor dem Senden der Ausgabe", „Sitzungsende" — so etwas. Wenn das Ereignis vage ist — „wenn es sich richtig anfühlt" — ist es kein Hook.

3.3 Die Entscheidung ist automatisch urteilbar

Sobald ein Hook feuert, muss automatisch entscheidbar sein, was zu tun ist. „Wenn die Änderung lint besteht, OK; andernfalls blockieren" — ein klarer Zweig. Verfahren, die zusätzliches Betreiberurteil erfordern, laufen durch Skill-Invokationen, nicht durch Hooks.

3.4 Fehler ist isoliert

Wenn ein Hook fehlschlägt, darf das System als Ganzes nicht brechen. Da Hooks außerhalb des Bewusstseins des Betreibers operieren, werden Fehler nicht sofort bemerkt. Also müssen Fehler in ihrem Einfluss isoliert sein.

3.5 Ausgabe ist ein Signal

Das Ergebnis eines Hooks erreicht den Betreiber als eine Zeile. Klare Signale wie „OK", „blockiert", „Warnung." Lange oder vage Ausgabe macht den Hook zum Rauschen im Blickfeld des Betreibers.

4. Hooks im tatsächlichen Betrieb

Eine Teilmenge der Hooks, auf die ich täglich angewiesen bin.

4.1 SessionStart — beim Sitzungsstart

Im Moment, in dem eine Sitzung startet, wird ein einzeiliger Gedächtnissync-Status ausgegeben. „Memory sync: aktuell" oder „5 Minuten alt — Auffrischung nötig." Der Betreiber liest die eine Zeile und urteilt sofort.

Ohne diesen Hook müsste der Betreiber jedes Mal bewusst prüfen „ist Gedächtnis aktuell." In Momenten, in denen die Aufmerksamkeit anderswo ist, wird die Prüfung vergessen und die Arbeit beginnt einfach so. Dann werden Entscheidungen auf veralteter Grundlage getroffen.

4.2 PreToolUse — kurz vor gefährlichen Befehlen

Feuert kurz vor bestimmten Befehlen wie rm -rf, force push, destruktivem SQL. Entweder Benutzerbestätigung anfragen oder bei Richtlinienverstoß blockieren.

Der Wert dieses Hooks: das System erzwingt einen Moment des „Will ich das wirklich." Den Fluss schneller Ausführung zu unterbrechen ist der eigentliche Punkt.

4.3 PreToolUse → Auto-Fire /verify

Ein Hook, der lint · build · test kurz vor einem „fertig"-Bericht automatisch ausführt. Das System greift genau dann ein, wenn der Betreiber im Begriff ist, „fertiggestellt" zu schreiben, und erzwingt Verifikation. Wenn sie scheitert, wird der Bericht blockiert.

Der Erleichterungsmoment des Betreibers („jetzt ist es fertig") ist der gefährlichste. Der Hook erzwingt eine kurze Pause in dieser Erleichterung.

4.4 Stop — beim Sitzungsschluss

In dem Moment, in dem die Sitzung enden soll, prüft dieser Hook, ob das Arbeitsprotokoll aktualisiert wurde und ob HANDOFF die Informationen enthält, die die nächste Sitzung braucht. Wenn etwas fehlt, wird der Betreiber benachrichtigt.

Ohne diesen Hook schließt der Betreiber einfach im „fertig"-Zustand. Die nächste Sitzung startet mit verlorenem Kontext.

4.5 Der akkumulierte Effekt

Jeder dieser Hooks ist für sich allein ein kleines Verfahren. Aber der akkumulierte Effekt ist groß — das System füllt 5–6 tägliche Momente, in denen das Bewusstsein des Betreibers erlischt. Der Geist des Betreibers kann sich auf Entscheidungen konzentrieren; „Verfahren, die nicht übersprungen werden dürfen" werden vom System gehalten.

5. Designprinzipien

Auf was ich mich beim Hook-Design festgelegt habe.

5.1 Kurz und schnell

Ein Hook schneidet in den Fluss des Betreibers ein. Wenn er nicht kurz ist, bricht der Fluss. Hooks, die mehr als eine Sekunde dauern, sollten asynchron laufen oder klaren Fortschritt zeigen. Wenn der Betreiber zu denken beginnt „warum hat das pausiert," geht der Wert des Hooks ins Negative.

5.2 Ausgabe ist eine Zeile

Wenn der Hook endet, sieht der Betreiber eine Zeile. Detaillierte Logs gehen in eine separate Datei. „Memory sync: aktuell", „Verifikation bestanden: 3 Tests OK", „Blockiert: 2 Lint-Fehler" — diese Form.

5.3 Fehler isoliert

Ein Hook-Fehler darf die Hauptarbeit nicht brechen. Wenn Gedächtnissync fehlschlägt, startet die Sitzung trotzdem (mit Warnung). Wenn der Verifikationshook fehlschlägt, wird der Bericht blockiert, aber die Arbeit bleibt lebendig.

5.4 Umgehbar

Manchmal will der Betreiber absichtlich einen Hook umgehen — Debugging, Ad-hoc-Arbeit. Eine explizite Umgehungsoption muss existieren. Die Umgehung wird protokolliert, aber nicht blockiert.

5.5 Idempotent

Dasselbe Ereignis zweimal zu feuern sollte dasselbe Ergebnis liefern oder zumindest nicht brechen. Hooks werden automatisch gefeuert, also kann doppelte Ereigniszustellung nicht vermieden werden.

6. Was nicht gehooked werden sollte — Fallen

Die Kehrseite der Promotionskriterien.

6.1 Betreiberentscheidungen ersetzen

Ein Hook, der „Code automatisch repariert, wenn er so aussieht", ist gefährlich. Auto-Fix geht oft in eine andere Richtung als beabsichtigt. Hooks sollten bei Benachrichtigung und Blockierung halt machen; Auto-Fix passiert nur, wenn der Betreiber explizit einen Skill aufruft.

6.2 Zu oft feuern

Hooks, die bei jedem Tastendruck oder jedem Dateispeichern feuern, werden zu Rauschen. Die natürliche Häufigkeit des Ereignisses sollte mindestens in der Größenordnung von Minuten liegen. Feuern unterhalb einer Sekunde unterbricht den Fluss des Betreibers.

6.3 Lange Ausgabe

Wenn ein Hook 30 Zeilen Log feuert, begräbt er die Ausgabe der Hauptarbeit. Lange Infos gehen in Dateien; die Konsole bekommt nur eine Signalzeile.

6.4 Fehler, der Hauptarbeit bricht

Wenn Hook-Fehler sich kaskadenweise in den Bruch der Hauptarbeit verwandeln, schaltet der Betreiber den Hook aus. Einmal ausgeschaltet, bleibt er für immer ausgeschaltet. Also ist Fehlerisolation nicht verhandelbar.

7. Skills und Hooks kombinieren

Der Netzwerkeffekt aus Teil 4 — Skills §5 erweitert sich um einen weiteren Schritt, wenn Hooks hinzukommen.

Dasselbe Verfahren auf beide Arten exponiert:

So gepaart — wenn der Betreiber bewusst handelt, der Skill; wenn das Bewusstsein erlischt, der Hook — ist dasselbe Verfahren in jedem Fall garantiert. Entscheidungsbefugnis bleibt beim Betreiber; das Sicherheitsnetz wird vom System gehalten.

Download — Beispiel settings.json

Das Hook-Layout aus diesem Beitrag (SessionStart / UserPromptSubmit / PreToolUse / PostToolUse) sowie eine Berechtigungs-Allow/Deny-Liste, als eine Datei. Einfach herunterladen und <project-root> an das eigene Projekt anpassen.

shasum -a 256 settings.json
# expected: 60b5bf7fec33f92d9ddcc6ab4696747df6bb3dab14e8287b696d45fbd6c1abde

8. Auf ein Prinzip verdichtet

Der Kern von Hook-Design kollabiert auf einen Satz.

„Nur die Verfahren, die der Betreiber wahrscheinlich vergessen wird, werden vom System automatisch gefeuert. Alles andere bleibt als Skill, den der Betreiber aufzurufen wählt."

Wenn das gilt, werden Hooks zu einem Sicherheitsgerät, das Last vom Geist des Betreibers hebt. Wenn es bricht, werden sie zu Rauschen, das die Absicht des Betreibers entführt.

Der nächste Beitrag behandelt die Struktur, in der ein Agent nicht alles allein trägt — Multi-Agent-Delegation, d.h. was an andere Kollaborateure übergeben wird und was man selbst tut.