Hooki w Claude Code: konfiguracja i 7 przykładów

Hooki w Claude Code to polecenia powłoki, wywołania HTTP lub krótkie kontrole LLM, które uruchamiają się automatycznie przed działaniem Claude’a lub po nim. Dodają kontrole określonych zdarzeń, formatują kod po edycji i wstawiają kontekst na starcie. Dopasowany PreToolUse może odrzucić wywołanie; przykłady regex to pomocnicze kontrole, nie granica bezpieczeństwa każdej ścieżki plików lub Git. Poniżej przedstawiam 4 typy obsługi, 31 zdarzeń cyklu życia, test „kiedy reguła powinna znaleźć się w hooku”, 7 gotowych do skopiowania hooków do .claude/settings.json oraz 3 pułapki, na które sam natrafiłem.

Dokumentacja Ailoot: API, klucze i konfiguracja.

Czym są hooki w Claude Code?#

Przez pół roku trzymałem w CLAUDE.md regułę „nigdy nie edytuj .env bezpośrednio”. Claude łamał ją raz w miesiącu. Nie ze złośliwości; po prostu zapominał o niej pod koniec długiej sesji. Raz w .env pojawił się dodatkowy token, innym razem zmienna o zduplikowanej nazwie nadpisała tę używaną.

Przeniosłem tę regułę do hooka, dzięki czemu nie da się o niej zapomnieć. Gdy dopasowane bezpośrednie narzędzie edycji podaje ścieżkę .env, hook odrzuca wywołanie. Przekierowania Bash, skrypty, MCP i inne ścieżki wymagają osobnych kontroli; przykład nie czyni pliku niezmiennym.

Innymi słowy, hook to twoje polecenie, które Claude Code uruchamia po wystąpieniu określonego zdarzenia. Każda edycja pliku, uruchomienie Bash, rozpoczęcie sesji lub zakończenie pracy subagenta to zdarzenie, do którego możesz przypisać hook.

Dlaczego ma to znaczenie dla vibe coderów:

• Chroń pliki zawierające sekrety przed przypadkowymi zmianami.
• Automatycznie uruchamiaj prettier/eslint po każdym wygenerowaniu kodu.
• Blokuj git push --force do main bez wyraźnej zgody.
• Wstawiaj świeży kontekst na początku każdej sesji.
• Rejestruj działania Claude’a na potrzeby audytu.

CLAUDE.md odpowiada za kontekst. Hooki odpowiadają za działania. To dwie różne rzeczy, a ich mylenie jest najczęstszym błędem początkujących.

Czym hooki różnią się od CLAUDE.md i skills?#

Dokumentacja Anthropic wyraźnie wyjaśnia różnicę między CLAUDE.md a hookami:

Innymi słowy, treść CLAUDE.md trafia do Claude’a jako pierwsza wiadomość od użytkownika, a nie jako instrukcja systemowa. Model ją przeczyta i spróbuje się do niej zastosować. Nie ma jednak żadnych gwarancji, zwłaszcza pod koniec długiej sesji, gdy kontekst się rozrasta, a starsze instrukcje wypadają z niego.

Hook działa inaczej. Jest zapisany w settings.json, nie zależy od modelu i jest uruchamiany przez proces Claude Code w reakcji na konkretne zdarzenie: PreToolUse, PostToolUse, SessionStart i inne. Polecenie uruchamia się, zanim Claude otrzyma wynik, i może fizycznie zablokować działanie (exit 2) lub zmodyfikować plik po edycji (exit 0).

Porównanie:

Pełny szablon CLAUDE.md i 6 zasad utrzymywania tego pliku znajdziesz w poradniku Jak skonfigurować CLAUDE.md w 2026 roku: gotowy szablon i 6 zasad. O skills jako nazwanych możliwościach przeczytasz w Claude Code Skills: jak zbudować własną bibliotekę.

Hook działa na najniższym poziomie: bez modelu, bez interpretacji, tylko powłoka.

Hooki to jedno z narzędzi inżynierii kontekstu, obok Plan Mode i /compact.

4 typy hooków: Command, HTTP, Prompt, Agent — który wybrać?#

