Claude Code Hooks erklärt: Regeln und Automatisierungen im Projekt erzwingen

Claude Code kann Dateien bearbeiten, Shell-Befehle ausführen, Tests starten und mit externen Tools kommunizieren. Je autonomer ein Coding-Agent arbeitet, desto wichtiger wird allerdings eine Frage: Wie stelle ich sicher, dass bestimmte Regeln wirklich eingehalten werden?

Eine Anweisung in einer CLAUDE.md kann Claude beispielsweise sagen, dass vor Abschluss einer Aufgabe Tests ausgeführt werden sollen. Eine solche Anweisung bleibt jedoch eine Anweisung an ein Sprachmodell.

Ein Claude Code Hook geht einen Schritt weiter. Hooks werden automatisch an festgelegten Punkten im Claude-Code-Workflow ausgeführt. Damit lassen sich beispielsweise gefährliche Shell-Befehle blockieren, Code nach Änderungen automatisch formatieren, Tests erzwingen oder beim Start einer Session zusätzliche Informationen laden.

Anthropic beschreibt Hooks entsprechend als Mechanismus für deterministische Aktionen innerhalb des Agenten-Lebenszyklus: Bestimmte Aktionen passieren also automatisch, anstatt darauf zu vertrauen, dass das Modell selbst daran denkt. Gerade bei größeren Projekten macht das einen erheblichen Unterschied.

Was sind Claude Code Hooks?

Ein Hook ist vereinfacht gesagt ein automatischer Auslöser. Claude Code erreicht einen bestimmten Punkt in seinem Workflow – beispielsweise bevor ein Shell-Befehl ausgeführt wird – und startet daraufhin eine von dir definierte Prüfung oder Aktion.

Das Prinzip sieht beispielsweise so aus:

Claude möchte einen Bash-Befehl ausführen
↓
PreToolUse
↓
Sicherheitsprüfung
↓
erlaubt / blockiert
↓
Befehl wird ausgeführt

Damit verschiebt sich ein Teil der Kontrolle vom KI-Modell in eine technisch definierte Regel. Das ist der entscheidende Unterschied.

Eine Regel wie „Bitte niemals direkt nach main pushen." kann in einer CLAUDE.md stehen. Mit einem Hook kannst du dagegen tatsächlich prüfen, welcher Bash-Befehl ausgeführt werden soll, und einen unerlaubten Push blockieren.

CLAUDE.md oder Hook: Was ist der Unterschied?

CLAUDE.md und Hooks erfüllen unterschiedliche Aufgaben und sollten sich ergänzen. In der CLAUDE.md beschreibst du beispielsweise Architektur, Coding-Konventionen, Projektstruktur oder Arbeitsabläufe. Ein typischer Eintrag könnte lauten: „Neue Funktionen müssen Unit-Tests besitzen. Direkte Pushes auf main sind nicht erlaubt. TypeScript-Dateien müssen mit Prettier formatiert werden." Damit weiß Claude, wie es arbeiten soll.

Hooks eignen sich dagegen für Regeln, deren Einhaltung technisch überprüft oder automatisiert werden kann. Man kann es sich so merken: CLAUDE.md beschreibt das gewünschte Verhalten. Hooks kontrollieren oder automatisieren das Verhalten. Mehr dazu, wie sich CLAUDE.md und AGENTS.md unterscheiden und ergänzen, erklärt der Artikel AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein KI-Coding-Projekt? (Zum Artikel).

Für professionelle Claude-Code-Projekte ist die Kombination aus beiden deshalb wesentlich stärker als eine immer länger werdende Prompt-Datei.

Wo werden Claude Code Hooks gespeichert?

Hooks können auf unterschiedlichen Ebenen definiert werden. Für ein einzelnes Projekt ist vor allem diese Datei interessant: .claude/settings.json. Sie kann zusammen mit dem Projekt in Git eingecheckt werden. Dadurch verwenden Entwickler eines Teams dieselben projektbezogenen Hooks.

