Przejdź do głównej zawartości

Przycinanie CLAUDE.md i AGENTS.md: protokół ablacji

Przycinanie plików kontekstu oznacza traktowanie CLAUDE.md, .cursor/rules i AGENTS.md jako budżetu do cięcia, a nie dziennika do rozbudowy: zamiast dopisywać regułę po każdej pomyłce, protokół ablacji usuwa linie, obserwuje powtarzające się błędy i przywraca tylko to, co bez nich w sposób sprawdzalny się psuje. To odzwierciedla zwrot z lipca 2026: od narastających plików instrukcji ku mniejszym, testowanym dowodami.

Trzy miesiące temu dopisałeś linijkę mówiącą agentowi, żeby nigdy nie odpalał pnpm build, gdy działa dev server. Dziś rano agent odpalił pnpm build, gdy działał dev server. Odruch podpowiada: przepisz regułę wersalikami, poprzedź ją słowem “WAŻNE”, a najlepiej dorzuć jeszcze “MUSISZ”.

To zła poprawka i jest złą poprawką od dłuższego czasu. W lipcu 2026 zmieniło się to, że ludzie budujący te narzędzia przestali się w tej sprawie spierać.

  • Datowanej mapy tego, dlaczego każdy przewodnik, który przeczytałeś, przeczy każdemu innemu, i jednego pytania, po którym poznasz, z której epoki pochodzi dany wpis
  • Mechaniki, którą dokumentacja każdego narzędzia zakopuje: które pliki ładują się przy starcie, które leniwie, która “optymalizacja” nie oszczędza nic, i o cięciu na 32 KiB, które Codex wykonuje bez śladu w TUI
  • Tabeli routingu odpowiadającej na pytanie “gdzie trafia ta linijka” dla wszystkich pięciu miejsc docelowych: plik główny, plik w podkatalogu, reguła zakresowana ścieżką, skill, hook
  • Dziewięciu gotowych promptów, z wypisanymi różnicami per narzędzie, które wykonają kasowanie i przenoszenie za ciebie
  • Protokołu na powtórzenie całości przy następnej zmianie modelu, bo to jest wyzwalacz, który naprawdę ma znaczenie

Wersja krótka: rada odwróciła się o 180 stopni, a prawie nic z tego, co przeczytasz, nie jest datowane na tyle wyraźnie, żebyś rozpoznał, po której stronie tego zwrotu stoi.

Dwa słowa czynią resztę tekstu czytelną. Nie są naszym wymysłem — to słownictwo, którego używa sama Anthropic i zespół Claude Code.

Akrecja to wzrost przez nawarstwianie. Za każdym razem, gdy model zrobi coś, czego nie chciałeś, dopisujesz linijkę, żeby tego nie robił. Plik może tylko rosnąć, a każda reguła jest blizną po jednej konkretnej dawnej pomyłce.

Ablacja to przeciwieństwo: celowe wycinanie materiału, żeby zobaczyć, co się stanie bez niego. Zapożyczenie jest zamierzone — ablacja to standardowy termin w badaniach nad uczeniem maszynowym na usuwanie komponentu w celu zmierzenia jego wkładu, i to jest słowo, którego Anthropic użyła na to, co zrobiła z własnym promptem systemowym Claude Code.

Oś czasu:

  1. Grudzień 2025. Pojawia się specyfikacja Agent Skills. Każdy przewodnik o plikach kontekstu napisany przed tą datą nie miał gdzie indziej upchnąć wiedzy warunkowej, więc wszystko lądowało w pliku głównym. Dlatego szablony z 2025 roku wyglądają maksymalistycznie. Nie były wtedy błędne — po prostu powstały przed alternatywą.
  2. Styczeń 2026 — akrecja jest domyślna. Boris Cherny, twórca Claude Code, który nadal nim kieruje, opisuje zacommitowany plik własnego zespołu: “Za każdym razem, gdy widzimy, że Claude robi coś źle, dopisujemy to do CLAUDE.md, żeby następnym razem wiedział”. Rada towarzysząca: kończ każdą korektę zdaniem “zaktualizuj swój CLAUDE.md, żebyś nie popełnił tego błędu ponownie”.
  3. Czerwiec 2026 — napięcie wychodzi na jaw. W podsumowaniu roku ten sam zespół określa się jako minimaliści kontekstu na poziomie promptu systemowego (“dajesz mu minimalny możliwy prompt systemowy, minimalne możliwe narzędzia, a potem pozwalasz modelowi to rozgryźć”) — i tym samym tchem powtarza akrecyjną radę dotyczącą pliku projektowego.
  4. 24 lipca 2026 — liczba. Anthropic publikuje “The new rules of context engineering for Claude 5 generation models”. Zespół Claude Code usunął ponad 80% promptu systemowego dla modeli klasy Opus 5 i Fable 5, bez mierzalnej straty na ewaluacjach kodowania.
  5. 26-27 lipca 2026 — ablacja staje się domyślna. Wychodzi Opus 5. Następnego dnia rada dla użytkowników jest odwrotnością tej ze stycznia: kasuj swoje pliki kontekstu, skille i hooki co pół roku i sprawdź, co model potrafi bez nich, zanim cokolwiek dopiszesz z powrotem.