Najczęstszym błędem jest próba użycia Command do zadania, które wymaga Prompt. Na przykład „nie używaj pauz em w plikach .md” można sprawdzić przez grep, więc Command jest idealny. Ale „nie pisz korporacyjnym tonem” dotyczy znaczenia, więc wymaga Prompt.

Jeśli dopiero zaczynasz, używaj Command. Wszystkie 7 gotowych hooków poniżej to Command. HTTP/Prompt/Agent przydadzą się później, gdy będziesz gotowy.

Gdzie znajduje się settings.json i jakie są 4 poziomy konfiguracji?#

Trzymam 7 opisanych poniżej hooków w projektowym .claude/settings.json, dzięki czemu są automatycznie uwzględniane po sklonowaniu repozytorium, a Claude stosuje te same reguły w nowym oknie. Osobiste hooki eksperymentalne umieszczam w .claude/settings.local.json, żeby nie przeszkadzały zespołowi.

Wszystkie 4 pliki są łączone na początku sesji. Jeśli reguły są sprzeczne, pierwszeństwo ma niższy poziom (lokalny przed projektem, projekt przed użytkownikiem).

Najszybszy sposób na utworzenie pierwszego hooka to interaktywne menu /hooks w Claude Code. Wybierz zdarzenie z listy, określ matcher (na przykład Bash lub Edit) i wklej polecenie. Claude Code zapisze poprawny JSON w settings.json.

31 zdarzeń cyklu życia: których potrzebują początkujący?#

Warto zrozumieć te trzy częstotliwości, żeby uniknąć nieporozumień:

1. Raz na sesję - SessionStart, SessionEnd, Setup. Uruchamiają się raz przy otwieraniu i zamykaniu Claude Code. Używaj ich do inicjowania kontekstu i usuwania plików tymczasowych.
2. Raz na turę - UserPromptSubmit, UserPromptExpansion, Stop, StopFailure. Uruchamiają się przy każdej twojej wiadomości i za każdym razem, gdy model się zatrzymuje. Służą do rejestrowania rozmowy i końcowej kontroli wyników.
3. Przy każdym wywołaniu narzędzia - PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, PermissionDenied, PostToolBatch, SubagentStart, SubagentStop. Uruchamiają się przy każdej edycji pliku, uruchomieniu Bash, odczycie lub wyszukiwaniu. To najbardziej intensywna warstwa, w której działają ograniczenia, formatowanie i walidacja.

Pełna lista 31 zdarzeń obejmuje asynchroniczne/reaktywne zdarzenia: TeammateIdle, PreCompact, PostCompact, Elicitation, ElicitationResult, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, Notification. Są przeznaczone do zaawansowanych zastosowań; na razie je pomiń.

Test z pięcioma pytaniami: kiedy reguła powinna trafić do hooka, a kiedy zostać w CLAUDE.md?#

Dla mnie to działa jak prawo, a nie sugestia. Wybór między CLAUDE.md a hookiem sprowadziłem do prostego testu z pięcioma pytaniami. Jeśli co najmniej trzy odpowiedzi brzmią „tak”, reguła trafia do hooka. Przy mniej niż trzech zostaje w tekście.

Test „kiedy reguła powinna trafić do hooka?”

1. Czy ta reguła dotyczy działania, a nie kontekstu? („nie uruchamiaj rm -rf” dotyczy działania; „mam projekt TypeScript” to kontekst).
2. Czy reguła dotyczy bezpieczeństwa, pieniędzy lub danych? („nie dotykaj .env”, „nie publikuj kluczy”).
3. Czy można ją sprawdzić przez grep, regex lub kod wyjścia polecenia powłoki? („po edycji .md sprawdź, czy nie ma pauzy em”).
4. Czy skutki złamania reguły byłyby trudne do naprawienia? („force push do main” trudno odwrócić; „brak kropki na końcu” łatwo poprawić).
5. Czy zdarzyło ci się już, że Claude przynajmniej raz zapomniał tej reguły?