Daneben gibt es ~/.claude/settings.json für persönliche Einstellungen über alle Projekte hinweg sowie .claude/settings.local.json für projektspezifische Einstellungen, die nur auf dem eigenen Rechner gelten sollen.

Auch zentral verwaltete Unternehmensrichtlinien sowie Hooks innerhalb von Plugins, Skills und Agents werden inzwischen unterstützt. Für gemeinsam genutzte Projektregeln ist .claude/settings.json meist der interessanteste Ausgangspunkt.

Wie ist ein Claude Code Hook aufgebaut?

Die grundlegende Struktur sieht so aus:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/format-file.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Darin befinden sich drei wichtige Ebenen: Event → Matcher → Hook. Das Event bestimmt, wann etwas passiert. Der Matcher bestimmt, bei welchen Tools die Regel gilt. Der eigentliche Hook bestimmt schließlich, was ausgeführt wird.

Matcher können beispielsweise nur Bash betreffen oder mehrere Tools wie "matcher": "Edit|Write".

Aktuelle Claude-Code-Versionen unterstützen zusätzlich das Feld if, mit dem Tool-Aufrufe noch genauer anhand der verwendeten Argumente gefiltert werden können. Dadurch lässt sich beispielsweise zwischen beliebigen Bash-Befehlen und einem git push unterscheiden.

Die wichtigsten Claude Code Hook Events

Claude Code besitzt inzwischen zahlreiche Lifecycle-Events. Für den Einstieg reichen jedoch einige besonders wichtige.

Die aktuelle Referenz enthält darüber hinaus unter anderem Events für Worktrees, Dateiänderungen, MCP-Elicitation, Verzeichniswechsel, Instructions und Fehler beim Beenden eines Turns. Für die meisten Projekte sind PreToolUse, PostToolUse, SessionStart und Stop zunächst die interessantesten.

Praxisbeispiel 1: Gefährliche Bash-Befehle blockieren

Einer der sinnvollsten Einsatzzwecke für Claude Code Hooks ist eine Sicherheitsprüfung vor Shell-Befehlen. Dafür eignet sich PreToolUse.

Erstelle beispielsweise .claude/hooks/block-dangerous.sh mit:

#!/usr/bin/env bash

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

if echo "$COMMAND" | grep -Eq 'rm[[:space:]]+-rf|git[[:space:]]+push[[:space:]]+--force'; then
  echo "Sicherheitsregel: Gefährlicher Befehl wurde blockiert." >&2
  exit 2
fi

exit 0

Anschließend: chmod +x .claude/hooks/block-dangerous.sh und in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-dangerous.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Versucht Claude anschließend einen passenden gefährlichen Befehl auszuführen, beendet sich das Script mit exit 2. Das ist wichtig: Bei Claude-Code-Command-Hooks bedeutet Exit-Code 0 Erfolg. Exit-Code 2 kann bei PreToolUse dagegen den Tool-Aufruf blockieren.

Ein gewöhnliches exit 1 ist dafür nicht ausreichend. Bei den meisten Hook-Events behandelt Claude Code andere Exit-Codes lediglich als nicht blockierenden Fehler. Damit lässt sich eine echte Sicherheitsbarriere aufbauen.

Praxisbeispiel 2: Direkte Pushes auf main verhindern

Noch interessanter wird es in Git-Projekten. Du könntest Claude in der CLAUDE.md folgende Regel geben: „Erstelle für Änderungen immer einen separaten Branch. Direkte Pushes auf main oder master sind verboten."

Zusätzlich wird die Regel technisch erzwungen, beispielsweise mit:

#!/usr/bin/env bash

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

if echo "$COMMAND" | grep -Eq 'git push([^;|&]*)[[:space:]](main|master)$'; then
  echo "Direkte Pushes auf main/master sind in diesem Projekt verboten." >&2
  exit 2
fi

exit 0