Oba obozy mówią: przycinaj. Różnią się domyślnym kierunkiem i kadencją. Akrecja mówi: dopisuj po każdym błędzie, edytuj sporadycznie. Ablacja mówi: kasuj wszystko okresowo, dopisuj rzadko. Ten sam zespół, odwrócony domyślny kierunek — w momencie, gdy modele przekroczyły próg zdolności.

Stąd bierze się test: jeśli wpis o plikach kontekstu nie mówi, kiedy powstał, nie da się z niego korzystać. Cokolwiek sprzed grudnia 2025 nie zna skilli. Cokolwiek sprzed końca lipca 2026 nie zna zwrotu ablacyjnego. Dotyczy to większości najwyższych wyników wyszukiwania — i kilku artykułów na tej stronie, które od tego czasu poprawiliśmy.

Zanim cokolwiek skasujesz, uświadom sobie, do czego przypięta jest rada o ablacji. Cięcie o 80% wykonano konkretnie dla Opus 5 i Fable 5. Zdanie “kasuj wszystko” padło w wywiadzie udzielonym dzień po premierze Opus 5. Nic z tego nie było testowane ani deklarowane dla modelu ze średniej półki czy starszego — a mnóstwo ludzi używa Sonneta ze względu na koszt, Haiku do wolumenu albo modelu lokalnego dla prywatności.

Zasada leżąca pod spodem przenosi się lepiej niż konkretna rada:

Ilość rusztowania, której potrzebujesz, jest odwrotnie proporcjonalna do zdolności modelu, który je czyta. Każda reguła, którą piszesz, to zakład, że model sam na to nie wpadnie. Lepsze modele odbierają ci te zakłady.

To przestawia całą dyskusję na pokrętło, które ustawiasz, a nie doktrynę, której przestrzegasz.

Modele frontier z rozumowaniem (Opus 5, Fable 5, GPT-5.6 Sol i odpowiedniki). Ablatuj agresywnie. Tutaj opublikowana rada obowiązuje dosłownie. Spodziewaj się, że skończysz z bardzo krótkim plikiem.

Modele ze średniej półki i starsze (Sonnet, Haiku, poprzednie generacje Opusa, modele lokalne). Zostaw więcej — ale rozumiej, że wymiana jest gorsza w obie strony. Te modele faktycznie korzystają na jawnej instrukcji: menedżer pakietów, warunek wstępny, pułapka. Ich budżet instrukcji jest jednak ciaśniejszy, bo mniejsze modele i te bez rozumowania degradują się szybciej wraz z przyrostem instrukcji niż modele frontier z rozumowaniem. Potrzebujesz więcej reguł i stać cię na mniej, co sprawia, że priorytetyzacja ma większe, a nie mniejsze znaczenie.

Zespoły mieszane. Jeśli twoje repo czyta twój Opus 5, Sonnet kolegi i CI odpalające coś taniego, plik musi obsłużyć najsłabszego czytelnika w pętli. Stroisz pod niego. Silny model zniesie lekko przespecyfikowany plik znacznie lepiej niż słaby zniesie niedospecyfikowany.

Praktyczne ulepszenie zasady “kasuj co pół roku”: ablatuj ponownie przy każdej zmianie modelu, nie według kalendarza. Sześć miesięcy to proxy dla “prawdopodobnie minęła generacja modeli”. Zmiana modelu jest właściwym zdarzeniem. A gdy schodzisz o poziom w dół — presja kosztowa, limity, model offline — spodziewaj się, że część dopiszesz z powrotem. To ruch pokrętła, nie twój regres.

