Claude Code Automatisierung: Hooks, Skills und Rules erklärt

Sie arbeiten jetzt schon eine Weile mit Claude Code. Es liest Ihre Dateien, schreibt Code, führt Befehle aus. Läuft gut. Aber mal ehrlich: Sie machen immer noch Dinge von Hand, die von allein passieren könnten — Code nach jeder Änderung formatieren, gefährliche Befehle prüfen bevor sie laufen, denselben Fünf-Schritte-Deploy-Prozess immer und immer wieder durchklicken.

Claude Code hat drei Systeme, die das für Sie erledigen: Hooks, Skills und Rules. Nur 12% der Setups in unserer Analyse nutzen Hooks, aber die erzielen im Schnitt 6.8/10 — verglichen mit 2.1 ohne. Der Unterschied ist riesig, und die Einrichtung dauert zehn Minuten.

Fangen wir direkt mit etwas Konkretem an.

Ihr erster Hook: Jede Datei automatisch formatieren, die Claude anfasst

Kennen Sie das? Claude bearbeitet eine TypeScript-Datei. Der Code funktioniert, aber die Formatierung stimmt nicht — falsche Einrückung, fehlende Semikolons, was auch immer Ihre Prettier-Config vorschreibt. Sie bitten Claude, das zu korrigieren. Das ist ein verschwendeter Turn.

Stattdessen machen wir es so, dass die Formatierung nach jeder Änderung automatisch passiert.

Erstellen Sie diese Datei unter .claude/hooks/format-on-save.sh:

#!/bin/bash
# Läuft nachdem Claude eine Datei erstellt oder bearbeitet

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.input.file_path // empty')

if [ -z "$FILE" ]; then
  exit 0
fi

# Basierend auf Dateityp formatieren
case "$FILE" in
  *.ts|*.tsx|*.js|*.jsx)
    npx prettier --write "$FILE" 2>/dev/null
    ;;
  *.py)
    ruff format "$FILE" 2>/dev/null
    ;;
  *.go)
    gofmt -w "$FILE" 2>/dev/null
    ;;
esac

Ausführbar machen:

chmod +x .claude/hooks/format-on-save.sh

Jetzt in .claude/settings.json registrieren:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": ".claude/hooks/format-on-save.sh"
      }
    ]
  }
}

Das war's. Wenn Claude das nächste Mal eine Datei bearbeitet, läuft Prettier (oder ruff, oder gofmt) automatisch hinterher. Keine Extra-Prompts, kein manuelles Aufräumen.

Probieren Sie es aus. Bitten Sie Claude, eine einfache Funktion in einer TypeScript-Datei zu erstellen. Schauen Sie auf die Ausgabe — die Datei wird nach der Bearbeitung automatisch formatiert. Sie müssen nie wieder an Formatierung denken.

Was genau sind Hooks, Skills und Rules?

Bevor wir weitermachen, klären wir das Grundkonzept. Die drei verwirren anfangs praktisch jeden, daher hier die einfache Version:

• Hooks führen Code vor oder nach jedem Tool-Aufruf aus. Sie sind automatisch — Sie lösen sie nicht aus, sie feuern einfach. Denken Sie an Event-Listener.
• Skills sind Slash-Befehle, die Sie eintippen. /deploy, /review, /ticket PROJ-123. Jeder verpackt einen mehrstufigen Workflow, den Sie per Name starten können.
• Rules sind Anweisungen, die automatisch geladen werden, je nachdem an welchen Dateien Claude arbeitet. Fasst Claude eine .tsx-Datei an, erscheinen Ihre Frontend-Rules. Berührt es SQL, erscheinen die Datenbank-Rules.

Jetzt schauen wir uns jedes im Detail an.

Hooks: Ihr Sicherheitsnetz und Ihr Autopilot

Ein Hook ist ein Shell-Skript, das Claude Code zu einem bestimmten Zeitpunkt ausführt. Es gibt vier Typen:

• PreToolUse — läuft vor einem Tool-Aufruf. Kann ihn blockieren.
• PostToolUse — läuft nach einem Tool-Aufruf. Kann die Ausgabe transformieren.
• Stop — läuft wenn Claude seinen Turn beendet.
• SessionStart — läuft einmal beim Start der Session.

PostToolUse haben Sie gerade mit dem Formatter gesehen. Jetzt schauen wir uns den wichtigsten an: einen Sicherheits-Guard.