In den Settings kann der Hook zusätzlich mit if eingegrenzt werden:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git push *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-git-push.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Dadurch muss das Script nicht bei jedem beliebigen Bash-Aufruf gestartet werden. Genau hier zeigt sich die Stärke von Hooks: Aus der Richtlinie „Bitte nicht nach main pushen." wird eine technisch überprüfbare Projektregel.

Praxisbeispiel 3: Code nach jeder Änderung automatisch formatieren

Hooks sind nicht nur für Verbote geeignet. Sie können Claude auch lästige Routinearbeiten abnehmen. Dafür bietet sich PostToolUse an.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/format-file.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Das Script könnte die bearbeitete Datei aus dem JSON-Input auslesen:

#!/usr/bin/env bash

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

case "$FILE" in
  *.js|*.jsx|*.ts|*.tsx|*.json|*.css)
    npx prettier --write "$FILE"
    ;;
esac

exit 0

Damit wird Formatierung nicht mehr zu einer freiwilligen Aufgabe des Coding-Agenten. Claude bearbeitet eine Datei – der Formatter läuft automatisch. Auch Anthropic nennt automatische Formatierung nach Write- oder Edit-Operationen als typischen Einsatzbereich für PostToolUse.

Praxisbeispiel 4: Claude darf erst aufhören, wenn Tests erfolgreich sind

Besonders interessant ist der Stop-Hook. Er wird ausgelöst, wenn Claude seine Antwort beziehungsweise Arbeit beenden möchte. Damit kannst du eine zusätzliche Qualitätskontrolle einbauen.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-tests.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Das Script könnte anschließend deine Tests starten. Vereinfacht:

#!/usr/bin/env bash

INPUT=$(cat)
STOP_ACTIVE=$(echo "$INPUT" | jq -r '.stop_hook_active // false')

if [ "$STOP_ACTIVE" = "true" ]; then
  exit 0
fi

if ! npm test; then
  echo "Tests schlagen noch fehl. Fehler beheben und erneut testen." >&2
  exit 2
fi

exit 0

Warum prüfen wir stop_hook_active? Weil Claude Code beim Stop-Event mitteilt, ob der Agent bereits aufgrund eines vorherigen Stop-Hooks weiterarbeitet. Diese Information sollte berücksichtigt werden, damit ein fehlerhaft konstruierter Hook Claude nicht in eine Endlosschleife zwingt.

Das Ergebnis ist mächtig: Claude kann eine Aufgabe nicht einfach als erledigt betrachten, obwohl die definierte Qualitätsprüfung fehlschlägt.

Noch besser: TaskCompleted statt jeden Stop prüfen

Bei größeren Claude-Code-Workflows kann inzwischen auch TaskCompleted interessant sein. Dieser Hook läuft, wenn eine Aufgabe als abgeschlossen markiert werden soll.

Die offizielle Dokumentation zeigt genau diesen Anwendungsfall: Tests können ausgeführt und der Abschluss einer Aufgabe über Exit-Code 2 verhindert werden, wenn sie fehlschlagen. Das kann effizienter sein, als bei jedem normalen Gesprächsende die gesamte Test-Suite zu starten.

SessionStart: Claude automatisch mit aktuellem Projektkontext versorgen

Ein weiteres sehr nützliches Event ist SessionStart. Damit lassen sich dynamische Informationen bereitstellen, die sich nicht sinnvoll statisch in einer CLAUDE.md speichern lassen.

#!/usr/bin/env bash

echo "Aktueller Git Branch:"
git branch --show-current

echo
echo "Git Status:"
git status --short

echo
echo "Letzte Commits:"
git log --oneline -5

Die Informationen können Claude beim Start zur Verfügung gestellt werden. Das ist besonders praktisch, wenn du häufig neue Sessions öffnest.

Statische Projektregeln gehören weiterhin in die CLAUDE.md. Dynamische Informationen wie Git-Status, aktuelle Tickets oder Build-Informationen eignen sich dagegen gut für SessionStart.

Command, HTTP, MCP, Prompt oder Agent Hook?