Rzetelnych prac jest tu znacznie mniej, niż sugerują pewne siebie wpisy blogowe, a to, co istnieje, nie jest entuzjastyczną rekomendacją. Liczą się trzy badania.

BadanieCo faktycznie wykazało
Chroma, Context Rot (2025)18 modeli frontier, wejścia od około 10 tys. do 500 tys. tokenów. Każdy bez wyjątku degraduje się wraz ze wzrostem długości wejścia. Nie większość — wszystkie, przy każdym testowanym przyroście. Degradacja jest nierównomierna, a efekt “zgubione w środku” jest wyraźny: fakt zakopany w środku kontekstu jest znacznie rzadziej wykorzystywany niż ten sam fakt na którymś z brzegów.
Jaroslawicz i in., How Many Instructions Can LLMs Follow at Once? (lipiec 2025)Benchmark IFScale: 500 instrukcji, 20 modeli, siedmiu dostawców. Najlepsze modele frontier osiągają 68% trafności przy 500 instrukcjach. Co kluczowe, dokładanie instrukcji pogarsza przestrzeganie wszystkich z nich, nie tylko nowych — i występuje mierzalny bias w stronę instrukcji pojawiających się wcześniej.
Gloaguen i in., ETH Zurich, Evaluating AGENTS.md (v1 luty 2026, v2 czerwiec 2026)Najbardziej bezpośrednie badanie tego, czy pliki kontekstu w ogóle pomagają. Abstrakt v2: pliki kontekstu “ogólnie nie poprawiają wskaźników sukcesu zadań, zwiększając koszt inferencji średnio o ponad 20%”. Wersja v1 podawała rozbicie, które v2 agreguje: pliki generowane przez LLM około 3% gorzej, pliki pisane przez ludzi około 4% lepiej.

Najbardziej użyteczny wynik to nie wskaźnik sukcesu. To mechanizm. Gdy plik kontekstu wspominał o narzędziu uv, agenty używały go 1,6 raza na instancję wobec poniżej 0,01, gdy nie było o nim wzmianki — wzrost 160-krotny. Narzędzia specyficzne dla repozytorium pokazały skok około 50-krotny.

Instrukcje są przestrzegane. Czasem aż nadto. Każda napisana przez ciebie linijka jest atraktorem, ciągnącym agenta w stronę tego, co nazywa, niezależnie od tego, czy zadanie tego wymaga. To jest prawdziwy koszt długiego pliku i powód, dla którego “nieszkodliwy dodatkowy kontekst” nie istnieje.

Praca wypowiada się równie wprost o najczęstszej sekcji w tych plikach: “przeglądy repozytorium, choć popularne i rekomendowane przez dostawców modeli, nie pomagają”.

Czy więc pliki kontekstu pomagają? Mniej, niż sugeruje konsensus dostawców — a uczciwa odpowiedź brzmi, że sprawa nie jest rozstrzygnięta. Praca następcza (Probe-and-Refine) zwraca uwagę, że ani badanie ETH, ani jego kontynuacje nie zmieniają budżetu kroków agenta, co jest realnym zakłóceniem, i odnotowuje, że dwa najbardziej rzetelne badania w tym obszarze dochodzą do przeciwnych wniosków. Traktuj ~4% zysku plików pisanych ręcznie jako wynik v1 w zakresie tamtego badania, a nie jako zmierzone prawo.

To, co przeżywa ten spór, jest węższe, a obie połowy mają różną wagę dowodową. Długość ma realny, mierzalny koszt — to potwierdza cała tabela: Chroma zmierzyła to wobec długości wejścia, IFScale wobec gęstości instrukcji, ETH wobec kosztu inferencji. Pliki pisane ręcznie biją generowane to twierdzenie słabsze: taki jest wynik v1 badania ETH w jego własnym zakresie, a żadne z pozostałych dwóch badań w ogóle nie porównywało autorstwa. Opieraj się na pierwszym. Żadne z nich nie zależy od tego, czy pliki kontekstu są dużą wygraną.

To jest sekcja, której oficjalna dokumentacja ci nie złoży, i to tutaj mieszka większość marnowanego kontekstu. Wszyscy wiedzą, że plik główny ładuje się co sesję. Prawie nikt nie sprawdził, które z pozostałych mechanizmów faktycznie odraczają ładowanie, a które tylko tak wyglądają.

