Dlaczego agenci AI ignorują instrukcje w kodzie

Dlaczego agenci programujący ignorują instrukcje

Agenci programujący ignorują instrukcje z czterech powodów i żaden z nich nie wynika z nadmiernej uprzejmości użytkownika. Zasada nie znalazła się w oknie kontekstowym. Zasada była zbyt niejasna, aby można było zweryfikować podjęte działanie. Inny element kontekstu był z nią sprzeczny, zazwyczaj kod, który agent przed chwilą odczytał. Lub zasada jest nadal załadowana, ale znajduje się daleko za bieżącą turą konwersacji, a agent pracuje w oparciu o informacje znajdujące się najbliżej.

Każda przyczyna wymaga innego rozwiązania, dlatego pierwszym krokiem jest ich rozróżnienie. Wielkie litery i słowo IMPORTANT nie stanowią diagnozy. Poniższe mechanizmy wykorzystują Claude Code jako przykład roboczy, ponieważ jego zachowanie w zakresie ładowania i kompresji danych jest szczegółowo udokumentowane na sierpień 2026. Inne narzędzia różnią się szczegółami, ale w ogólnym zarysie działają w ten sam sposób.

Najpierw dwa terminy. Okno kontekstowe (context window) to blok tekstu, który model widzi w danej turze: prompt systemowy, pliki z instrukcjami, konwersacja oraz każdy plik odczytany przez agenta. Harness to program otaczający model, czyli komponent odczytujący pliki z dysku i składający ten blok. Prawie każda skarga w tym tekście jest w rzeczywistości skargą na harness, a nie na sam model.

Plik instrukcji to komunikat, a nie ustawienie

Plik instrukcji nie jest konfiguracją. Żaden element środowiska wykonawczego nie odczytuje CLAUDE.md w celu wymuszenia jego treści. Mechanizm sterujący odczytuje plik z dysku i wkleja tekst do konwersacji. W Claude Code zawartość ta jest dostarczana jako komunikat użytkownika umieszczony po prompcie systemowym, co oznacza, że model postrzega te zasady tak samo, jak każdy inny wpisany tekst.

Ma to niekomfortowe konsekwencje. Zasady konkurują z każdym innym fragmentem tekstu w oknie na równych prawach. Zasada jest twierdzeniem. Plik, który agent właśnie otworzył, jest dowodem. Gdy są one sprzeczne, dowód często wygrywa i nie jest generowany żaden błąd, ponieważ z punktu widzenia modelu nie wydarzyło się nic niewłaściwego.

Oficjalna dokumentacja stwierdza to jasno: pliki instrukcji są traktowane jako kontekst, a nie wymuszona konfiguracja. Aby zablokować działanie niezależnie od decyzji modelu, potrzebny jest punkt zaczepienia (hook), a nie zdanie. Należy o tym pamiętać. Większość poprawek na końcu tego wpisu stanowi zastosowanie tej zasady w konkretnym przypadku.

Które pliki instrukcji są wczytywane i kiedy

Claude Code przeszukuje drzewo katalogów, zaczynając od folderu, w którym został uruchomiony. Każdy plik CLAUDE.md oraz CLAUDE.local.md, począwszy od głównego katalogu systemu plików aż do katalogu roboczego, jest wczytywany w całości podczas startu. Pliki są łączone w tej kolejności, co oznacza, że plik znajdujący się najbliżej miejsca uruchomienia jest odczytywany jako ostatni, a w obrębie jednego katalogu plik .local jest dołączany po pliku głównym.

Pliki w podkatalogach znajdujących się poniżej katalogu roboczego zachowują się inaczej. Nie są one wczytywane podczas startu. Są wczytywane w momencie, gdy agent odczytuje plik w danym katalogu. To samo dotyczy reguł o zasięgu ścieżki w .claude/rules/, które zawierają pole frontmatter paths:: wchodzą one do kontekstu w momencie odczytania pasującego pliku, a nie przy każdej turze konwersacji.

Ta jedna różnica wyjaśnia znaczną część zgłaszanych błędów. Umieszczasz regułę w packages/api/CLAUDE.md, zadajesz pytanie o API, a agent odpowiada, nie otwierając żadnego pliku w packages/api/. Reguła nie została zignorowana. Nigdy nie była obecna w kontekście. Jeśli repozytorium rozdziela wytyczne zgodnie z plikami instrukcji dla poszczególnych pakietów w monorepo, jest to pierwsza rzecz, którą należy sprawdzić w każdym przypadku.