Claude Code beschränkt Hooks inzwischen nicht mehr auf Shell-Scripts. Die aktuelle Implementierung kennt fünf Handler-Typen.

Für klare Regeln solltest du möglichst deterministische Hooks verwenden. Beispielsweise: Ist git push --force verboten? Dafür braucht man keine KI. Ein command-Hook ist schneller, reproduzierbar und eindeutig.

Anders sieht es bei einer Frage wie „Hat Claude die vom Benutzer angeforderten Änderungen wirklich vollständig umgesetzt?" aus. Hier kann ein Prompt- oder Agent-Hook sinnvoll sein.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Prüfe, ob alle angeforderten Aufgaben vollständig abgeschlossen wurden: $ARGUMENTS"
          }
        ]
      }
    ]
  }
}

Prompt-Hooks verwenden ein Claude-Modell für eine einzelne Entscheidung. Agent-Hooks gehen noch weiter: Sie können einen Subagenten starten, der Dateien liest, Code durchsucht und Bedingungen untersucht. Wie du eigene Subagenten für solche Prüfaufgaben aufbaust, zeigt Claude Code Subagents: Spezialisten für komplexe Coding-Aufgaben erstellen (Zum Artikel).

Diese Agent-Hooks werden in der aktuellen Dokumentation allerdings weiterhin als experimentell bezeichnet. Für produktionskritische Regeln empfiehlt Anthropic deshalb eher Command-Hooks.

Hooks und MCP kombinieren

Claude Code Hooks werden besonders interessant, wenn das Projekt MCP-Server verwendet. MCP-Tools erscheinen bei Tool-Events wie normale Tools. Ihre Namen folgen beispielsweise dem Muster mcp__server__tool.

Damit kannst du gezielt Regeln für externe Systeme erstellen. Beispielsweise könnten lesende MCP-Operationen erlaubt sein, während schreibende Aktionen einer zusätzlichen Kontrolle unterliegen. Ein Matcher kann beispielsweise so aussehen: "matcher": "mcp__.*__write.*".

Dadurch lassen sich Sicherheitsregeln nicht nur auf Bash oder Dateiänderungen anwenden, sondern auch auf Aktionen über angeschlossene MCP-Systeme. Das ist besonders für KI-Agenten interessant, die Zugriff auf Datenbanken, GitHub, Ticketsysteme oder interne APIs besitzen. Welche Risiken externe Daten über MCP-Server zusätzlich mitbringen können, erklärt Prompt Injection bei MCP-Servern: Warum externe Daten gefährlich werden können (Zum Artikel).

Claude Code Hooks sind kein Ersatz für CI/CD

Hooks sind sehr praktisch – sie sollten jedoch nicht deine zentrale Qualitätssicherung ersetzen. Ein Entwickler könnte lokale Hooks verändern oder deaktivieren. Deshalb sollte beispielsweise eine wichtige Regel wie „Alle Tests müssen erfolgreich sein." zusätzlich in deiner CI/CD-Pipeline kontrolliert werden.

Eine sinnvolle Architektur sieht deshalb eher so aus:

CLAUDE.md
↓ beschreibt Entwicklungsregeln
Claude Code Hooks
↓ erzwingen Regeln während der KI-Entwicklung
Git / Pull Request
↓ Code Review
CI/CD
↓ führt verbindliche Tests und Security Checks aus
Deployment

Hooks verkürzen also die Feedbackschleife. Probleme werden bereits während der Arbeit mit Claude erkannt – und nicht erst nach dem Push in der Pipeline.

Sicherheit: Hooks besitzen echte Rechte

Hier sollte man besonders vorsichtig sein. Command-Hooks laufen mit den Rechten des Benutzers, unter dem Claude Code gestartet wurde. Sie können damit grundsätzlich auf dieselben Dateien und Ressourcen zugreifen wie dieser Benutzer.