Ładuje się co sesję: każda reguła .mdc z alwaysApply: true, plus User Rules i Team Rules. O Team Rules łatwo zapomnieć, bo są zarządzane z panelu, a nie z repozytorium — możesz płacić za kontekst, którego nie widzisz w swoim checkoucie.

Ładuje się warunkowo: reguły z globs (tylko gdy dotykasz pasujących plików), reguły mające wyłącznie description (tylko gdy agent uzna je za istotne) i reguły ręczne (tylko gdy wpiszesz @nazwa-reguly).

Ładuje się leniwie: AGENTS.md w podkatalogach. To nowsze niż większość przewodników i szeroko przeoczane — Cursor czyta AGENTS.md natywnie w katalogu głównym projektu i w dowolnym podkatalogu, stosując go przy pracy z plikami w tym katalogu lub jego dzieciach.

Dwie pułapki warte poznania:

  • Frontmatter jest honorowany wyłącznie w plikach .mdc. Wstaw globs albo alwaysApply na górze zwykłej reguły .md, a zostanie zignorowany — plik zastosuje się tak jak jest, co zwykle oznacza: zawsze. To najczęstszy powód, dla którego “zakresowana” reguła po cichu kosztuje cię kontekst przy każdej turze.
  • /migrate-to-skills pomija dokładnie te reguły, które najbardziej wymagają przeglądu. Konwertuje reguły dynamiczne i slash-komendy na skille, ale wyklucza reguły z alwaysApply: true oraz z konkretnymi wzorcami glob. Twoje reguły zawsze aktywne są tymi drogimi, a narzędzie migracyjne przejdzie obok nich.

Deklarowana wytyczna Cursora: trzymaj reguły poniżej 500 linii i dziel duże na kompozycyjne pliki. Pierwszeństwo przy konflikcie: Team Rules, potem Project Rules, potem User Rules — wszystkie stosowalne reguły są scalane, a wcześniejsze źródła wygrywają.

Gdy już wiesz, co się odracza, “czy ta linijka ma zostać” staje się złym pytaniem. Właściwe brzmi: gdzie ta linijka trafia. Są pięć miejsc docelowych, a plik główny to tylko jedno z nich.