Kolejna pułapka związana z wczytywaniem, będąca najczęstszą przyczyną sytuacji, w których "agent zignorował moje instrukcje", dotyczy faktu, że Claude Code odczytuje CLAUDE.md, a nie AGENTS.md. Repozytorium, które ustandaryzowało użycie AGENTS.md i nie posiada pliku CLAUDE.md, nie dostarcza Claude Code żadnych danych do wczytania. Obsługiwanym rozwiązaniem jest plik CLAUDE.md, którego pierwsza linia to @AGENTS.md, co powoduje zaimportowanie pliku przy starcie, wraz z wszelkimi uwagami specyficznymi dla Claude poniżej. Dowiązanie symboliczne (symlink) również działa, jeśli nie ma potrzeby dodawania dodatkowych treści. Decyzja o tym, co powinno znaleźć się w tym pliku, jest osobnym zagadnieniem, omówionym w rozdzielaniu instrukcji dla agenta od dokumentacji dla ludzi.

Potwierdzenie wczytania pliku przed jego nadpisaniem

Nie należy modyfikować treści, dopóki nie ma pewności, że agent widzi dany plik. Istnieją dwie metody weryfikacji, z których pierwsza jest mniej obciążająca.

Należy wykonać /context wewnątrz sesji. Polecenie to wyświetla bieżące okno z podziałem na kategorie, a lista Memory files zawiera nazwy wszystkich plików instrukcji, które zostały poprawnie wczytane. Plik nieobecny na tej liście nie znajduje się w kontekście konwersacji, więc wszelkie zmiany w nim wprowadzone nie przyniosą efektu. /memory wyświetla lokalizacje plików i otwiera je do edycji, w tym również pliki, które jeszcze nie istnieją.

W celu uzyskania bardziej szczegółowych informacji należy rejestrować zdarzenia wczytywania. Zdarzenie typu hook InstructionsLoaded jest wyzwalane za każdym razem, gdy plik CLAUDE.md lub plik reguł trafia do kontekstu, a jego mechanizm dopasowania wskazuje przyczynę wczytania: session_start, nested_traversal, path_glob_match, include lub compact. Należy umieścić poniższy kod w .claude/settings.json:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

Hook otrzymuje dane w formacie JSON na standardowe wejście, dlatego cat dopisuje cały rekord do pliku. Należy monitorować ten plik za pomocą tail -f /tmp/instructions-loaded.log podczas pracy. Kod wyjścia tego zdarzenia jest ignorowany, co oznacza, że hook może jedynie obserwować proces, ale nie może go zablokować. Jeśli zagnieżdżony plik nie pojawia się w logu podczas sesji, w której powinien zostać wczytany, należy wstrzymać edycję. Problem leży w lokalizacji pliku.

Wpływ długiej sesji na reguły

Występują tutaj dwa odrębne efekty, które wymagają różnych działań.

Dystans. Reguła podana w pierwszej turze nadal znajduje się w oknie kontekstowym w turze 90, konkurując z 90 turami tekstu, który jest nowszy i bardziej dopasowany do bieżących działań. Nie można tego wyeliminować konfiguracją, ale można to zmierzyć. Uruchom to samo zadanie w nowej sesji. Jeśli reguła działa poprawnie w nowej sesji, a zawodzi w długiej, przyczyną jest dystans.

Kompakcja. Gdy okno się zapełnia, mechanizm podsumowuje dotychczasową konwersację i kontynuuje pracę na podstawie tego podsumowania. Przetrwa to, co podsumowujący uznał za istotne, co nie zawsze pokrywa się z Twoją oceną ważności. Claude Code dokumentuje wynik dla każdego mechanizmu, a różnice są znaczne. Katalog główny projektu CLAUDE.md oraz reguły bez określonego zakresu są ponownie wczytywane z dysku po kompakcji. Pamięć automatyczna (Auto memory) jest również wczytywana z dysku. Reguły z nagłówkiem paths: są tracone do momentu ponownego odczytania pasującego pliku. Zagnieżdżone pliki CLAUDE.md w podkatalogach są tracone do momentu odczytania pliku z tego podkatalogu.