Przykład: „Nie używaj pauz em, używaj tylko łączników.” Działanie? Tak. Bezpieczeństwo? Nie. Można sprawdzić przez grep? Tak. Trudno naprawić? Nie. Widziałem naruszenie? Tak. 3 z 5: umieść w hooku.

Kontrprzykład: „Jestem vibe coderem, nie programistą; pisz bez slangu.” Działanie? Raczej kontekst. Bezpieczeństwo? Nie. Można sprawdzić regexem? Zbyt trudno. Trudno naprawić? Nie. Widziałem naruszenie? Tak. 1 z 5: zostaw w CLAUDE.md.

Pięć moich reguł przeszło test. Przeniosłem je do hooków. Pozostałe 75% zostało w pliku tekstowym.

7 hooków gotowych do skopiowania#

Wszystkie 7 hooków znajduje się w jednym pliku .claude/settings.json w katalogu głównym projektu. Każdy wpis zawiera typ zdarzenia, filtr narzędzia (matcher) i polecenie powłoki. Kod 2 odrzuca dopasowane PreToolUse przed wykonaniem. Przy PostToolUse czynność już nastąpiła: hook zgłasza informację zwrotną i nie może jej cofnąć.

exit 0 oznacza powodzenie. exit 1 oznacza błąd, ale Claude kontynuuje (to pierwszy antywzorzec poniżej). exit 2 zależy od zdarzenia: może blokować PreToolUse, ale PostToolUse tylko zgłasza informację o już wykonanej czynności.

Hook 1. Kontroluj bezpośrednie edycje .env (PreToolUse, exit 2)

Blokuje próby bezpośredniej edycji dowolnego pliku pasującego do wzorca .env, .env.local, .env.production i podobnych.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '(^|/)\\.env(\\.|$)' && { echo 'Do not edit `.env` directly. Tell me which variable to add, and I’ll open the file myself.' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Co robi: Przed każdym Edit/Write/MultiEdit pobiera ścieżkę pliku i sprawdza przez grep, czy pasuje do wzorca .env. Jeśli tak, zwraca exit 2 z komunikatem. Claude widzi stderr i mówi mi: „Próbowałem edytować .env, ale hook mnie zablokował; powiedz mi, którą zmienną dodać”.

Hook 2. Automatycznie uruchamiaj prettier po każdej edycji kodu (PostToolUse, exit 0)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '\\.(ts|tsx|js|jsx|json)$' && npx prettier --write \"$FILE\" 2>/dev/null & exit 0"
          }
        ]
      }
    ]
  }
}

Co robi: Po każdym Edit/Write pobiera ścieżkę i jeśli rozszerzenie to .ts/.tsx/.js/.jsx/.json, uruchamia prettier w tle za pomocą &. Zawsze kończy się kodem 0, ponieważ chodzi o formatowanie, a nie ograniczenie. Jeśli prettier zawiedzie, nic wielkiego; plik pozostaje bez zmian.

Różnica w stosunku do hooka 1 jest zasadnicza: PreToolUse + exit 2 to twarda blokada przed działaniem. PostToolUse + exit 0 to miękka edycja po działaniu. To dwa tryby przeznaczone do różnych zadań.

Hook 3. Blokuj git push --force do gałęzi main (PreToolUse, exit 2)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "CMD=$(jq -r '.tool_input.command // empty'); [ -z \"$CMD\" ] && exit 0; echo \"$CMD\" | grep -qE 'git[[:space:]]+push' && echo \"$CMD\" | grep -qE '(\\-\\-force|\\-\\-force-with-lease|[[:space:]]-f([[:space:]]|$))' && echo \"$CMD\" | grep -qE '([[:space:]/:])main([[:space:]/:]|$)' && { echo 'Force push to main is forbidden. Create a new branch or ask me to do it manually.' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Co robi: Przy każdym uruchomieniu Bash sprawdza, czy polecenie zawiera push, --force/--force-with-lease/-f i wzmiankę o main. Jeśli pasują wszystkie trzy warunki, blokuje operację i wyświetla jasny komunikat.

