Skills & Hooks einrichten

Wissen

Review-Skill erstellen

Skills machen deinen Workflow wiederverwendbar. Statt jedes Mal den Review-Prozess zu beschreiben, erstellst du einen /review-Befehl, den du und dein Team jederzeit aufrufen könnt.

Erstelle die Datei .claude/skills/review/SKILL.md:

---
name: review
description: Review the latest changes or a specific PR
argument-hint: "[PR-number]"
context: fork
agent: code-reviewer
---

# Code Review durchführen

1. Lies die Änderungen (git diff oder gh pr diff $ARGUMENTS)
2. Lies die CLAUDE.md für projektspezifische Review-Regeln
3. Prüfe auf: Bugs, Security Issues, Performance, Lesbarkeit
4. Gib strukturiertes Feedback mit Severity (critical/warning/info)
5. Fasse am Ende zusammen: Anzahl Findings pro Severity

## Wenn eine PR-Nummer angegeben ist:
- Nutze `gh pr diff $ARGUMENTS` für den Diff
- Lies die PR-Beschreibung mit `gh pr view $ARGUMENTS`
- Beziehe den Kontext der PR-Beschreibung in das Review ein

icontext: fork

Die Einstellung context: fork sorgt dafür, dass der Review-Agent in einem eigenen Kontext arbeitet. So bleibt deine aktuelle Konversation unberührt, und der Agent kann sich voll auf das Review konzentrieren.

Beachte die Schlüsselelemente:

argument-hint -- Zeigt dem Nutzer, welche Argumente möglich sind. /review 42 würde PR #42 reviewen.
agent: code-reviewer -- Verknüpft den Skill mit dem Agent, den wir im vorherigen Abschnitt definiert haben.
$ARGUMENTS -- Wird durch die übergebenen Argumente ersetzt. Ohne Argumente reviewt der Agent die lokalen Änderungen.

Hooks konfigurieren

Hooks automatisieren wiederkehrende Aufgaben. Wir konfigurieren drei Arten von Hooks in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $FILE && npx eslint --fix $FILE"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "if": "Bash(git commit*)",
        "hooks": [
          {
            "type": "command",
            "command": "npm test"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Review abgeschlossen'"
          }
        ]
      }
    ]
  }
}

Verstehen

settings.json Konfiguration

Klicke auf einen Abschnitt, um die Auswirkung zu sehen

Konfiguration

{
  "hooks": {
    "PostToolUse": [{
      "matcher": { "tool_name": "Write" },
      "hook": {
        "type": "command",
        "command": "npx eslint --fix $TOOL_INPUT_FILE_PATH"
      }
    }]
  }
}

Auswirkung

Nach jeder Dateiänderung durch Claude Code wird automatisch ESLint ausgeführt. Fehler werden sofort gefixt.

Was passiert bei jedem Hook?

PostToolUse (nach Edit/Write): Jedes Mal, wenn Claude Code eine Datei bearbeitet oder erstellt, laufen automatisch Prettier und ESLint. Das Ergebnis: Jede Änderung ist sofort korrekt formatiert und lint-frei -- ohne dass du daran denken musst.

PreToolUse (vor git commit): Bevor Claude Code einen Commit erstellt, laufen automatisch alle Tests. Schlagen die Tests fehl, wird der Commit blockiert. So landen keine kaputten Änderungen im Repository.

Stop (bei Abschluss): Wenn der Agent fertig ist, wird eine Abschlussmeldung ausgegeben. In einem erweiterten Setup könnte hier eine Slack-Benachrichtigung oder ein Log-Eintrag stehen.

!Exit-Codes bei Hooks

Der Exit-Code eines Hooks bestimmt, was passiert: 0 bedeutet Erfolg (stdout wird dem Context hinzugefügt), 1 ist ein nicht-blockierender Fehler (Aktion läuft weiter, stderr wird im Verbose-Modus angezeigt), und 2 blockiert die Aktion komplett (stderr wird als Feedback an Claude zurückgegeben). Nutze Exit-Code 2 für kritische Checks, die auf keinen Fall übergangen werden dürfen.

Was passiert, wenn der Pre-Commit-Hook (npm test) mit Exit-Code 2 zurückkehrt?

Den Workflow zusammensetzen

Hier ist der vollständige Ablauf, wenn du /review 42 aufrufst:

Du tippst: /review 42
    │
    ▼
Skill "review" wird aktiviert
    │
    ▼
Agent "code-reviewer" startet (fork-Kontext)
    │
    ▼
Agent liest CLAUDE.md → kennt Review-Regeln
    │
    ▼
Agent ruft `gh pr diff 42` auf → MCP-Server holt Diff
    │
    ▼
Agent analysiert Code → prüft auf Bugs, Security, Performance
    │
    ▼
Agent gibt strukturiertes Feedback aus
    │
    ▼
Stop-Hook feuert → "Review abgeschlossen"

Anwenden

Teste deinen Workflow mit diesen Schritten:

Lokale Änderungen reviewen: Mache eine kleine Änderung in deinem Projekt und rufe /review auf (ohne PR-Nummer). Der Agent sollte den lokalen Diff analysieren.
PR reviewen: Wenn du ein GitHub-Repository hast, erstelle einen PR und rufe /review <PR-Nummer> auf. Prüfe, ob der Agent die PR-Beschreibung einbezieht.
Hooks testen: Bearbeite eine Datei und beobachte, ob Prettier und ESLint automatisch laufen. Versuche, einen Commit zu machen -- die Tests sollten vorher laufen.

*Schrittweise testen

Teste jeden Baustein einzeln, bevor du den gesamten Workflow durchspielst. Erst Hooks, dann den Agent allein, dann den Skill, und zum Schluss alles zusammen. So findest du Probleme schneller.

Reflektieren

Skills und Hooks bilden zusammen das Rückgrat deines Workflows. Skills geben dir die Kontrolle darüber, wann etwas passiert. Hooks sorgen dafür, dass bestimmte Dinge immer passieren -- egal ob du daran denkst oder nicht. Diese Kombination aus bewusster Auslösung und automatischer Absicherung macht Claude-Code-Workflows robust und zuverlässig.