Der PreToolUse-Sicherheits-Guard

Dieser Hook fängt gefährliche Befehle ab, bevor sie ausgeführt werden. Kopieren Sie das in .claude/hooks/pre-tool-guard.sh:

#!/bin/bash
# Destruktive Shell-Befehle blockieren

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool')
COMMAND=$(echo "$INPUT" | jq -r '.input.command // empty')

if [ "$TOOL" = "Bash" ]; then
  if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force|git reset --hard|DROP TABLE'; then
    echo '{"blocked": true, "reason": "Destruktiver Befehl durch Sicherheits-Guard blockiert"}'
    exit 0
  fi
fi

echo '{"blocked": false}'

chmod +x .claude/hooks/pre-tool-guard.sh

In der settings.json registrieren:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": ".claude/hooks/pre-tool-guard.sh"
      }
    ]
  }
}

Ab jetzt: Wenn Claude versucht rm -rf / oder git push --force auszuführen, fängt der Hook es ab, gibt blocked: true zurück, und Claude sieht den Grund. Der Befehl wird nie ausgeführt.

Testen Sie es sofort, auch ohne Claude:

echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Sie sollten {"blocked": true, "reason": "Destruktiver Befehl durch Sicherheits-Guard blockiert"} sehen. Ihr Sicherheitsnetz funktioniert.

SessionStart: Claude von Anfang an orientieren

Dieser Hook läuft einmal beim Öffnen von Claude Code. Er injiziert Kontext, damit Claude sich sofort zurechtfindet:

#!/bin/bash
# .claude/hooks/session-start.sh

echo "## Aktueller Git-Status"
echo "Branch: $(git branch --show-current)"
echo "Letzter Commit: $(git log --oneline -1)"
echo "Geänderte Dateien:"
git status --short
echo ""
echo "## Aktuelle TODOs"
grep -r "TODO\|FIXME\|HACK" src/ --include="*.ts" -l 2>/dev/null | head -10

Jede Session startet damit, dass Claude weiß, auf welchem Branch Sie sind, was der letzte Commit war, und welche Dateien offene TODOs haben. Kein „Auf welchem Branch bin ich?" mehr als Einstiegsfrage.

Skills: Ihre persönlichen Slash-Befehle

Hier wird es richtig spannend. Sie schreiben eine Markdown-Datei, die einen Workflow beschreibt, und sie wird ein Slash-Befehl, den Sie jederzeit tippen können.

Ihr erster Skill: Ein Deploy-Befehl

Erstellen Sie .claude/skills/deploy.md:

---
name: deploy
description: Den aktuellen Branch auf Staging oder Produktion deployen
---

# Deploy-Workflow

1. `npm run build` ausführen um den Build zu verifizieren
2. `npm run test` ausführen um alle Tests zu bestätigen
3. Aktuellen Branch prüfen: `git branch --show-current`
4. Wenn auf `main`:
   - Auf Produktion deployen: `railway up --service production`
   - Health-Check verifizieren: `curl -s https://api.example.com/health`
5. Wenn auf anderem Branch:
   - Auf Staging deployen: `railway up --service staging`
   - Staging-URL zur Überprüfung ausgeben

Immer den Deployment-Status und die URL melden.

Tippen Sie /deploy in Claude Code. Claude baut, testet, prüft den Branch, deployt in die richtige Umgebung und verifiziert den Health-Check. Ein Befehl statt fünf manuelle Schritte.

Ein Code-Review-Skill

Diesen werden Sie jeden Tag nutzen. Speichern Sie ihn als .claude/skills/review.md:

---
name: review
description: Gestagete Änderungen vor dem Commit überprüfen
---

# Code Review

1. `git diff --staged` ausführen um alle Änderungen zu sehen
2. Für jede Datei prüfen:
   - Fehlerbehandlung: Sind async-Operationen in try/catch?
   - Sicherheit: Hartcodierte Secrets, SQL-Injection oder XSS?
   - Typen: Irgendwelche `any` die spezifisch sein sollten?
   - Tests: Haben modifizierte Funktionen Test-Updates?
3. Mechanische Probleme AUTO-FIXEN (Formatierung, fehlende Typen, offensichtliche Bugs)
4. KRITISCHE Issues (muss behoben werden) und INFORMELLE (überlegenswert) melden
5. Wenn keine kritischen Issues: Commit-Message vorschlagen