Uszereguj swoje instrukcje według tej tabeli, a wyłoni się kolejność ich trwałości. Reguła wpisana tylko na czacie jest najbardziej nietrwała: przetrwa tylko wtedy, gdy podsumowanie ją zachowa. Reguła w packages/api/CLAUDE.md jest następna w kolejności, ponieważ została wczytana raz, podsumowana i powraca dopiero przy kolejnym odczycie w danym katalogu. Reguła w pliku głównym projektu jest najbardziej trwała, ponieważ jest odczytywana z dysku przy każdej operacji.

Jeśli instrukcja musi obowiązywać przez całą sesję, powinna znaleźć się w pliku głównym projektu bez nagłówka paths:. Wszystko inne to kompromis, na który powinieneś zdecydować się świadomie. Zarządzanie zawartością okna kontekstowego omawia /compact z argumentem focus oraz /clear między niepowiązanymi zadaniami; oba te elementy wpływają na to, jak często mechanizm podsumowujący decyduje o tym, jakie były Twoje reguły.

Dlaczego otaczający kod przeważa nad regułą

Jest to błąd, który użytkownicy opisują najczęściej, a diagnozują najrzadziej. Plik konfiguracyjny wskazuje, że dostęp do bazy danych powinien odbywać się przez warstwę repozytorium. Agent tworzy jednak procedurę obsługi, która wywołuje ORM (object relational mapper) bezpośrednio. Nie zignorowano Twoich wytycznych ze względu na styl. Zostały one odrzucone przez dowody w kodzie.

Reguła opisuje preferencję. Kod natomiast demonstruje rzeczywistość. Gdy agent otwiera trzy pliki w module, który ma edytować, a wszystkie trzy wywołują ORM bezpośrednio, kontekst zawiera jedno abstrakcyjne zdanie po jednej stronie i trzy konkretne, aktualne, dopasowane do zadania przykłady po drugiej. Powielanie lokalnego wzorca jest zazwyczaj poprawnym zachowaniem. W tym przypadku jest to błąd tylko dlatego, że posiadasz wiedzę, której kontekst nie posiada: te pliki to kod typu legacy.

Zapisz to w regule. Reguły, które wskazują własne kontrargumenty, sprawdzają się w pracy z rzeczywistym repozytorium. Reguły, które wyrażają jedynie ogólną preferencję, nie sprawdzają się.

Nowy dostęp do bazy danych odbywa się przez app/repositories/. Pliki w app/legacy/ nadal wywołują ORM bezpośrednio. Jest to stary kod, a nie obowiązujący wzorzec. Nie należy go powielać.

Drugie zdanie wykonuje kluczową pracę. Informuje agenta, co zaraz napotka i jak ma to interpretować, zanim jeszcze to znajdzie. Ta sama poprawka ma zastosowanie do każdej reguły, której Twoje repozytorium jawnie przeczy: stylu commitów, którego historia nie przestrzega, układu testów, który połowa pakietu ignoruje, czy konwencji importów, która obowiązuje tylko w nowym kodzie. Wszędzie tam, gdzie kod nie zgadza się z plikiem reguł, należy tę rozbieżność nazwać wewnątrz pliku.

Niejasna zasada jest niemożliwa do zweryfikowania, a zatem nie może być przestrzegana

„Pisz czysty kod”. „Nie przekombinuj”. „Utrzymuj prostotę”. „Uważaj przy migracjach”. Żadnej z tych wytycznych nie da się przetestować pod kątem konkretnego działania – ani przez agenta, ani przez użytkownika. Agent, który otrzymuje zasadę niemożliwą do sprawdzenia względem własnego wyniku, zgaduje, a użytkownik ocenia to zgadywanie „na wyczucie”.

Oto test, który należy zastosować do każdej linii w pliku. Napisz polecenie powłoki, które zakończy się niepowodzeniem (kod wyjścia inny niż zero), gdy zasada zostanie złamana. Jeśli nie potrafisz napisać takiego polecenia, zasada nie jest weryfikowalna. Porównaj poniższe pary:

