Hooks und Skripte: Deinen Workflow automatisieren

Überblick

Hooks führen Skripte automatisch zu definierten Momenten aus, sodass das Richtige passiert, ob sich jemand daran erinnert oder nicht. Claude Code hat eigene Lifecycle-Hooks, die rund um die Aktionen des Agents feuern, und Git hat Hooks, die rund um Commits und Pushes feuern. Der klassische, wertvollste Einsatz ist ein Quality Gate, das deinen Linter, deinen Typechecker und deine Tests ausführt, bevor Code deinen Rechner verlassen kann, sodass eine Regression physisch nicht in dein Repo oder die Produktion gelangen kann. Diese Lektion verdrahtet beide mit echter, lauffähiger Konfiguration.

Was du lernst

Du lernst, was ein Hook ist, die Lifecycle-Events, in die Claude Code dich hooken lässt, wie du einen Hook in settings.json konfigurierst, wie sich das von einem Git-Pre-Push-Hook unterscheidet und wie du ein Quality Gate zusammenstellst, das dein Projekt automatisch schützt. Du gehst mit einem funktionierenden settings.json-Snippet und einem funktionierenden Git-Hook raus, die du anpassen kannst.

Voraussetzungen

Ein versionskontrolliertes Projekt aus Kurs 1 und mindestens ein Check, den du von der Kommandozeile aus ausführen kannst, etwa ein Lint- oder Test-Skript. Die CLAUDE.md aus Lektion eins hilft auch, denn deine Regel-Datei sollte bereits den Quality-Gate-Befehl benennen, den deine Hooks erzwingen werden. Der Tiefgang dazu, was in das Gate gehört, ist Kurs 5.

Das Problem

Du weisst, dass du die Tests vor dem Pushen laufen lassen solltest. Meistens tust du das. Aber es ist Freitag, die Änderung ist klein, du bist sicher, dass alles in Ordnung ist, und du überspringst es. Das ist der Push, der die Produktion kaputt macht. Sich für Routine-Checks auf menschliche Disziplin zu verlassen scheitert irgendwann, für jeden, weil Aufmerksamkeit endlich ist und der langweilige Check das Erste ist, was wegfällt, wenn du müde oder gehetzt bist. Die Lösung ist nicht mehr Disziplin. Es ist, den Menschen ganz aus der Schleife zu nehmen, damit der Check jedes einzelne Mal automatisch läuft, ohne dass eine Entscheidung beteiligt ist.

Was ein Hook ist

Ein Hook ist ein Befehl, der automatisch läuft, wenn ein bestimmtes Event feuert. Du entscheidest das Event und den Befehl, und wenn der Befehl mit einem Fehler endet, kann die Aktion blockiert werden. Claude Code stellt Lifecycle-Hooks rund um die Arbeit des Agents bereit: bevor ein Tool läuft (PreToolUse), nachdem ein Tool gelaufen ist (PostToolUse), wenn der Agent mit dem Antworten fertig ist (Stop) und andere. Du kannst PostToolUse nutzen, um eine Datei in dem Moment automatisch zu formatieren, in dem der Agent sie bearbeitet, oder PreToolUse, um einen gefährlichen Befehl zu blockieren. Diese Hooks sind deterministisch - es ist das Harness, das dein Skript ausführt, nicht das Modell, das sich dazu entscheidet.

• PreToolUse: läuft vor einem Tool-Aufruf. Nutze ihn, um eine Aktion zu validieren oder zu blockieren, bevor sie passiert.
• PostToolUse: läuft nach einem Tool-Aufruf. Nutze ihn, um eine Datei direkt nach einer Bearbeitung automatisch zu formatieren oder zu linten.
• Stop: läuft, wenn der Agent mit dem Antworten fertig ist. Nutze ihn, um einen finalen Check auszuführen oder dich zu benachrichtigen.
• Hooks sind deterministisches Harness-Verhalten, also feuern sie verlässlich - anders als das Modell höflich zu bitten, sich zu erinnern.

Einen Hook in settings.json verdrahten

Claude-Code-Hooks werden in settings.json konfiguriert, in deinem Projekt unter .claude/settings.json oder in deiner User-Konfiguration. Jeder Hook passt zu einem Event und einem Tool-Muster und führt einen Shell-Befehl aus. Hier ist ein echter PostToolUse-Hook, der jede TypeScript-Datei formatiert und lintet, sobald der Agent sie bearbeitet oder schreibt, sodass die Codebasis zwischen den Runden nie in einem unordentlichen Zustand zurückbleibt.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bun run prettier --write \"$CLAUDE_FILE_PATHS\" && bun run eslint --fix \"$CLAUDE_FILE_PATHS\""
          }
        ]
      }
    ]
  }
}

Der Matcher zielt auf die Tools Edit und Write, und der Befehl läuft gegen die Dateien, die der Agent gerade angefasst hat. Jetzt ist Formatieren nie etwas, woran du oder der Agent denken müssen, weil das Harness es nach jeder Änderung erledigt. Schau in die offiziellen Hooks-Docs für die genauen Umgebungsvariablen und die Matcher-Syntax, da diese mit der Zeit verfeinert werden.

Das Pre-Push-Quality-Gate