Co maszCursorClaude CodeCodex
Reguła uniwersalna, potrzebna co sesjęAGENTS.md albo .mdc z alwaysApply: trueCLAUDE.md (cel: poniżej 200 linii)główny AGENTS.md
Reguła dotycząca typu pliku.mdc z globs.claude/rules/*.md z pathszagnieżdżony AGENTS.md (tylko zakres katalogu)
Reguła dotycząca jednej części repoAGENTS.md w podkataloguCLAUDE.md w podkataloguAGENTS.md w podkatalogu albo .override.md, by zastąpić
Procedura wieloetapowa.cursor/skills/<nazwa>/SKILL.md.claude/skills/<nazwa>/SKILL.md.codex/skills/<nazwa>/SKILL.md
Coś, co musi się naprawdę wydarzyćhookhook PreToolUse / Stophook (beta) albo CI
Wskazówka, której potrzebuje tylko słabszy modeldefinicja subagenta w .cursor/agents/definicja subagenta z polem model:definicja subagenta
Preferencja osobista, nie zespołowaUser RulesCLAUDE.local.md~/.codex/AGENTS.md
Notatka dla ludzkich opiekunówREADMEkomentarz HTML (kosztuje zero tokenów)README

Z tej tabeli wynikają dwie reguły kciuka.

Jeśli reguła zaczyna się od słowa “gdy”, nie należy do pliku głównego. “Gdy pracujesz nad handlerami API, waliduj wspólnym helperem schematów” to reguła zakresowana ścieżką w przebraniu. Przenieś ją, a nie będzie cię kosztować nic, dopóki agent faktycznie nie otworzy czegoś pod src/api/.

Jeśli naprawdę zdenerwowałbyś się, gdy model to zignoruje, proza jest złym narzędziem. Pliki kontekstu są doradcze. W Claude Code plik jest dostarczany jako wiadomość użytkownika po prompcie systemowym, co jest mechanicznym powodem, dla którego nigdy nie wiąże. Hooki są deterministyczne. “Nigdy nie odpalaj builda, gdy działa dev server” to nie zdanie, to hook PreToolUse.

Są uporządkowane jako protokół. Uruchom 1, żeby ustalić, czego naprawdę potrzebujesz, 2 i 3, żeby kasować, 4 do 6, żeby przenieść to, co przetrwało, 7, żeby utwardzić to, co nie może zawieść, 8, żeby skonsolidować, i 9, żeby udowodnić, że cokolwiek z tego zadziałało.

Każdy prompt ma wspólny rdzeń i różnicę per narzędzie. Ta różnica to naprawdę wszystko, co się zmienia — ścieżki i kilka kroków specyficznych dla narzędzia — więc zamiast drukować trzy niemal identyczne prompty, rdzeń podany jest raz, a zakładki niosą tylko to, co się zmienia.

Nie zaczynaj od edycji. Zacznij od ustalenia, co ten plik ci kupuje. To jest ten jeden krok, który wszyscy pomijają, i to on sprawia, że każda późniejsza decyzja opiera się na dowodach, a nie na estetyce.

Kolumna, która ma znaczenie, to ostatnia. Ablacja mówi: dopisuj linię z powrotem dopiero po tym, jak model zawiedzie w ten sam sposób więcej niż raz. Pojedyncze potknięcie to szum; linia, którą byś dopisał, to zakład, który byś przegrał.

Zarchiwizuj .cursor/rules/ w całości, nie tylko AGENTS.md — i sprawdź panel pod kątem Team Rules, których nie ma w twoim checkoucie, a które będą działać dalej, gdy będziesz sądził, że wykonałeś ablację.

Oficjalny test to jedno pytanie na linię: czy jej usunięcie spowoduje, że agent popełni błąd? Jeśli nie — tnij. Powód, dla którego działa lepiej jako prompt niż jako ręczne przejście, jest taki, że agent musi podać uzasadnienie każdego werdyktu, a przeczytanie dwudziestu słabych uzasadnień z rzędu jest tym, co w końcu skłania cię do skasowania ich.

Spodziewaj się, że zbiór ZOSTAW to około jednej trzeciej tego, od czego zacząłeś. Jeśli nie jest — audyt był zbyt grzeczny; powiedz to i uruchom go ponownie.

Dopisz: “Also list every rule file with its application type (Always / Intelligent / Glob / Manual) and its line count. Flag any .md file carrying frontmatter — frontmatter is ignored outside .mdc, so those rules are applying always regardless of what their globs field says.”

Każde narzędzie ma komendę, która napisze ci plik kontekstu, i każde z nich pisze dokument zoptymalizowany pod opisanie projektu ludzkiemu czytelnikowi, a nie pod zmianę zachowania modelu. To dwie różne prace. To także kierunek, wobec którego badania są najmniej łaskawe: pliki kontekstu generowane przez LLM wypadły gorzej niż brak pliku.

Uruchom generator, jeśli chcesz — wydobywa komendy i konwencje, co oszczędza ci odkrywania. Potem przytnij go mocno, kategoria po kategorii.

Mapa plików zasługuje na osobną uwagę, bo psuje się inaczej niż reszta. Pozostała część rozdętego pliku po prostu kosztuje cię tokeny. Mapa plików wietrzeje, a nieaktualny kontekst jest gorszy niż jego brak — wysyła agenta z pełnym przekonaniem pod ścieżkę, która już nie istnieje. Twój agent ma narzędzia wyszukiwania i posługuje się nimi bardzo dobrze. Nie potrzebuje twojej mapy. Potrzebuje, żeby twoja mapa nie była błędna.

Cursor generuje reguły z panelu ustawień i przez czat. Niezależnie od tego, którego użyłeś, przytnij przed commitem — generowane reguły domyślnie dostają alwaysApply, czyli najdroższe dostępne ustawienie.

4. Wyprowadź reguły zależne od ścieżki z pliku głównego

Dział zatytułowany „4. Wyprowadź reguły zależne od ścieżki z pliku głównego”

To najbardziej wartościowy mechaniczny ruch, jaki masz do dyspozycji, i zarazem ten najrzadziej używany. Każda sekcja zaczynająca się od “gdy pracujesz nad X” to treść warunkowa siedząca w pliku bezwarunkowym, kosztująca cię uwagę przy każdej turze, w której X jest nieistotne.

Celem jest .cursor/rules/<temat>.mdc. Rozszerzenie ma znaczenie — w .md frontmatter jest ignorowany:

---
description: "API endpoint conventions"
globs:
- "services/api/**/*.ts"
---
# API rules
- Validate every request body with the shared Zod schema helper
- Error responses use the { error, code } shape, never a bare string