• Nieweryfikowalne: „Utrzymuj małe funkcje”. Weryfikowalne: „Funkcja dłuższa niż 60 linii musi posiadać komentarz wyjaśniający powód jej długości”.
• Nieweryfikowalne: „Testuj swoje zmiany”. Weryfikowalne: „Uruchom npm test i wklej liczbę błędów przed oznaczeniem zadania jako wykonane”.
• Nieweryfikowalne: „Utrzymuj porządek w plikach”. Weryfikowalne: „Handlery HTTP znajdują się w src/api/handlers/. Żadne inne pliki nie mogą znajdować się w tym katalogu”.
• Nieweryfikowalne: „Poprawnie formatuj kod”. Weryfikowalne: „Używaj wcięć 2-spacyjnych w plikach .ts”.

„Nie przekombinuj” to zasada, z której ludzie rezygnują najszybciej, ponieważ naprawa nie polega na skróceniu zdania, lecz na jego wydłużeniu: precyzyjne określenie, co faktycznie oznacza najmniejsza działająca zmiana dostarcza agentowi kryteriów, do których może on odnieść własny diff.

Rozmiar to ten sam problem w innym wydaniu. Wytyczne Claude Code zalecają mniej niż 200 linii na plik instrukcji i wskazują bezpośrednio, że dłuższe pliki obniżają skuteczność przestrzegania zasad. Plik o długości 700 linii nie jest bardziej stanowczą instrukcją. To 700 linii twierdzeń, które częściej mogą być ze sobą sprzeczne, a ponadto obciążają okno kontekstowe w każdej turze, co uwidacznia się bezpośrednio w zużyciu tokenów. Strukturyzowanie pliku tak, aby każda zasada znajdowała się pod nagłówkiem, który czytelnik może szybko przejrzeć, zostało omówione w pisaniu pliku instrukcji, na podstawie którego agent może działać.

Jak zdiagnozować problem w dziesięć minut

Wykonaj poniższe kroki w podanej kolejności. Pominięcie ostatniego etapu to najczęstsza przyczyna tworzenia długich list wykluczających się reguł, które i tak nie działają.

1. Potwierdź załadowanie. Uruchom /context i przejrzyj listę plików Memory. Jeśli pliku tam nie ma, popraw jego lokalizację i przerwij działania. Żaden inny punkt z tej listy nie ma jeszcze zastosowania.
2. Odtwórz problem w nowej sesji. Rozpocznij nową sesję i wykonaj najmniejsze możliwe zadanie, które powinno wywołać regułę. Jeśli reguła działa tutaj, ale zawodzi w długiej sesji, problemem jest odległość lub kompresja danych. Jeśli zawodzi również tutaj, problemem jest sama treść reguły.
3. Wyeliminuj konkurencję. Zastosuj tę samą zmianę w katalogu, którego istniejący kod jest już zgodny z regułą. Jeśli zgodność powróci, oznacza to, że otaczający kod był sprzeczny z Twoją instrukcją.
4. Wyszukaj konflikt. Dwa pliki zawierające odmienne wytyczne dla tego samego zachowania to udokumentowany błąd: model może wybrać dowolny z nich i nie poinformuje o tym fakcie.
5. Uczyń regułę sprawdzalną i przetestuj ponownie. Przepisz regułę, używając konkretnej ścieżki i warunku. Znaczny wzrost zgodności oznacza, że przyczyną było sformułowanie instrukcji.

Krok 4 to jedno polecenie. Przeszukaj wszystkie źródła instrukcji pod kątem danego tematu, a nie tylko plik, który aktualnie edytujesz:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

Znalezienie dwóch plików z różnymi instrukcjami wskazuje na błąd. Usuń jeden z nich. Nie próbuj nadawać im priorytetów poprzez silniejsze sformułowania, ponieważ nie istnieje mechanizm oceny ważności reguł.

Poprawki w kolejności skuteczności

Każdy poniższy krok ma większą skuteczność niż poprzedni, ale wymaga większego nakładu pracy przy konfiguracji. Należy zacząć od góry, gdy regułę można łatwo przeformułować. Należy przejść niżej, gdy reguła staje się na tyle istotna, że sporadyczne błędy są niedopuszczalne.

