Pisanie CLAUDE.md od zera – tak jak w lekcji o pierwszym takim pliku – ma sens, gdy zaczynasz od pustego katalogu. Gdy w folderze leży już rok twojej pracy, sytuacja jest inna: sporo kontekstu da się z tych plików wyczytać, a przepisywanie tego ręcznie jest dość nudnym zajęciem.

Tu z pomocą przychodzi /init. Polecenie przegląda zawartość projektu i tworzy na tej podstawie pierwszą wersję CLAUDE.md. Ta lekcja prowadzi przez uruchomienie go na twoim własnym folderze i, co ważniejsze, przez to, co zrobić z wynikiem.

Bo wynik nie jest gotowcem. Claude Code zgaduje z tego, co widzi, i część tych domysłów będzie nietrafiona – zadaniem na dziś jest je wyłapać.

Dokumentacja pamięci

Wybierz folder, który realnie coś zawiera

Do tego ćwiczenia potrzebny jest folder, o którym umiesz powiedzieć, czy to, co Claude Code o nim napisze, jest prawdą. Bez tego nie ma jak ocenić wyniku, a cała lekcja jest właśnie o ocenianiu.

Wybierz więc coś, co znasz na wylot: projekt, przy którym siedzisz od kilku miesięcy, katalog z dokumentacją, repozytorium strony.

Jeśli folder jest repozytorium git, tym lepiej: będziesz mieć git diff jako drugą parę oczu na wszystko, co powstanie.

Sprawdź, co Claude Code w ogóle widzi

Otwórz terminal i wejdź do tego folderu poleceniem cd ze ścieżką, na przykład cd ~/projekty/strona-firmowa. Uruchom claude i, zanim wywołasz /init, zadaj pytanie rozpoznawcze:

Rozejrzyj się w tym katalogu i opowiedz, co to za projekt i jak jest zorganizowany.

Odpowiedź jest ciekawa sama w sobie, bo pokazuje, ile kontekstu daje się odczytać z samej struktury plików. Zwykle sporo – nazwy katalogów, pliki konfiguracyjne, README – i zwykle z jednym albo dwoma miejscami, w których Claude Code wyciągnął wniosek zbyt daleko idący.

Zapamiętaj te miejsca. Za chwilę zobaczysz je z powrotem, tym razem zapisane w pliku, i wtedy będą już wyglądać na fakty.

Uruchom /init

Napisz:

/init

Claude Code przechodzi przez zawartość folderu i buduje CLAUDE.md z tego, co znajdzie: komend do budowania i testowania, konwencji, układu katalogów, wszystkiego, co da się wywnioskować z plików. W zależności od zawartości i wielkości folderu trwa to od kilkudziesięciu sekund do kilku minut.

Jedna rzecz, którą warto wiedzieć, jeśli pracujesz też z innymi narzędziami: /init czyta przy okazji reguły Cursora (.cursor/rules/ albo .cursorrules) i Copilota (.github/copilot-instructions.md) i wciąga z nich to, co pasuje. Jeśli więc masz już gdzieś opisane konwencje projektu, nie musisz ich przepisywać.

Gdy skończy, plik jest na dysku. Nie zamykaj jeszcze sesji.

Dokumentacja pamięci

Niech Claude Code wskaże własne domysły

Pierwszy przegląd zleć temu, kto ten plik napisał:

Przejrzyj CLAUDE.md, który przed chwilą powstał. Wypisz, które zdania odczytałeś wprost z plików, a które są twoim domysłem – i przy których najmniej jesteś pewien.

Dostajesz krótką listę zamiast sześćdziesięciu linijek i to ona jest właściwym materiałem do pracy. Domysły to dokładnie te miejsca, w których rozstrzygnąć możesz tylko ty: Claude Code nie będzie wiedzieć, że komponent, który zobaczył, był wyjątkiem, którego nikt nie zdążył poprawić.

Cztery rzeczy pojawiają się w takiej liście najczęściej:

  1. Wnioski wyciągnięte z jednego przykładu. Claude Code zobaczył jeden komponent napisany w danym stylu i opisał to jako konwencję projektu. Bywa, że to był wyjątek, którego nikt nie zdążył poprawić.
  2. Opis stanu zamiast instrukcji. „Projekt używa biblioteki X” to fakt, który Claude Code i tak odczyta z plików przy każdej sesji. Miejsce w pliku warto zajmować tym, czego z plików nie widać – dlaczego akurat X, i czego przy niej nie robić.
  3. Nieaktualne fragmenty struktury. Katalog, który został po poprzedniej wersji projektu, potrafi zostać opisany jak żywa część układu.
  4. Komendy przepisane z README, których nikt już nie używa. Warto sprawdzić, czy podana komenda budowania faktycznie działa – to jedna z tych rzeczy, które w wygenerowanym pliku wyglądają najbardziej wiarygodnie i najczęściej są nieaktualne.

Nie chodzi o to, że /init pisze źle. Chodzi o to, że pisze na podstawie tego, co widzi, a ty widzisz więcej.