Anthropic weist deshalb ausdrücklich darauf hin, Hook-Eingaben zu validieren, Shell-Variablen sauber zu quoten, Path-Traversal zu verhindern, möglichst absolute Pfade zu verwenden und sensible Dateien wie .env oder Schlüssel besonders zu schützen. Wie du solche Zugangsdaten zusätzlich absicherst, zeigt Secrets und API-Keys bei KI-Agenten schützen: .env, Vault und Berechtigungen richtig einsetzen (Zum Artikel).

Ein Hook sollte deshalb niemals unkontrolliert externe Eingaben direkt in einen Shell-Befehl einsetzen. Problematisch wäre beispielsweise sinngemäß eval "$USER_INPUT". Sicherheitsprüfungen sollten stattdessen möglichst mit klaren Allow- oder Deny-Regeln arbeiten. Eine breitere Einordnung, welche Rechte ein KI-Agent insgesamt erhalten sollte, liefert Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für autonome Tools (Zum Artikel).

So würde ich Hooks in einem echten Projekt aufbauen

Eine saubere Projektstruktur könnte beispielsweise so aussehen:

my-project/
├── .claude/
│   ├── settings.json
│   ├── hooks/
│   │   ├── block-dangerous.sh
│   │   ├── check-git-push.sh
│   │   ├── format-file.sh
│   │   └── check-tests.sh
│   └── rules/
├── CLAUDE.md
├── src/
├── tests/
└── package.json

Die Logik bleibt damit aus der großen JSON-Konfiguration heraus. settings.json definiert hauptsächlich, wann welcher Hook ausgeführt werden soll. Die eigentliche Prüfung steckt dagegen in kleinen Scripts. Das macht die Regeln einfacher testbar und wartbar.

Hooks überprüfen und debuggen

Claude Code besitzt mittlerweile außerdem einen /hooks-Befehl. Damit kannst du die aktuell konfigurierten Hooks ansehen und prüfen, aus welcher Konfigurationsdatei sie stammen. Das ist besonders hilfreich, wenn globale, lokale, Projekt- und Plugin-Hooks gleichzeitig aktiv sind.

Gerade bei komplexeren Setups sollte außerdem jedes Hook-Script zunächst separat im Terminal getestet werden. Ein Hook, der Sicherheitsregeln erzwingen soll, aber aufgrund eines Syntaxfehlers nie korrekt ausgeführt wird, vermittelt sonst nur eine falsche Sicherheit.

Welche Regeln eignen sich besonders für Claude Code Hooks?

Hooks sind besonders stark für Regeln, die eindeutig überprüfbar sind. Sinnvolle Beispiele sind: direkte Pushes auf main verhindern, git push --force blockieren, gefährliche Löschbefehle verhindern, Formatter nach Dateiänderungen ausführen, Unit-Tests vor dem Abschluss einer Aufgabe starten, Änderungen an bestimmten Dateien kontrollieren oder protokollieren sowie sicherheitsrelevante MCP-Schreiboperationen zusätzlich prüfen.

Je eindeutiger eine Regel technisch beschrieben werden kann, desto weniger sollte ihre Einhaltung ausschließlich vom KI-Modell abhängen.

Claude Code Hooks verändern den Umgang mit Coding-Agenten

Coding-Agenten werden zunehmend autonomer. Damit verändert sich auch die Aufgabe des Entwicklers. Es geht nicht mehr nur darum, Claude möglichst gute Prompts zu geben. Man muss zusätzlich definieren, innerhalb welcher technischen Grenzen ein Agent arbeiten darf. Genau dafür sind Hooks interessant.

Statt Claude lediglich zu sagen „Bitte führe Tests aus.", kann ein Hook dafür sorgen, dass Tests tatsächlich ausgeführt werden. Statt „Bitte niemals direkt nach main pushen.", kann ein PreToolUse-Hook den entsprechenden Befehl verhindern. Und statt „Beende die Aufgabe erst, wenn alles funktioniert.", kann ein Stop- oder TaskCompleted-Hook eine echte Qualitätsprüfung durchführen.