Kiedyś miałem tę regułę zapisaną wielkimi literami w CLAUDE.md. Claude i tak łamał ją mniej więcej raz na dwa tygodnie, gdy prosiłem go o „force push, żeby cofnąć mój zły commit”. Hook wychwytuje pokazane dosłowne formy, lecz aliasy, skrypty, domyślna gałąź celu i inny klient Git mogą go ominąć. Egzekwuj ochronę main zdalnie i ogranicz poświadczenia agenta.

Hook 4. Blokuj pauzy em w plikach tekstowych (PostToolUse, exit 2)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '\\.(md|mdx|tsx?)$' && grep -q $'\\xe2\\x80\\x94' \"$FILE\" && { echo \"File $FILE contains an em dash (U+2014). Replace it with a regular hyphen (U+002D).\" >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Co robi: PostToolUse z exit 2 zgłasza Claude błąd kontroli po edycji. Nie cofa ani nie zapobiega zapisowi. Jeśli Claude edytuje plik i pozostawia pauzę em, hook kończy się błędem, Claude otrzymuje informację zwrotną i próbuje ponownie. Po 2–3 sesjach Claude przestaje wstawiać ten znak.

Zwróć uwagę, że grep szuka konkretnie znaku pauzy em (U+2014) za pomocą $'\xe2\x80\x94', czyli zapisu w Bash służącego do przedstawienia go jako bajtów UTF-8. Jeśli po prostu wpiszesz grep -q '-', polecenie znajdzie zwykłe łączniki i uruchomi się przy każdym pliku. Niewidoczny znak psuje całą logikę.

Hook 5. Zwolnij port 3000 przed npm run dev (PreToolUse, exit 0)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "CMD=$(jq -r '.tool_input.command // empty'); [ -z \"$CMD\" ] && exit 0; echo \"$CMD\" | grep -qE '(npm|pnpm|yarn)[[:space:]]+run[[:space:]]+dev' && { lsof -ti:3000 | xargs -r kill -9 2>/dev/null; echo 'Port 3000 freed before launch' >&2; }; exit 0"
          }
        ]
      }
    ]
  }
}

Co robi: Przed każdym npm run dev (lub pnpm/yarn) zabija proces korzystający z portu 3000. Zawsze kończy się kodem 0, ponieważ to przygotowanie, a nie ograniczenie. Chroni przed pułapką, w której Claude widzi „port in use”, uznaje, że problem dotyczy kodu i zaczyna go poprawiać, choć tak naprawdę nadal działał tylko stary serwer.

Hook 6. Automatycznie wykonuj commit po pomyślnych testach (PostToolUse, exit 0)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "INPUT=$(cat); CMD=$(printf '%s' \"$INPUT\" | jq -r '.tool_input.command // empty') || exit 1; EXIT=$(printf '%s' \"$INPUT\" | jq -r '.tool_response.exit_code // empty') || exit 1; case \"$CMD\" in 'npm test'|'pnpm test'|'yarn test') ;; *) exit 0 ;; esac; [ \"$EXIT\" = \"0\" ] || exit 0; git diff --cached --quiet || { echo 'Existing staged changes: review manually' >&2; exit 0; }; git add -- src/orders.ts tests/orders.test.ts || exit 1; git diff --cached --quiet && exit 0; git commit -m 'tests: checkpoint after successful run'"
          }
        ]
      }
    ]
  }
}

Co robi: Czyta JSON stdin raz i akceptuje tylko pokazane dokładne proste polecenia testów. Działa tylko przy jawnie zerowym tool_response.exit_code; jeśli wersja nie dostarcza pola, pomija commit zamiast zgadywać sukces. Zastąp src/orders.ts i tests/orders.test.ts dokładnymi plikami zadania. Wcześniejsze zmiany w indeksie zatrzymują receptę, aby nie dołączyć cudzej pracy. Nieudane add zatrzymuje ją, pusty diff nie tworzy commita, zwykłe hooki commitów pozostają aktywne. Przed włączeniem sprawdź offline wyniki udane, błędne i brakujące.

Antywzorzec: git commit --no-verify przy każdej edycji. Zachowuj kontrole commitów. Przy rekurencyjnym wyzwalaniu automatyzacji zawęź wyzwalacz lub przeprojektuj kontrolę zamiast domyślnie pomijać weryfikację. Przed automatycznymi commitami przejrzyj diff indeksu i własność zadania.