Popraw to w rozmowie, nie w edytorze

Wróć do sesji, w której plik powstał, i podyktuj poprawki. To, co wyłapiesz przy czytaniu, wystarczy powiedzieć zwykłym zdaniem:

W CLAUDE.md usuń punkt o konwencji nazewnictwa komponentów – to był jednorazowy wyjątek, nie konwencja projektu. Wyrzuć też opis katalogu legacy, jest martwy od pół roku.

Skreślanie z tego pliku jest bezpieczne: usunięta linijka przestaje trafiać do rozmowy i nic się przez to nie psuje.

Warto być bezwzględnym, bo dłuższy plik działa gorzej. Dokumentacja zaleca trzymanie się poniżej dwustu linijek – nie ze względu na estetykę, tylko dlatego, że rozdmuchany plik zajmuje miejsce w pamięci rozmowy i Claude Code mniej dokładnie się do niego stosuje.

Potem podyktuj to, czego Claude Code nie miał szans wiedzieć. Zwykle jest to najcenniejsza część całego pliku, bo dotyczy rzeczy, których w plikach nie ma:

  • ustalenia z klientem, których nikt nigdzie nie zapisał,
  • historia w rodzaju „tego katalogu nie ruszamy, jest wdrożony osobno”,
  • twoje własne granice – co ma być robione bez pytania, a co zawsze do zatwierdzenia,
  • konwencje, które obowiązują, mimo że kod jeszcze ich nie odzwierciedla.

Formułuj to konkretnie. „Rób wcięcia tabulatorem” jest jasną instrukcją, „pisz ładny kod” już niekoniecznie.

Edytor przydał się do przeczytania pliku i tylko do tego. Zmiany zostawiasz Claude Code – bo to on ułożył ten plik w formie, która jemu pasuje najlepiej, i bo dyktowanie poprawek jest tą samą umiejętnością, którą ćwiczysz przy każdym innym zadaniu.

Dokumentacja pamięci

Sprawdź w nowej sesji

Plik czytany jest przy starcie, więc bieżąca sesja nie zna twoich poprawek. Zamknij ją i uruchom claude jeszcze raz.

Zadaj coś, co wymusi użycie konkretnej instrukcji dopisanej przed chwilą. Nie pytaj ogólnie „czy znasz zasady projektu”, bo dostaniesz streszczenie pliku, a to nie dowodzi niczego poza tym, że plik się wczytał.

Warto sprostować jedno nieporozumienie, które krąży wokół polecenia /init: ta komenda nie tworzy żadnej ukrytej pamięci. Tworzy plik, który możesz otworzyć i przeczytać, i to jest cała jego magia. Claude Code ma osobno mechanizm automatycznej pamięci, w którym sam notuje sobie wnioski z twoich poprawek – to jest coś innego i z tym poleceniem niezwiązanego. Wrócimy do tego w osobnym wpisie.

Dokumentacja pamięci

Uruchom /init drugi raz

Zróbmy mały eksperyment.

Wywołaj /init jeszcze raz, w folderze, w którym CLAUDE.md już istnieje – po twoich poprawkach. Claude Code nie nadpisze pliku. Zamiast tego przejrzy projekt i zaproponuje ulepszenia do tego, co już stoi.

Takie zachowanie zmienia sposób myślenia o tym poleceniu. /init jest narzędziem, do którego można wracać, gdy projekt urósł i plik przestał go opisywać, a nie jednorazowym kreatorem z chwili zakładania projektu. Przy okazji: gdy plik zrobi się za długi, propozycje przycięcia potrafi wygenerować /doctor.

Propozycje z drugiego uruchomienia oceniaj tak samo jak pierwszą wersję – czytając, nie przyjmując. Ta lekcja właściwie w całości jest o tym jednym nawyku.

Dokumentacja pamięci

/init nie potrzebuje dużego projektu. Zadziała też na folderze, w którym leży jeden plik z luźnymi notatkami – mail od szefa z opisem zadania, spisane pomysły, wytyczne rzucone w punktach. Czyta wtedy nie strukturę katalogów, tylko treść, i potrafi wyciągnąć z prozy to, o co w zadaniu chodzi. Wynik oceniaj dokładnie tak samo jak dziś: najpierw poproś o wskazanie domysłów.

Zadania

Odhacz, gdy zrobisz. Stan zapamięta się w przeglądarce, więc możesz wrócić do tej listy jutro.

  • Folder z realną, własną pracą wybrany
  • Pytanie rozpoznawcze zadane przed /init
  • /init wykonane, plik CLAUDE.md powstał
  • Lista domysłów wyciągnięta z Claude Code i przejrzana
  • Nietrafione fragmenty usunięte w rozmowie
  • Podyktowane to, czego Claude Code nie miał skąd wiedzieć
  • Nowa sesja potwierdza, że dopisana instrukcja działa
  • Drugie /init uruchomione, propozycje obejrzane zamiast przyjęte w ciemno