W monorepo plik główny zwykle zawiera reguły trzech zespołów naraz, a każdy z nich płaci za dwa pozostałe. Pliki w podkatalogach są rozwiązaniem i we wszystkich trzech narzędziach są leniwsze niż plik główny.

Umieść AGENTS.md w katalogu każdego pakietu. Cursor zastosuje go automatycznie przy pracy z plikami w tym katalogu lub jego dzieciach — bez frontmattera, bez konfiguracji.

AGENTS.md # tylko to, co prawdziwe wszędzie
apps/web/AGENTS.md # konwencje aplikacji Next.js
services/api/AGENTS.md # konwencje serwisu API
packages/ui/AGENTS.md # konwencje biblioteki komponentów

Reguły to ograniczenia. Skille to procedury. Jeśli blok twojego pliku kontekstu czyta się jak instrukcja operacyjna — ponumerowane kroki, sekwencja, “najpierw zrób to, potem tamto” — jest w złym miejscu, i jest tam od grudnia 2025.

Różnica dotyczy ładowania. Reguła w pliku głównym jest czytana przy każdej turze, na zawsze. Skill jest czytany wtedy, gdy jest istotny.

Ostatnia instrukcja jest tą, przed którą ludzie się bronią. Zostawienie w pliku głównym zdania “szczegóły wdrożenia znajdziesz w skillu deployment” przywraca koszt, który właśnie usunąłeś. Odkrywanie skilli jest automatyczne we wszystkich trzech narzędziach.

Skille mieszkają w .cursor/skills/ albo .agents/skills/, a osobiste w ~/.cursor/skills/ i ~/.agents/skills/. Cursor czyta też .claude/skills/ i .codex/skills/, więc wspólny katalog skilli działa we wszystkich trzech narzędziach.

Cursor ma /migrate-to-skills, które konwertuje reguły dynamiczne i slash-komendy automatycznie. Uruchom je najpierw — ale wiedz, że wyklucza reguły z alwaysApply: true oraz z konkretnymi globami, czyli dokładnie ten drogi zbiór. Te przenosisz ręcznie powyższym promptem.

Własne ujęcie Cursora: “w porównaniu z zawsze aktywnymi, deklaratywnymi regułami, skille lepiej sprawdzają się przy dynamicznym odkrywaniu kontekstu i proceduralnych instrukcjach «jak to zrobić»”.

Przy niektórych regułach byłbyś lekko rozczarowany, widząc ich złamanie. Inne kosztują cię godzinę. Ten drugi rodzaj w ogóle nie należy do prozy — pliki kontekstu są doradcze, a linijka “nigdy tego nie rób” w markdownie jest mocną sugestią skierowaną do systemu probabilistycznego.

Zasada powiązana, ładnie ujęta przez HumanLayer: twój agent nie jest drogim linterem. Nigdy nie wydawaj kontekstu na opisywanie reguł, które i tak wymusza narzędzie deterministyczne. Jeśli Biome przeformatuje to przy zapisie, nie mów o tym dodatkowo modelowi.

Cursor obsługuje hooki, zarządzane obok pluginów, skilli, serwerów MCP, subagentów, reguł i komend ze strony Customize, na poziomie użytkownika, zespołu lub workspace’u.

8. Skonsoliduj do jednego źródła prawdy, potem sprawdź budżet

Dział zatytułowany „8. Skonsoliduj do jednego źródła prawdy, potem sprawdź budżet”

Jeśli twoje repo dotyka więcej niż jeden agent, prawie na pewno masz dwa pliki mówiące niemal to samo i rozjeżdżające się w tempie, w jakim je edytujesz.

AGENTS.md jest otwartym, międzynarzędziowym formatem do tego zadania — czysty markdown, brak wymaganych pól, wygrywa plik najbliższy w monorepo, i jest czytany natywnie przez Codeksa, Cursora, Copilota, Gemini CLI, Aidera, Windsurfa, Zeda, Cline’a i inne. Claude Code czyta wyłącznie CLAUDE.md, nie czyta AGENTS.md i nie stosuje go jako fallbacku, wbrew temu, co twierdzi kilka wpisów.

Rozwiązaniem jest jedna linijka.