1. Ukonkretnij regułę. Wskaż ścieżkę, polecenie lub warunek. Dodaj kontrargumenty, które agent znajdzie w repozytorium, zgodnie z wcześniejszymi wskazówkami. Jest to darmowe i rozwiązuje zaskakująco wiele problemów.
2. Przenieś regułę bliżej tego, czego dotyczy. Zagnieżdżony CLAUDE.md, reguła ograniczona ścieżką w .claude/rules/ lub komentarz na początku pliku. Reguła jest wtedy odczytywana wraz z kodem, którego dotyczy. Zaakceptuj kompromis: wszystko, co jest wczytywane w ten sposób, znika przy następnej kompresji i powraca przy kolejnym dopasowanym odczycie.
3. Przenieś egzekwowanie do hooka. Tekst prosi. Hook decyduje. Hooki uruchamiają się jako kod w określonych momentach cyklu życia i działają niezależnie od wniosków modelu.
4. Przekaż regułę do narzędzia deterministycznego i usuń opis tekstowy. Formatowanie, kolejność importów, długość linii, zabronione importy, format wiadomości commit. ruff format, prettier --write, eslint, hook pre-commit. Formatter ma rację za każdym razem i nie zużywa tokenów. Zdanie ma rację w większości przypadków, ale zużywa tokeny przy każdej iteracji.

Krok 3 w szczegółach. Załóżmy, że pliki migracji nigdy nie mogą być edytowane przez agenta. Umieść to w .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

Oraz to w .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

Uruchom chmod +x .claude/hooks/guard-migrations.sh, a następnie rozpocznij nową sesję i poproś agenta o edycję pliku w migrations/. Edycja zostanie odrzucona, a Twoja wiadomość wróci jako powód. Kod wyjścia 2 w PreToolUse blokuje wywołanie narzędzia przed jego uruchomieniem, a treść stderr jest przekazywana do modelu jako komunikat blokujący. ${CLAUDE_PROJECT_DIR} wskazuje na główny katalog projektu, więc hook działa niezależnie od tego, w jakim katalogu znajduje się agent. Agent nie musi zgadzać się z regułą, pamiętać o niej ani mieć jej w kontekście. Edycja nie zostanie wykonana.

W przypadku całkowitego zakazu bez logiki, permissions.deny w ustawieniach wykonuje to samo zadanie bez konieczności utrzymywania skryptu, a tryby uprawnień decydują o tym, co zostanie uruchomione bez wcześniejszego pytania. Jeśli instrukcja musi znajdować się na poziomie system prompt, a nie w wiadomości użytkownika, --append-system-prompt umieszcza ją tam, choć musi być przekazywana przy każdym wywołaniu, co lepiej sprawdza się w skryptach niż w pracy interaktywnej.

Czego nie da się wyeliminować instrukcją

Należy jasno rozróżnić, która część problemu leży po stronie użytkownika. Rozmieszczenie, sformułowania, konflikty między plikami oraz rozmiar plików to kwestie zależne od autora i wymagające jego poprawy. Reszta to zachowanie modelu, którego lepsze sformułowanie poleceń nie wyeliminuje.

Zgoda nie oznacza przestrzegania zasad. Agent potwierdzi regułę, powtórzy ją poprawnie, a dwa wywołania narzędzi później ją złamie. Potwierdzenie nic nie kosztuje i niczego nie gwarantuje. Nie należy traktować go jako rozwiązania ani testu skuteczności.

Niektóre nawyki są trwałe. Dodawanie komentarzy, defensywna obsługa błędów, pisanie podsumowań czy uruchamianie oczywistych kolejnych poleceń. Powracają one nawet przy zakazie, choć z mniejszą częstotliwością, nigdy jednak nie spadają do zera. Własną częstotliwość występowania błędów można zmierzyć: należy wykonać to samo zadanie dziesięć razy w nowych sesjach i policzyć naruszenia. Jeśli liczba ta musi wynosić zero, reguła musi zostać usunięta z promptu.

Własna sesja staje się przykładem. Jeśli agent złamał regułę w kroku 12, a użytkownik pozwolił na to, naruszenie to pozostaje w kontekście jako wzorzec, który jest znacznie świeższy niż sama reguła. Naruszenie należy korygować w momencie jego wystąpienia. Niepoprawione naruszenie kształtuje resztę sesji.

Plik z instrukcjami nie stanowi bariery bezpieczeństwa. Kształtuje on zachowanie, ale go nie wymusza. Wszystko, gdzie błąd jest kosztowny, jak dane uwierzytelniające czy destrukcyjne polecenia, powinno być zarządzane przez uprawnienia lub hooki. Ochrona sekretów przed dostępem agenta stosuje tę samą zasadę do danych: nie należy prosić agenta, aby nie czytał pliku, lecz skonfigurować system tak, aby plik nie był dla niego czytelny.