Die mit Abstand wertvollste Automation ist ein Gate, das deine volle Check-Suite ausführt, bevor Code deinen Rechner verlassen kann. Der robusteste Ort dafür ist ein Git-Pre-Push-Hook, denn er schützt das Repo unabhängig davon, welcher Agent oder Mensch pusht. Ein Git-Hook ist einfach ein ausführbares Skript im Ordner .git/hooks, oder besser, gemanagt von einem Tool wie Husky, damit es committet und geteilt wird. Wenn ein Check fehlschlägt, endet das Skript mit ungleich null und der Push wird verweigert. Kaputter Code kann dein Repo nicht erreichen, Punkt.

#!/usr/bin/env bash
# .husky/pre-push - blockiert den Push, wenn ein Check fehlschlägt

set -e  # beim ersten fehlschlagenden Befehl stoppen

echo "Running quality gate before push..."
bun run lint
bun run typecheck
bun run test

echo "All checks passed. Pushing."

Mit set -e bricht der erste fehlschlagende Check das Skript ab und der Push passiert nie. Dieses eine Gate verhindert den häufigsten Weg, auf dem Teams Regressionen shippen: jemand überspringt die Tests bei einer "kleinen" Änderung. Es kostet dich eine Minute bei jedem Push und erspart dir den Nachmittag, den ein kaputtes Deploy gekostet hätte.

Agent-Hooks versus Git-Hooks

Diese beiden Systeme ergänzen sich, und zu wissen, welches du nutzt, zählt. Claude-Code-Hooks feuern rund um die Aktionen des Agents und sind grossartig, um jede Bearbeitung sauber zu halten - formatieren beim Schreiben, einen verbotenen Befehl blockieren, dich benachrichtigen, wenn eine lange Aufgabe endet. Git-Hooks feuern rund um Versionskontroll-Events und sind der richtige Ort für das harte Quality Gate, denn sie bewachen das Repo, egal wer oder was den Push anstösst. Das Muster, das die meisten ernsthaften Builder nutzen: Agent-Hooks fürs Aufräumen unterwegs, Git-Hooks für das finale Gate, an dem nichts vorbeikommt. Doppelt hält besser.

Typische Fehler

Die häufigen: dein einziges Quality Gate in einen Agent-Hook stecken, sodass ein manueller Push vom Terminal direkt daran vorbeisegelt; einen Hook schreiben, der so langsam ist, dass jeder Push zur Qual wird und du anfängst, ihn zu umgehen; set -e vergessen, sodass ein fehlschlagender Check ignoriert wird und der Push trotzdem weiterläuft; und deine Git-Hooks nicht committen (nutze Husky), sodass sie nur deinen Rechner schützen und nicht deine Teammitglieder. Ein Gate funktioniert nur, wenn es schnell, geteilt und echt blockierend ist.

Business-ROI

Automation schlägt Disziplin jedes Mal, und die Rechnung ist brutal zu ihren Gunsten. Ein Pre-Push-Gate, das eine Minute dauert, verhindert das kaputte Deploy, das einen Nachmittag Feuerlöschen plus den Vertrauensverlust eines kundensichtbaren Bugs kostet. Den Check als Hook zu codieren heisst, er läuft für jeden, jedes Mal, mit null laufender Aufmerksamkeit. Für eine Gründerin verwandelt das "Ich hoffe, alle denken daran zu testen" in "Kaputter Code kann nicht shippen" - eine Garantie statt eines Wunsches. Gute Automation macht das Richtige zur Voreinstellung, und die Voreinstellung ist das, was Freitag um 18 Uhr tatsächlich passiert.

Checkliste

Du bist bereit weiterzugehen, wenn jedes davon stimmt. Das Gate, das du hier baust, ist das Rückgrat der Qualitätsarbeit in Kurs 5.

• Du kannst drei Claude-Code-Lifecycle-Events benennen und wofür jedes gut ist.
• Du hast einen PostToolUse-Hook, der nach Bearbeitungen formatiert oder lintet.
• Du hast einen Pre-Push-Git-Hook, der Lint, Typecheck und Test ausführt und bei Fehlschlag blockiert.
• Deine Git-Hooks sind committet und geteilt, nicht nur auf deinem Rechner.

Ressourcen

Halt die offizielle Claude-Code-Hooks-Dokumentation als Lesezeichen für die aktuellen Event-Namen, Matcher und Umgebungsvariablen. Husky ist das Standard-Tool für committete, geteilte Git-Hooks - seine Docs führen dich in ein paar Befehlen durch das Setup. Die Test-Lektion in Kurs 5 behandelt genau, was du in das Gate steckst, damit es echte Bugs fängt, ohne langsam zu sein.

Deine Aufgabe

Ergänze einen Pre-Push-Git-Hook in einem echten Projekt, der deine Lint-, Typecheck- und Test-Befehle ausführt und den Push blockiert, wenn einer fehlschlägt. Mach absichtlich einen Test kaputt, versuch zu pushen und sieh zu, wie er verweigert wird. Ergänze dann einen Claude-Code-PostToolUse-Hook, der Dateien nach Bearbeitungen formatiert. Du hast jetzt Automation, die deine Standards erzwingt, statt deines Gedächtnisses.

Nächste Lektion

Dein Agent folgt jetzt Regeln, fährt verpackte Workflows und erzwingt Gates automatisch. Die nächste Lektion verbindet ihn mit der Welt jenseits deiner Dateien: MCP, das Model Context Protocol, das deinem Agent über einen Standard-Stecker Zugang zu Datenbanken, Design-Tools, Diensten und Datenquellen gibt.