Tippen Sie /review vor dem Committen, und Claude prüft Ihre Arbeit. Mechanische Probleme werden automatisch behoben. Mehrdeutige Entscheidungen werden markiert, damit Sie entscheiden.

Skills mit Argumenten

Skills können Eingaben annehmen. Speichern Sie als .claude/skills/ticket.md:

---
name: ticket
description: Arbeit an einem bestimmten Ticket beginnen
---

Der Nutzer gibt eine Ticket-ID an (z.B. `/ticket PROJ-123`).

1. Ticket-Details vom Issue-Tracker abrufen
2. Neuen Branch erstellen: `git checkout -b feat/PROJ-123-beschreibung`
3. Relevante Dateien aus dem Ticket lesen
4. Implementierungsplan vorschlagen bevor Code geschrieben wird
5. Auf Genehmigung warten bevor es weitergeht

Tippen Sie /ticket PROJ-123 und Claude liest das Ticket, erstellt einen Branch, findet die relevanten Dateien und schlägt einen Plan vor — alles bevor eine einzige Codezeile geschrieben wird.

Rules: Anweisungen, die zur richtigen Zeit laden

Sie kennen Rules bereits aus dem Setup-Guide. Hier ist, warum sie für Automatisierung so wichtig sind: Sie halten Claudes Kontext sauber und schlank.

Stellen Sie sich vor, Sie haben 200 Zeilen Frontend-Konventionen, 150 Zeilen Backend-Rules und 100 Zeilen Datenbank-Standards. Wenn Sie alle 450 Zeilen in CLAUDE.md packen, lädt Claude alles bei jeder einzelnen Interaktion — selbst wenn Sie nur eine CSS-Datei bearbeiten.

Mit Rules lädt Claude die Frontend-Konventionen nur bei .tsx-Dateien, die Datenbank-Rules nur bei Migrationen, und Sicherheitswarnungen nur bei sensiblen Dateien.

Hier ist eine Sicherheits-Rule, die wirklich zählt:

<!-- .claude/rules/security.md -->
---
globs: [".env*", "*.pem", "*.key", "*secret*", "*credential*"]
---

- Diese Datei NIEMALS in die Versionskontrolle committen
- Den Inhalt dieser Datei NIEMALS loggen
- Diese Werte NIEMALS in Fehlermeldungen oder API-Antworten verwenden
- Wenn diese Datei geändert werden muss: benötigte Änderungen erklären, aber aktuelle Werte nicht anzeigen

Wenn Claude eine Datei berührt, die diesen Mustern entspricht, erscheinen diese Rules automatisch. Bei unverwandtem Code bleiben sie im Hintergrund.

Der Spickzettel: Wann was verwenden

Das ist die Frage, die alle stellen. So entscheiden Sie:

Hook verwenden, wenn die Aktion jedes Mal passieren soll, ohne dass jemand daran denkt. Formatierung beim Speichern. Blockieren gefährlicher Befehle. Loggen jedes Tool-Aufrufs. Wenn ein Mensch sich nicht daran erinnern sollte, ist es ein Hook.

Skill verwenden, wenn Sie einen mehrstufigen Prozess haben, den Sie regelmäßig wiederholen. Deployen. Code reviewen. Neues Ticket starten. Migration schreiben. Wenn Sie eine Checkliste dafür machen würden, ist es ein Skill.

Rule verwenden, wenn die Anweisungen davon abhängen, an welcher Datei Claude arbeitet. Frontend-Konventionen für .tsx-Dateien. SQL-Sicherheit für Migrationen. Sicherheitswarnungen für .env-Dateien. Wenn der Rat lautet „wenn du an X arbeitest, folge diesen Richtlinien", ist es eine Rule.

Alle drei kombinieren: ein Praxisbeispiel

So arbeiten Hooks, Skills und Rules bei einem Datenbank-Migrations-Workflow zusammen:

1. Rule (.claude/rules/database.md) — wenn Claude Migrationsdateien berührt, lädt sie automatisch Ihre Konventionen: parametrisierte Queries, Rollback-Anforderungen, Namenskonventionen.

2. Hook (PreToolUse auf Bash) — wenn Claude einen Migrationsbefehl ausführen will, prüft der Hook, ob eine Rollback-Datei existiert. Kein Rollback? Der Befehl wird blockiert.

