Najlepsze praktyki CLAUDE.md: 9 zasad, które sprawią, że Claude przestanie Cię ignorować (2026)

Najlepsze praktyki CLAUDE.md: 9 zasad, które sprawią, że Claude przestanie Cię ignorować (2026)

Większość postów o najlepszych praktykach CLAUDE.md daje Ci szablon i uznaje sprawę za zakończoną, ale plik, który napisałeś w zeszłym tygodniu, prawdopodobnie jest już ignorowany, a Ty nie wiesz dlaczego. Rozwiązaniem rzadko jest „dodanie więcej reguł”. Zazwyczaj jest odwrotnie. Wdrożyliśmy Claude Code w każdym niedawnym projekcie klienckim i to właśnie te 9 zasad naprawdę przynosi efekty: hierarchia dopasowana do sposobu ładowania plików przez Claude, nieprzekraczalny budżet instrukcji, decyzja dotycząca AGENTS.md oraz sześć powodów, dla których Claude po cichu porzuca Twój plik w trakcie sesji.

Kluczowe wnioski

• CLAUDE.md to pamięć projektu ładowana do kontekstu Claude Code, utrzymuj go poniżej 200 linii, inaczej reguły zaczną znikać.
• Pliki ładują się od góry do dołu: globalne, główny katalog projektu, podkatalogi (leniwie) oraz CLAUDE.local.md (osobiste, ignorowane przez git).
• Używaj AGENTS.md, jeśli korzystasz również z Cursor lub Copilot; utwórz dowiązanie symboliczne CLAUDE.md do AGENTS.md, aby obsługiwać oba narzędzia jednocześnie.
• Jeśli Claude ignoruje Twój plik, w 90% przypadków winna jest długość, niejasność lub brak wyjaśnienia „dlaczego”.

Co tak naprawdę robi CLAUDE.md (i dlaczego to ważne)

W skrócie: CLAUDE.md to plik markdown, który Claude Code odczytuje jako pamięć projektu na początku każdej sesji. Nie jest to prompt systemowy, hook ani umiejętność (skill), lecz kontekst doradczy, który kieruje Claude ku konwencjom Twojego zespołu. Myśl o tym mniej jak o dokumentacji, a bardziej jak o pliku konfiguracyjnym, który Twój programista AI rzeczywiście czyta.

Wiele zespołów pisze CLAUDE.md jak README. To pierwszy błąd. README wyjaśnia projekt ludziom, którzy mogą go przeglądać i pomijać fragmenty. CLAUDE.md jest konsumowany w całości przez Claude Code na początku sesji, a każda linia kosztuje tokeny i wpływa na przestrzeganie reguł. Jest znacznie bliżej pliku konfiguracyjnego lub zestawu fixture'ów testowych niż dokumentacji.

To także nie jedyny sposób na sterowanie Claude. Hooki wykonują deterministyczne akcje (formatowanie, blokowanie commitów). Umiejętności (Skills) grupują wielokrotnego użytku przepływy pracy. CLAUDE.md znajduje się pomiędzy nimi jako kontekst doradczy; Claude ocenia go, czasami go nadpisuje i zdecydowanie zapomina części, jeśli napiszesz za dużo. To rozróżnienie jest fundamentem dla wszystkiego, co poniżej, i dlatego CLAUDE.md jest jednym z narzędzi w szerszej praktyce inżynierii kontekstu, a nie srebrną kulą.

Zasada nr 1: Traktuj to jak kod, nie jak dokumentację. Wersjonuj go. Przeglądaj zmiany w PR-ach. Ocinaj go tak, jak refaktoryzowałbyś rozdęty moduł. Według przewodnika Anthropic po CLAUDE.md, plik jest ładowany z tym samym priorytetem co każda instrukcja systemowa, co oznacza, że przestarzała reguła sprzed sześciu miesięcy nadal aktywnie kształtuje każdą dzisiejszą odpowiedź.

Jak ładuje się CLAUDE.md: Czteropoziomowa hierarchia