Wersja skrócona: należy potwierdzić wczytanie pliku, uczynić regułę sprawdzalną, umieścić ją obok elementu, którego dotyczy, a gdy wskaźnik błędów nadal jest istotny, usunąć ją z tekstu instrukcji. Reguła, której agent nie może zignorować, to taka, o którą nigdy nie trzeba było go prosić.

FAQ

Dlaczego Claude Code ignoruje mój plik CLAUDE.md?

Przed założeniem, że plik jest ignorowany, należy sprawdzić, czy został wczytany. Uruchom /context i przejrzyj listę Memory files; plik, którego tam nie ma, nie znajduje się w konwersacji. Pliki z instrukcjami są dostarczane jako wiadomość użytkownika po systemowym prompcie i są traktowane jako kontekst, a nie wymuszona konfiguracja, dlatego nie ma gwarancji ścisłego przestrzegania zasad. Większość rzeczywistych przypadków wynika z jednej z czterech przyczyn: plik znajduje się w podkatalogu, z którego agent nigdy nie czytał, dwa pliki są ze sobą sprzeczne i model wybrał jeden z nich arbitralnie, reguła jest zbyt niejasna, aby zweryfikować działanie, lub otaczający kod demonstruje zachowanie przeciwne do treści reguły.

Czy edycja pliku z instrukcjami w trakcie sesji coś zmienia?

Nie w przypadku kopii znajdującej się już w konwersacji. Pliki znajdujące się powyżej katalogu roboczego są wczytywane w całości podczas uruchamiania, więc tekst, którym dysponuje model, pochodzi z momentu startu. Aby uwzględnić edycję, należy rozpocząć nową sesję lub poprosić agenta o odczytanie pliku za pomocą standardowych narzędzi plikowych, co wprowadzi aktualną wersję do konwersacji jako nową wiadomość. Po kompresji (compaction) plik z katalogu głównego projektu jest ponownie odczytywany z dysku, więc nowa wersja pojawia się w tym momencie.

Który plik ma pierwszeństwo, gdy CLAUDE.md w katalogu głównym i zagnieżdżony plik są sprzeczne?

Żaden w sposób niezawodny. Wykryte pliki są łączone w kontekście, zamiast się nadpisywać, w kolejności od katalogu głównego systemu plików do katalogu roboczego, więc plik znajdujący się najbliżej jest po prostu odczytywany jako ostatni. Nie istnieje mechanizm rozstrzygający sprzeczności, a dokumentacja Claude Code stwierdza, że sprzeczne reguły mogą być rozstrzygane arbitralnie. Zagnieżdżone pliki należy tworzyć jako uzupełnienia wskazujące ścieżkę, której dotyczą, a sprzeczne zapisy usuwać, zamiast próbować je nadpisywać.

Czy moje instrukcje przetrwają polecenie /compact?

Zależy to od sposobu ich wczytania. Plik CLAUDE.md z katalogu głównego projektu, reguły bez zakresu (unscoped) oraz automatyczna pamięć są ponownie wstrzykiwane z dysku po kompresji. Reguły z frontmatter paths: oraz zagnieżdżone pliki CLAUDE.md w podkatalogach są tracone do momentu ponownego odczytania pasującego pliku. Wszystko, co zostało wpisane bezpośrednio w czacie, przetrwa tylko wtedy, gdy mechanizm podsumowujący (summariser) je zachowa. Jeśli reguła musi obowiązywać przez całą sesję, należy umieścić ją w pliku w katalogu głównym projektu bez frontmatter paths:.

Kiedy reguła powinna stać się hookiem zamiast opisu tekstowego?

Gdy weryfikacja jest deterministyczna, a koszt błędu przewyższa koszt napisania krótkiego skryptu. Ograniczenia ścieżek plików, wymagane polecenia przed commitem oraz zabronione wywołania narzędzi kwalifikują się do tego rozwiązania. Hook PreToolUse, który kończy działanie ze statusem 2, blokuje wywołanie narzędzia i zwraca tekst stderr do modelu jako uzasadnienie, dzięki czemu reguła obowiązuje niezależnie od tego, czy nadal znajduje się w kontekście. Wszystko, co może zostać zweryfikowane przez formater lub linter, powinno być obsługiwane przez te narzędzia i całkowicie usunięte z pliku z instrukcjami.