Hook 7. Wstawiaj świeży kontekst na początku sesji (SessionStart z additionalContext)

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null || echo 'no-branch'); STATUS=$(git status --short 2>/dev/null | head -10); echo \"{\\\"additionalContext\\\":\\\"Current branch: $BRANCH. Uncommitted changes:\\n$STATUS\\\"}\""
          }
        ]
      }
    ]
  }
}

Co robi: Na początku sesji zbiera bieżącą gałąź Git i listę niezatwierdzonych zmian, a następnie zwraca JSON z polem additionalContext. Claude Code wstawia ten tekst do pierwszej wiadomości systemowej, więc Claude od początku wie, gdzie się znajduje i co pozostało po poprzedniej sesji.

Ten hook można rozszerzyć o pobieranie najnowszego commita i jego opisu, statusu GitHub Actions, bieżącego sprintu z Linear/Jira oraz otwartych zgłoszeń w bieżącym repozytorium.

3 pułapki związane z hookami, które przydarzają się co drugiej osobie#

Pułapka 1. Hook z exit 1 przechodzi po cichu

To najniebezpieczniejsza pułapka. Przez tydzień myślałem, że mój hook chroniący .env działa, ale okazało się, że w hooku użyłem jq -r '.tool_input.file_path' bez sprawdzenia wartości null. Gdy tool_input było puste, jq kończył działanie z kodem 1. Claude traktował exit 1 jako „błąd hooka, kontynuuj”, więc działanie było wykonywane. Nie rozumiałem, dlaczego .env nadal jest modyfikowany. Przyczynę zauważyłem dopiero wtedy, gdy ręcznie uruchomiłem hook w terminalu z pustym wejściem.

Rozwiązanie to jedna zasada: każdy hook zaczynaj od sprawdzenia null, a kończ na || exit 0. Każde nieoczekiwane zakończenie spowoduje wtedy „bezpieczne” wyjście zamiast cichego przepuszczenia operacji.

# Safe start and end template:
FILE=$(jq -r '.tool_input.file_path // empty')
[ -z "$FILE" ] && exit 0
# ... your logic ...
exit 0   # or || exit 0 on one line

Pułapka 2. Wolne hooki są przerywane po przekroczeniu limitu czasu

Miałem hook, który po Edit uruchamiał eslint --fix na całym pliku. Przetworzenie dużych plików (1000+ linii) zajmowało 8–10 sekund. Domyślny limit czasu hooka w Claude Code wynosi 60 sekund, więc wydawało mi się, że mieszczę się w limicie. Gdy jednak w ciągu minuty dochodzi do kilku operacji Edit, hooki gromadzą się i ustawiają w kolejce, a niektóre są po prostu pomijane. Zorientowałem się dopiero wtedy, gdy w logu pojawił się komunikat „hook timed out”.

Rozwiązanie: jeśli hook wymaga ciężkiej pracy, uruchom ją w tle. Użyj eslint --fix "$FILE" & i nie czekaj na wynik. Hook zwróci wtedy exit 0 w kilka milisekund, a właściwa praca będzie wykonywana w tle.

# Heavy operation in background:
npx eslint --fix "$FILE" &
exit 0

Pułapka 3. Hook nie widzi zmiennych środowiskowych projektu

Myślałem, że process.env w hooku będzie dostępne tak jak w aplikacji Node.js. Tak nie jest. Hook działa w powłoce uruchomionej przez proces nadrzędny Claude Code i widzi tylko to, co znajduje się w ~/.zshrc lub ~/.bashrc, oraz to, co Claude Code jawnie przekazuje. Jeśli hook zależy od OPENAI_API_KEY z .env, musisz ręcznie odczytać .env.

Rozwiązanie: jawnie odczytaj .env w poleceniu hooka.

# Passing project env into hook:
cd "$PWD" && source .env && curl -H "Authorization: Bearer $OPENAI_API_KEY" ...
# Or with dotenv:
dotenv -e .env -- node my-validator.js