W skrócie: Claude Code ładuje CLAUDE.md z czterech poziomów: globalnego (~/.claude/CLAUDE.md), głównego katalogu projektu, CLAUDE.local.md dla osobistych nadpiszeń oraz plików w podkatalogach, które ładują się leniwie tylko wtedy, gdy Claude odczytuje pliki wewnątrz tego katalogu. Sąsiednie podkatalogi nigdy nie widzą swoich plików CLAUDE.md, co utrzymuje pamięć claude code ściśle ograniczoną.

Hierarchia jest najbardziej niezrozumianą częścią CLAUDE.md i to tutaj żaden z 5 najlepszych wyników SERP nie zagłębia się wystarczająco. Oto, co tak naprawdę dzieje się pod maską:

Dwa terminy wartue zapamiętania: leniwe ładowanie i izolacja sąsiadów.

Leniwe ładowanie oznacza, że CLAUDE.md z podkatalogu nie trafia do kontekstu Claude, dopóki Claude faktycznie nie otworzy pliku wewnątrz tego katalogu. Jeśli poprosisz o „naprawienie błędu logowania”, a Claude dotyka tylko backend/, Twój frontend/CLAUDE.md nigdy się nie załaduje. To dobrze, utrzymuje czyste okno kontekstowe, ale gryzie zespoły, które umieszczają krytyczne reguły w podkatalogach, oczekując, że będą one zawsze stosowane.

Izolacja sąsiadów jest tego konsekwencją: frontend/CLAUDE.md i backend/CLAUDE.md nigdy nie ładują się nawzajem. Współdzielą tylko to, co znajduje się w głównym katalogu projektu. Jeśli więc reguły frontendu contradicują reguły backendu, to nie problem. Jeśli muszą dzielić konwencję, przenieś ją do pliku głównego.

CLAUDE.local.md to awaryjne wyjście. Jest ładowany, ale nie commitowany, idealny do nadpisania w stylu „wolę pnpm, ale zespół standaryzował npm”. Haczyk: nie jest automatycznie ignorowany przez git. Musisz dodać to samodzielnie. Zapomnij o tym, a commitujesz swoje osobiste reguły do repozytorium zespołu.

Zasada nr 4: Dopasuj instrukcje do miejsc, w których Claude je faktycznie czyta. Reguły stylów dla komponentów React należą do frontend/CLAUDE.md, a nie do katalogu głównego. Reguły migracji bazy danych należą do backend/. Dokumentacja Anthropic Memory (zaktualizowana w listopadzie 2025) potwierdza to; zachowanie leniwego ładowania jest celowe i kluczowe.

Co umieścić w CLAUDE.md (a co pominąć)

W skrócie: Do CLAUDE.md trafia wszystko, czego Claude nie może wywnioskować z Twojego kodu: polecenia budowania, konwencje nazewnictwa, antywzorce, na których zespół się sparzył, oraz dlaczego za każdą regułą. Pomijamy wszystko, co jest w README, wszystko w package.json i każdą regułę, która zmienia się co tydzień. Instrukcje claude code powinny być możliwe do przetestowania i konkretne.

Oto minimalny CLAUDE.md, który faktycznie ma wartość:

# Project: techsy-app