3. Skill (/migrate) — ein Slash-Befehl, der die Migrationsdatei aus einem Template erstellt, das passende Rollback generiert, gegen eine Testdatenbank ausführt und das Ergebnis meldet.

Die Rule liefert das Wissen. Der Hook setzt die Regel durch. Der Skill verpackt den Workflow. Jedes Teil macht einen Job, und den gut.

Wenn etwas nicht funktioniert

Falls Ihre Hooks, Skills oder Rules nicht feuern, so debuggen Sie:

# Claude im Verbose-Modus starten um Hook-Ausführung zu sehen
claude --verbose

# Hook unabhängig testen
echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Die üblichen Verdächtigen:

• Hook-Skript ohne Ausführungsberechtigungen. Beheben mit chmod +x .claude/hooks/ihr-hook.sh
• Glob-Muster matcht nicht. **/api/**/*.ts ist etwas anderes als api/**/*.ts. Testen Sie Ihres gegen echte Dateipfade.
• Skill nicht gefunden. Stellen Sie sicher, dass er in .claude/skills/ liegt und der name: im Frontmatter korrekt ist.

Was Sie gebaut haben

Wenn Sie mitgemacht haben, besitzen Sie jetzt:

• Einen Sicherheits-Guard, der destruktive Befehle blockiert bevor sie laufen
• Einen Auto-Formatter, der jede Datei aufräumt, die Claude anfasst
• Einen Deploy-Skill, der Ihren gesamten Deploy-Workflow in einen Befehl packt
• Einen Review-Skill, der Ihren Code prüft bevor Sie committen
• Rules, die die richtigen Konventionen zur richtigen Zeit laden

Die meisten Claude Code Nutzer kommen nie an diesen Punkt. Sie haben gerade eine maßgeschneiderte Entwicklungsumgebung gebaut, die automatisch für Sie arbeitet.

Bereit für mehr? Hier geht es weiter:

• Claude mit Ihren Tools verbinden — MCP-Server, die Claude Ihre Datenbank abfragen, GitHub durchsuchen und Sentry-Fehler abrufen lassen
• Fortgeschrittene Workflow-Muster — Subagents, parallele Ausführung und die Debugging-Muster der Power-User
• Ihr Setup bewerten um zu sehen, wo genau Ihre Automatisierung steht

Häufig gestellte Fragen

Verlangsamen Hooks die Arbeit?

Ein grep-basierter Sicherheits-Guard fügt 10-50 Millisekunden pro Tool-Aufruf hinzu — das merken Sie nicht. Aber ein PostToolUse-Hook, der Prettier startet, fügt 200-500ms pro Bearbeitung hinzu. Halten Sie Hooks schnell. Wenn ein Hook schwere Arbeit erledigen muss, starten Sie den Prozess im Hintergrund, damit Claude nicht wartet.

Kann ich Hooks projektübergreifend teilen?

Ja. Legen Sie geteilte Hooks in ~/.claude/hooks/ ab und referenzieren Sie sie mit absoluten Pfaden in Ihrer globalen ~/.claude/settings.json. Projektspezifische Hooks kommen in .claude/hooks/ mit relativen Pfaden in den Projekteinstellungen.

Was passiert, wenn ein Hook abstürzt?

Claude Code fängt Hook-Fehler ab und macht weiter, als ob der Hook nicht existierte — der Tool-Aufruf läuft normal. Der Fehler erscheint im Verbose-Modus. Das ist Safety-First-Design: Ein kaputter Hook verhindert nie, dass Claude arbeitet. Aber testen Sie Ihre Hooks gründlich — ein kaputter Sicherheits-Guard, der still versagt, ist schlimmer als gar kein Guard.

Kann ein Skill einen anderen Skill aufrufen?

Nicht direkt. Es gibt keinen Mechanismus, bei dem /deploy automatisch /review aufruft. Wenn Sie einen zusammengesetzten Workflow brauchen, bauen Sie einen einzelnen Skill, der alle Schritte enthält. Alternativ nutzen Sie einen Hook, um zusätzliche Logik nach einem Skill auszulösen.

Wie interagieren Rules mit CLAUDE.md?

Beide werden in den Kontext geladen, und Claude folgt allem. Wenn eine Rule etwas in CLAUDE.md widerspricht, gewinnt normalerweise die spezifischere Anweisung. Aber vermeiden Sie Widersprüche von vornherein — CLAUDE.md für projektweite Anweisungen, Rules für dateispezifische Überschreibungen.