Damit werden aus Prompt-Regeln technische Guardrails.

Fazit: Gute Claude-Code-Projekte brauchen mehr als gute Prompts

Claude Code Hooks gehören zu den Funktionen, die bei kleinen Experimenten leicht übersehen werden, bei größeren Projekten aber zunehmend wichtig werden.

Eine gute CLAUDE.md erklärt Claude, wie das Projekt funktioniert. Skills stellen wiederverwendbares Wissen und Arbeitsabläufe bereit. Subagents übernehmen spezialisierte Aufgaben. MCP verbindet Claude mit zusätzlichen Werkzeugen und Systemen. Und Hooks sorgen dafür, dass bestimmte Regeln und Automatisierungen tatsächlich ausgeführt werden.

Gerade für produktive Entwicklungsumgebungen ist das entscheidend. Denn je mehr Aufgaben ein Coding-Agent selbstständig übernimmt, desto wichtiger wird nicht nur die Frage: Was kann Claude tun? Sondern auch: Welche Regeln gelten unabhängig davon, was Claude tun möchte? Claude Code Hooks liefern genau dafür einen mächtigen Mechanismus.

Häufige Fragen zu Claude Code Hooks

Was ist ein Claude Code Hook?

Ein Claude Code Hook ist eine automatisch ausgeführte Aktion an einem definierten Punkt im Claude-Code-Lifecycle. Hooks können beispielsweise vor einem Shell-Befehl, nach einer Dateiänderung oder beim Abschluss einer Aufgabe ausgeführt werden.

Wo werden Claude Code Hooks konfiguriert?

Projektweite Hooks können in .claude/settings.json definiert werden. Persönliche Hooks befinden sich unter ~/.claude/settings.json, während .claude/settings.local.json lokale projektspezifische Einstellungen aufnehmen kann.

Kann ein Claude Code Hook einen Befehl verhindern?

Ja. Ein PreToolUse-Hook kann einen Tool-Aufruf blockieren. Bei Command-Hooks kann dafür unter anderem Exit-Code 2 verwendet werden.

Kann Claude Code automatisch Tests ausführen?

Ja. Beispielsweise können PostToolUse, TaskCompleted oder Stop verwendet werden, um Tests automatisch zu starten. Je nach Hook kann ein Fehlschlag anschließend verhindern, dass eine Aktion oder Aufgabe abgeschlossen wird.

Sind Claude Code Hooks dasselbe wie CLAUDE.md?

Nein. CLAUDE.md enthält Anweisungen und Kontext für Claude. Hooks führen dagegen automatisch Aktionen aus oder kontrollieren konkrete Vorgänge. Beide Funktionen ergänzen sich.

Können Hooks mit MCP-Servern verwendet werden?

Ja. MCP-Tools können bei Tool-Hooks anhand ihrer Tool-Namen gefiltert werden. Zusätzlich unterstützt Claude Code inzwischen auch den Hook-Typ mcp_tool.

Sind Claude Code Hooks sicher?

Hooks können die Sicherheit eines Agenten-Workflows deutlich verbessern, müssen aber selbst sicher programmiert werden. Insbesondere Command-Hooks laufen mit den Berechtigungen des aktuellen Systembenutzers.

Weitere verständliche Anleitungen rund um KI, Coding und Systemadministration findest du im KI-Buster Blog.

Quellen und weiterführende Dokumentation

Redaktioneller Stand: 16. Oktober 2026. Primärquellen: [1] Claude Code: Hooks reference – Hook-Events, Handler-Typen, Exit-Codes und JSON-Input/-Output. [2] Claude Code: Get started with hooks – Einrichtung, Beispiele und Sicherheitshinweise. [3] Claude Code: Settings – Speicherorte von settings.json und Konfigurationsebenen. Die Hook-Scripts und das Projektbeispiel sind eigene Beispiele zu Demonstrationszwecken; es werden keine selbst gemessenen Produktivitätsgewinne oder durchgeführten Projekttests behauptet.