Cursor czyta AGENTS.md natywnie, w katalogu głównym i zagnieżdżone, więc nie ma tu nic do podłączenia. Sprawdź natomiast nakładanie się: jeśli masz jednocześnie AGENTS.md i reguły .cursor/rules/*.mdc z alwaysApply: true, są scalane i prawdopodobnie płacisz dwa razy za tę samą wytyczną. Dopisz: “List every rule that appears in both AGENTS.md and an always-applied .mdc rule.”

9. Udowodnij, że zadziałało, i zaplanuj następną rundę

Dział zatytułowany „9. Udowodnij, że zadziałało, i zaplanuj następną rundę”

Krok, który wszyscy pomijają. Jeśli dodałeś regułę i nie potrafisz wskazać zmiany zachowania, dodałeś szum — a szum nie jest darmowy, bo każda linia jest atraktorem.

Potem ustaw następną rundę na wyzwalaczu, a nie na dacie. Sześć miesięcy to proxy dla “prawdopodobnie minęła generacja modeli”; zmiana modelu jest prawdziwym zdarzeniem.

Skróciłeś plik, a reguła nadal jest ignorowana. Skracanie to właściwy pierwszy ruch, ale nie jedyny tryb awarii. Sprawdź sprzeczność: jeśli dwie reguły dają różne wytyczne dla tego samego zachowania, agent może wybrać jedną arbitralnie, a żadne skracanie tego nie naprawi. W Claude Code uruchom /context i potwierdź, że plik faktycznie się załadował — reguła w pliku, który się nie załadował, wygląda dokładnie tak samo jak reguła ignorowana. Potem sprawdź, czy reguła w ogóle jest falsyfikowalna. “Pisz kod łatwy w utrzymaniu” nie da się ani spełnić, ani złamać, więc nie da się tego naprawić przez mówienie głośniej.

Skasowałeś coś nośnego i dowiedziałeś się z CI. To oczekiwany koszt ablacji, a nie znak, że zrobiłeś ją źle — i dlatego archiwum z promptu 1 jest datowaną kopią, a nie usunięciem. Przywróć pojedynczą linię, nie sekcję, z której pochodzi. Pokusa po jednej awarii każe przywrócić wszystko, co odstawia cię tam, gdzie zacząłeś.

Codex ignoruje twoje instrukcje, a ty obwiniłeś model. Sprawdź budżet bajtowy, zanim sprawdzisz cokolwiek innego. Cięcie na 32 KiB nigdy nie pokazuje się w TUI, a ponieważ pliki projektowe ładują się od korzenia, zabiera najpierw te najbliższe — czyli szczegółowe, które napisałeś najnowsze. Plik przekraczający limit ładuje się tylko częściowo, więc możesz też dostać połowę reguły. Objaw — głębokie, precyzyjne instrukcje ignorowane, podczas gdy ogólnikowe globalne są przestrzegane — czyta się dokładnie jak regres modelu, a nim nie jest. Wariant Codeksa z promptu 2 znajduje to w jednym przebiegu.

Auto-pamięć odbudowuje to, co skasowałeś. W Claude Code to tryb awarii o najdłuższym loncie. Ablatujesz plik, a przez kolejne tygodnie Claude zapisuje własne notatki o twoich korektach do pliku, którego nigdy nie przeglądasz, a który ładuje się do każdej sesji. Akrecja, zautomatyzowana. Uruchamiaj /memory w tym samym rytmie, w jakim przeglądasz plik główny, albo ustaw autoMemoryEnabled: false i kuratoruj ręcznie.

Twój zespół nie zgadza się co do tego, co wycięto. Traktuj archiwum i dziennik jako artefakt do przeglądu, nie tylko plik wynikowy. PR pokazujący “usunęliśmy 140 linii, oto dziennik tego, co faktycznie się psuło przez trzy tygodnie” da się przedyskutować. PR pokazujący usunięcie 140 linii — nie. Blokowe komentarze HTML są w Claude Code darmowe, więc uzasadnienie może mieszkać w samym pliku, nie kosztując kontekstu.

Wszystko, co przeczytałeś, zdezaktualizowało się. Zdezaktualizuje się. Rada odwróciła się raz w ciągu siedmiu miesięcy, a narzędzia zmieniają się szybciej — /doctor dostał kontrolę przycinania w 2.1.206, Cursor dodał zagnieżdżone AGENTS.md i /migrate-to-skills w linii 2.4, a sufit kontekstu Codeksa ruszył się dwukrotnie w samym lipcu 2026. Zastosuj do tego artykułu ten sam test, który stosujesz do innych: sprawdź datę, a potem sprawdź dokumentację narzędzia, zanim zadziałasz na podstawie konkretnej flagi czy ścieżki.