## Commands
- Build: `pnpm build` (Turbopack — Webpack flags don't apply)
- Test: `pnpm test --run` (we use Vitest, not Jest)
- Lint: `pnpm lint` (will fail CI on warnings, not just errors)

## Conventions
- Server components by default. Add `'use client'` only when truly needed.
  Why: we hit 8s LCP last quarter from over-clienting.
- Database access only via `lib/db/` helpers — never raw SQL in routes.
  Why: row-level security policies live in those helpers.
- Tests colocate as `*.test.ts` next to the file under test.

## Don'ts
- Don't add a new dependency without opening a PR comment first.
- Don't use `any` — use `unknown` and narrow.

## Where to look
- Schema: `db/schema.ts`
- Auth flow: `lib/auth/README.md`

Teraz porównaj to z wersją antywzorca, którą wysyła większość zespołów:

# Project Rules

- Write clean, maintainable code.
- Follow best practices.
- Use TypeScript properly.
- Make sure tests pass.
- Be consistent with existing patterns.
- Document complex logic.

Drugi plik nie jest błędny. Jest po prostu bezużyteczny. Claude już chce pisać czysty kod. „Bądź spójny” nie mówi Claude, z którym wzorcem ma być spójny. Publiczne przykłady inżyniera Anthropic, Borisa Cherny’ego, mocno skłaniają się ku pierwszemu stylowi: konkretne polecenia, nazwane narzędzia i dlaczego stojące za decyzjami, które nie są oczywiste z samej bazy kodu.

Zasada nr 2: Bądź konkretny, nie aspiracyjny. „Pisz czysty kod” jest aspiracyjny. „Komponenty serwerowe domyślnie; dodawaj 'use client' tylko wtedy, gdy jest to naprawdę konieczne” jest możliwe do przetestowania. Ta sama dyscyplina leży u podstaw dobrego inżynierii promptów: konkretne, możliwe do przetestowania instrukcje biją na głowę vague aspiracje, niezależnie od tego, czy żyją w prompcie, czy w CLAUDE.md.

Zasada nr 3: Wyjaśnij, dlaczego każda reguła ma znaczenie. „Dlaczego” to nie wypełniacz, to sposób, w jaki Claude podejmuje decyzje w przypadkach brzegowych. Reguła z powodem („mieliśmy 8s LCP przez nadmierne używanie klienta”) uogólnia się na podobne sytuacje. Reguła bez powodu jest ignorowana w momencie zmiany kontekstu. Wzorzec ten jest również opisany w przewodniku Builder.io po CLAUDE.md.

Dlaczego Claude ignoruje Twój CLAUDE.md? Budżet instrukcji

W skrócie: Claude nie jest złośliwy, kończa mu się uwaga. Powyżej około 80 linii zauważysz wypadanie reguł; powyżej 200 linii duże bloki są całkowicie ignorowane; powyżej 500 słów gęstych reguł, przestrzeganie załamuje się. Rozwiązaniem jest budżet instrukcji. Traktuj każdą linię jako koszt dla pamięci claude code i przestrzegania poszczególnych reguł.

Niedawne badania potwierdzają to, co użytkownicy produkcyjni ciągle odkrywają: przestrzeganie instrukcji degraduje się nieliniowo wraz z liczbą reguł. Artykuł arxiv 2507.11538 dotyczący pojemności przestrzegania instrukcji pokazuje, że przestrzeganie per reguła spada, gdy ich nakładasz więcej, a analiza HumanLayer dotycząca CLAUDE.md w produkcji powtarza to samo odkrycie.

Przekład: każda dodana reguła sprawia, że każda inna reguła jest nieco mniej prawdopodobna do wykonania. Więc CLAUDE.md o długości 400 linii nie jest 4x skuteczniejszy niż ten o 100 liniach. Często jest mniej skuteczny, ponieważ reguły, na których naprawdę Ci zależy, są rozcieńczane przez te, które napisałeś w piątek trzy miesiące temu i nigdy nie usunąłeś.

W naszych plikach CLAUDE.md wszystko powyżej linii 150 zaczyna widocznie tracić na przestrzeganiu. Przy linii 250 widzieliśmy, jak Claude pomija całe sekcje. Dlatego wprowadzamy limit.

wc -l CLAUDE.md

To całe narzędzie. Uruchom je. Jeśli masz ponad 200, przekroczyłeś budżet. Twarda zasada, którą wdrażamy u klientów:

Traktuj CLAUDE.md jak budżet 200 linii. Każda linia kosztuje przestrzeganie. Wydawaj go tam, gdzie to matters.

Zasada nr 1 wzmocniona: Utrzymuj krótkość. Poniżej 200 linii. Poniżej 500 słów gęstych reguł. Jeśli łapiesz się na dodawaniu reguł automatyzacji („zawsze uruchamiaj prettier po edycjach”), prawdopodobnie należą one do hooków Claude Code; hooki są deterministyczne i nie kosztują tokenów z budżetu instrukcji.

Czy używać CLAUDE.md, AGENTS.md, .cursorrules, czy copilot-instructions?

W skrócie: Jeśli używasz tylko Claude Code, CLAUDE.md jest w porządku. Jeśli używasz dwóch lub więcej agentowych CLI (Codex, Cursor, Copilot, Sourcegraph), przełącz się na AGENTS.md i utwórz dowiązanie symboliczne CLAUDE.md do AGENTS.md. AGENTS.md pojawiło się pod koniec 2025 roku jako standard między narzędziami; większość nowoczesnych agentów korzysta z niego jako fallbacku, więc jeden plik zasila cały ekosystem.

To pytanie, na które żaden z 5 najlepszych wyników nie odpowiada. Oto macierz:

Sztuczka podwójnego targetowania to jedna linia:

ln -s AGENTS.md CLAUDE.md

To wszystko. Teraz Claude Code, Codex i każde narzędzie świadome AGENTS.md czytają ten sam plik. Aktualizuj raz, każdy agent to pobierze. Specyfikacja AGENTS.md jest otwarta i celowo minimalna; to po prostu markdown z konwencjonalnymi sekcjami.

Dwa realne zgrzyty. Po pierwsze: jeśli Twój zespół ma power usera Cursor, .cursorrules od Cursor przyjmuje inne podejście: pojedynczy plik, brak hierarchii, bardziej sztywny format. Niektóre zespoły utrzymują oba: AGENTS.md dla wspólnych reguł, .cursorrules dla specyficznych dziwactw Cursor. Po drugie: .github/copilot-instructions.md od Copilota nie korzysta z fallbacku do AGENTS.md, więc zespoły mocno oparte na Copilocie potrzebują osobnego pliku.

Jeśli wybierasz stos agentów od zera, nasze zestawienie Claude Code vs Cursor vs Copilot omawia kompromisy na poziomie użytkowania. W skrócie: hierarchia Claude Code jest najpotężniejsza dla monorepo, UX Cursor wygrywa przy pracy solo, a integracja IDE Copilota jest nadal najpłynniejsza przy stopniowym wdrażaniu.

Zasada nr 9: Używaj AGENTS.md, jeśli uruchamiasz więcej niż jedno agentowe CLI. Nie utrzymuj dwóch plików mówiących to samo. Wybierz plik, który czyta większość Twojego stosu, a resztę dowiąż symbolicznie.

CLAUDE.md vs Hooki vs Umiejętności: Trójkąt decyzyjny

W skrócie: CLAUDE.md = kontekst doradczy. Hooki = deterministyczne akcje. Umiejętności = grupowane możliwości. Wybierz źle, a spalysz budżet instrukcji na coś, co powinien obsłużyć hook, albo napiszesz regułę CLAUDE.md dla czegoś, co dostarczyć może tylko umiejętność. Trójkąt to najtańszy sposób na utrzymanie szczupłości CLAUDE.md.

Trzy narzędzia, trzy zadania. Błąd, który widzimy najczęściej: umieszczanie „zawsze uruchamiaj prettier po edycji” w CLAUDE.md. Claude to czyta. Claude czasami uruchamia prettier. Jesteś sfrustrowany. Rozwiązaniem jest przeniesienie tej linii z CLAUDE.md do hooka, ponieważ hooki odpalają się deterministycznie za każdym razem, bez doradczego marginesu swobody.

Jeśli reguła musi zawsze się odpalić, należy do hooka. Jeśli jest to preferencja stylu, którą Claude może ocenić w kontekście, należy do CLAUDE.md. Jeśli jest to wieloetapowy przepływ pracy z grupowanymi zasobami (szablony, skrypty, prompty), należy do umiejętności.

Zasada nr 8: Prawidłowo wybierz między CLAUDE.md a hookami a umiejętnościami; umieszczenie hooka w CLAUDE.md to najczęstsze marnotrawstwo budżetu instrukcji. Konfiguruj deterministyczne akcje za pomocą hooków Claude Code i pakuj wielokrotnego użytku przepływy pracy jako umiejętności Claude. Twój CLAUDE.md staje się krótszy, Twoje guardraile mocniejsze, a Claude przestaje „zapominać” reguły, które mają znaczenie.

Wzorce Monorepo: Zagnieżdżone CLAUDE.md, @imports i .claude/rules/

W skrócie: W monorepo utrzymuj główny CLAUDE.md tiny, tylko wskaźniki i wspólne konwencje. Przesuwaj szczegóły do apps/*/CLAUDE.md, aby każde poddrzewo miało zakresowane reguły. Używaj @imports, aby udostępniać modularne pliki reguł przez .claude/rules/. To jest progresywne ujawnianie, Claude pobiera każdą część tylko wtedy, gdy jest istotna.

Typowe drzewo CLAUDE.md w monorepo:

.
├── CLAUDE.md                        # 30 lines — points to subdirs and shared rules
├── .claude/
│   └── rules/
│       ├── style.md
│       ├── testing.md
│       └── security.md
├── apps/
│   ├── web/
│   │   └── CLAUDE.md                # Next.js-specific rules
│   └── api/
│       └── CLAUDE.md                # Fastify-specific rules
└── packages/
    └── shared/
        └── CLAUDE.md                # Library author rules

Składnia @import pozwala plikowi głównemu pobierać wspólne fragmenty reguł bez ich ponownego statedowania:

# Root CLAUDE.md

This is a Turborepo. See subdir CLAUDE.md for app-specific rules.

@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md

## Top-level commands
- `pnpm dev` runs all apps in parallel
- `pnpm test` runs every workspace's test script

To jest progresywne ujawnianie w praktyce. Plik główny to wskaźnik o 30 liniach. Każdy CLAUDE.md w podkatalogu dodaje 50–80 linii skupionych reguł. Pliki w .claude/rules/ przechowują fragmenty konwencji, które wiele podkatalogów może pobierać. Nic nie jest duplikowane, nic nie jest pomijane i żaden pojedynczy plik nie przekracza budżetu instrukcji.

Reguła leniwego ładowania z wcześniej ma tu jeszcze większe znaczenie: gdy Claude pracuje nad apps/web/Button.tsx, widzi plik główny plus apps/web/CLAUDE.md plus pliki reguł zaimportowane przez @import. Nie widzi apps/api/CLAUDE.md. To jest sedno sprawy, konwencje backendu nie zanieczyszczają kontekstu frontendu, a Twoje okno kontekstowe pozostaje użyteczne.

Zasada nr 6: Używaj @imports, aby utrzymać plik główny poniżej 200 linii. Przewodnik Najlepsze praktyki dla Claude Code od Anthropic traktuje to jako standardowy wzorzec monorepo. Subagenci dziedziczą też kontekst CLAUDE.md rodzica, co warto wiedzieć, jeśli zagnieżdżasz przepływy pracy; zobacz inżynierię kontekstu, aby zobaczyć, jak to współgra z projektowaniem subagentów.

6 powodów, dla których Claude ignoruje Twój plik (i poprawka dla każdego)

W skrócie: Gdy Claude ignoruje CLAUDE.md, prawie zawsze jest to jedna z sześciu przyczyn: plik za długi, vague sformułowania, brak „dlaczego”, kompaktowanie kontekstu, konfliktny plik nadrzędny lub zła nazwa pliku. Każda ma 60-sekundową poprawkę. Testuj w nowej sesji po każdej zmianie, to Zasada nr 7.

1. Plik za długi (>200 linii / >500 słów)

Uruchom wc -l CLAUDE.md. Jeśli jest powyżej 200, tnij agresywnie. Przenieś reguły automatyzacji do hooków. Przenieś przepływy pracy do umiejętności. Podziel wspólne fragmenty na .claude/rules/ i pobieraj je za pomocą @import. Najczęstszym powodem, dla którego Claude „przestał przestrzegać” Twoich reguł, jest to, że plik z czasem stał się za długi, a przestrzeganie po cichu upadło.

2. Vague sformułowania („pisz czysty kod”)

Zastąp każdą aspiracyjną regułę konkretną, możliwą do przetestowania. „Bądź spójny” jest niewidzialne dla Claude. „Używaj domyślnie komponentów serwerowych; dodawaj 'use client' tylko do formularzy lub interaktywnego UI” to coś, co Claude może faktycznie zastosować.

3. Brak „dlaczego”

Reguły bez powodów nie uogólniają się. Claude nie może wywnioskować, kiedy nagiąć regułę, ponieważ nie wie, przed czym reguła chroni. Każda nieoczywista reguła dostaje jedną linię: „używamy unknown, a nie any, ponieważ mieliśmy trzy crashy runtime z odpowiedzi API typowanych jako any w ostatnim kwartale”.

4. Kompaktowanie kontekstu go odrzuciło

Długie sesje wywołują kompaktowanie; Claude podsumowuje wcześniejszy kontekst, aby zmieścić się w oknie, a zawartość CLAUDE.md bywa czasem podsumowywana w nicość. Poprawka: /clear po dużych wypalenach kontekstu lub całkowite restartowanie sesji. Dokładnie to surfuje GitHub Issue #17530.

5. Konfliktny nadrzędny CLAUDE.md

Globalny mówi „używaj 4 spacji”. Główny projektu mówi „używaj 2 spacji”. Podkatalog nic nie mówi. Claude wybiera jeden, czasami ten zły. Audytuj ~/.claude/CLAUDE.md i główny projektu pod kątem sprzeczności. Ten, który jest bardziej specyficzny, powinien wygrać, ale tylko jeśli uczynisz to wyraźnym.

6. Zła lokalizacja pliku lub wielkość liter w nazwie

Claude.md i CLAUDE.md to różne pliki w Linuxie i macOS. Tak samo claude.md i CLAUDE.md. Potwierdź, że ścieżka to dokładnie ./CLAUDE.md (wszystkie duże litery) i potwierdź, że Claude Code jest uruchamiany z katalogu, który go zawiera. GitHub Issue #668 jest pełen przypadków, gdzie plik istniał, ale Claude nie mógł go zobaczyć przez ścieżkowanie.

Zasada nr 7: Testuj w nowej sesji. Po każdej zmianie w CLAUDE.md otwórz nową sesję i poproś Claude o „podsumowanie reguł w CLAUDE.md”. Jeśli podsumowanie czegoś pomija, plik nie robi swojej roboty.

Twój pierwszy CLAUDE.md w 10 minut: Starter w 5 krokach

W skrócie: Uruchom /init, aby wygenerować szkic, przytnij go do 6–10 prawdziwych reguł z powodami, dodaj 3 polecenia, które Claude powinien znać, dodaj 2 antywzorce, na które natknął się Twój zespół, a następnie przetestuj w nowej sesji, prosząc Claude o podsumowanie pliku. Całkowity czas: około 10 minut. Ten 5-etapowy przepis stosujemy pierwszego dnia w każdym nowym repo.

1. Uruchom /init, aby wygenerować szkic. Polecenie /init w Claude Code skanuje Twoje repo i pisze startowy CLAUDE.md. Nie wysyłaj tego, co napisze. Wynik /init to punkt wyjścia, a nie gotowy plik, i szczerze mówiąc, większość tego, co generuje, można usunąć.

2. Przytnij go do 6–10 linii rzeczywistych reguł z powodami. Usuń wszystko generic. Usuń wszystko, co jest w README. Zachowaj tylko reguły, których Claude nie może wywnioskować z samego kodu.

3. Dodaj 3 polecenia, które Claude powinien znać. Build, test, lint. Dołącz dokładne polecenie i wszelkie nieoczywiste flagi. Jeśli używasz Vitest, a nie Jest, powiedz to.

4. Dodaj 2 antywzorce, na które ten zespół natknął się. Prawdziwe. „Nie używaj any, bo mieliśmy trzy crashy runtime” bije „używaj TypeScript poprawnie” za każdym razem.

5. Otwórz świeżą sesję i zweryfikuj. Poproś Claude o „podsumowanie reguł w CLAUDE.md”. Jeśli czegoś brakuje, plik jest za długi, zbyt vague lub brakuje „dlaczego”. Napraw i powtórz.

Zasada nr 5: Nie generuj automatycznie tylko z /init. /init to punkt wyjścia, a nie gotowy plik. Te 8 minut spędzone na przycinaniu to miejsce, gdzie tkwi wartość.

FAQ

Co to jest plik CLAUDE.md?

Plik CLAUDE.md to plik markdown, który Claude Code odczytuje jako pamięć projektu na początku każdej sesji. Mówi Claude o Twoich konwencjach, poleceniach i antywzorcach, aby nie musiał zgadywać. Działa na czterech poziomach: globalnym, głównym projektu, podkatalogowym (ładowanym leniwie) oraz osobistym CLAUDE.local.md, który utrzymujesz ignorowany przez git.

Jak długi powinien być plik CLAUDE.md?

Poniżej 200 linii i poniżej 500 słów gęstych reguł. Powyżej tych progów, przestrzeganie instrukcji przez Claude degraduje się; każda dodana reguła sprawia, że każda inna jest nieco mniej prawdopodobna do wykonania. Traktuj to jako stały budżet. Jeśli potrzebujesz więcej, podziel na pliki CLAUDE.md w podkatalogach i użyj @import dla wspólnych fragmentów.

Gdzie powinienem umieścić CLAUDE.md?

Główny trafia do głównego katalogu projektu (./CLAUDE.md) i jest commitowany. Dodaj pliki CLAUDE.md w podkatalogach dla reguł specyficznych dla aplikacji w monorepo. Umieść preferencje międzyprojektowe w ~/.claude/CLAUDE.md. Użyj CLAUDE.local.md dla osobistych nadpisień, których nie chcesz commitować, ale pamiętaj, aby ręcznie dodać je do gitignore.

Dlaczego Claude ignoruje mój CLAUDE.md?

W 90% przypadków jest to jedna z trzech rzeczy: plik jest za długi (powyżej 200 linii), reguły są vague („pisz czysty kod”) lub regułom brakuje „dlaczego”, którego Claude może użyć do ich zastosowania. Uruchom wc -l CLAUDE.md, a następnie przeprowadź audyt pod kątem specyficzności. Testuj zmiany w nowej sesji, prosząc Claude o podsumowanie pliku.

Czy powinienem używać CLAUDE.md czy AGENTS.md?

Jeśli Twój zespół używa tylko Claude Code, zostań przy CLAUDE.md. Jeśli używasz dwóch lub więcej agentowych CLI (Codex, Cursor, Sourcegraph), przełącz się na AGENTS.md i utwórz dowiązanie symboliczne CLAUDE.md do niego: ln -s AGENTS.md CLAUDE.md. Większość nowoczesnych agentowych CLI korzysta z fallbacku do AGENTS.md, więc jeden plik zasila każde narzędzie.

Czy powinienem uruchomić /init, aby wygenerować CLAUDE.md?

Tak, jako szkic. Nie, jako gotowy plik. /init skanuje Twoje repo i produkuje starter, ale jest rozwlekły i generic. Zarówno Anthropic, jak i HumanLayer zalecają agresywne przycinanie po uruchomieniu /init. Te 8 minut spędzone na cięciu i dodawaniu linii „dlaczego” to moment, w którym plik staje się faktycznie użyteczny.

Jak działają pliki CLAUDE.md w monorepo?

Główny CLAUDE.md pozostaje tiny, tylko wskaźniki i wspólne reguły. Każda aplikacja otrzymuje własny apps/*/CLAUDE.md ze scope'owanymi konwencjami. Pliki w podkatalogach ładują się leniwie tylko wtedy, gdy Claude czyta pliki wewnątrz tego poddrzewa, więc sąsiedzi pozostają izolowani. Użyj @import .claude/rules/style.md, aby udostępniać modularne fragmenty reguł bez duplikowania ich across apps.

Jaka jest różnica między CLAUDE.md, hookami a umiejętnościami?

CLAUDE.md to kontekst doradczy, Claude go czyta i zazwyczaj stosuje. Hooki to deterministyczne akcje, które zawsze się odpalają (formatowanie, blokowanie commitów). Umiejętności to grupowane możliwości dla wielokrotnego użytku przepływów pracy z zasobami. Używaj CLAUDE.md do wytycznych stylistycznych, hooków do twardych reguł, a umiejętności do wieloetapowych zadań, które będziesz powtarzać across projects.

Jak Techsy podchodzi do tego

W Techsy każdy projekt Claude Code, który wdrażamy, ma CLAUDE.md poniżej 150 linii i dowiązanie symboliczne AGENTS.md. Traktujemy plik jak kod, wersjonujemy go, przeglądamy zmiany w PR-ach i ponownie testujemy w świeżych sesjach przed merge'em. Potrzebujesz pomocy w wpięciu agentów AI do swojego workflow deweloperskiego? Umów bezpłatną konsultację.