Jest to szczególnie kłopotliwe w monorepo, gdzie różne pakiety mają własne pliki .env. Rozwiąż ten problem, przekazując PWD i jawnie wykonując cd "$PWD" na początku polecenia.

Jak testować hooki przed commitem?#

Podstawowy scenariusz testowy. Skopiuj polecenie hooka z JSON, otwórz terminal i przekaż JSON, który wysłałby Claude Code:

# Test hook 1 (protect .env):
echo '{"tool_input":{"file_path":".env"}}' | bash -c '
FILE=$(jq -r ".tool_input.file_path // empty")
[ -z "$FILE" ] && exit 0
echo "$FILE" | grep -qE "(^|/)\.env(\.|$)" && {
  echo "BLOCKED" >&2
  exit 2
} || exit 0
'
echo "Exit code: $?"

W stderr powinien pojawić się komunikat BLOCKED oraz Exit code: 2. Jeśli otrzymasz exit 0, regex nie działa; popraw grep.

Scenariusze do sprawdzenia:

1. Ścieżka pozytywna - plik powinien zostać zablokowany. .env w przypadku hooka 1, git push --force main w przypadku hooka 3.
2. Ścieżka negatywna - plik nie powinien zostać zablokowany. README.md w przypadku hooka 1, git push origin feature-branch w przypadku hooka 3.
3. Przypadki brzegowe - puste wejście, wartości null, nieoczekiwane znaki. Hook powinien zwrócić exit 0 albo zakończyć się czytelnym błędem, a nie po cichu przepuszczać operację.

Gdzie umieszczać eksperymentalne hooki. Nie w .claude/settings.json, lecz w .claude/settings.local.json (poza gitem). Dodaj tam nowe hooki w sekcji PostToolUse i użyj echo zamiast właściwego działania. Sprawdź, czy się uruchamiają, a następnie przenieś je do produkcyjnego settings.json.

// Experiment in settings.local.json - writes to /tmp/hook-debug.log:
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[hook fired] $(date) $(jq -r '.tool_input.file_path // \"?\"')\" >> /tmp/hook-debug.log"
          }
        ]
      }
    ]
  }
}

Po 5–10 edycjach w Claude Code otwórz /tmp/hook-debug.log i sprawdź, które pliki wywołały hook. Jeśli plik jest pusty, matcher nie pasuje; popraw regex.

Co dalej?#

5 kroków na nadchodzący tydzień:

1. Wyszukaj w CLAUDE.md przez Grep słowa takie jak „never”, „forbidden”, „always” i „must”. Każda taka reguła może trafić do hooka. Jeśli reguła ma formę nakazu, plik tekstowy jej nie wymusi.
2. Zacznij od PostToolUse + exit 0. To najbezpieczniejsze rozwiązanie: wprowadza zmianę, ale niczego nie blokuje. Prettier (hook 2), zakończenie serwera deweloperskiego (hook 5), automatyczny commit po testach (hook 6).
3. Dopiero gdy nabierzesz pewności, dodaj pierwszy PreToolUse + exit 2. Na przykład chroń .env (hook 1) albo zapobiegaj force-push (hook 3). To twarda blokada, a błąd w poleceniu grep może zablokować również ciebie.
4. Ręcznie testuj hooki przed commitem (zobacz sekcję powyżej). Oszczędzi ci to wielu godzin debugowania.
5. Eksperymentuj w settings.local.json. Umieszczaj tam nowe hooki, używając echo zamiast właściwego działania.

Po skonfigurowaniu hooków kolejnym krokiem w tym klastrze jest jak cofnąć zmiany w Claude Code, na wypadek gdyby hook przepuścił coś niebezpiecznego. Jeśli chcesz, by Claude pamiętał strukturę projektu między sesjami, zbuduj Drugi Mózg w Claude Code (folder business/ + połączona baza wiedzy). A jeśli chcesz nadać skills projektu nazwy, aby można było ich ponownie używać, zobacz Claude Code Skills.

Jeśli potrzebujesz dostępu do sieci neuronowych przez Ailoot, zajrzyj na stronę Ailoot.