CLAUDE.md i Tryb Planowania (Plan Mode)

Dotarliśmy do prawdziwych skarbów, @name! Te dwie rzeczy dzielą zwykłe "gadanie z AI" od profesjonalnego vibecodingu z Claude Code.

CLAUDE.md - serce projektu

Najważniejszy plik w pracy z Claude Code to CLAUDE.md - leży w katalogu głównym projektu, a Claude automatycznie wczytuje go na początku każdej sesji. To Twoja mapa, wręczana nawigatorowi, zanim jeszcze postawi stopę na pokładzie: kurs zna, zanim wykona pierwszy manewr.

Warto od razu ustalić, czym ten plik jest, bo tu najłatwiej o pomyłkę. CLAUDE.md to markdownowy plik pamięci projektu - trzymasz w nim konwencje, architekturę i komendy, a Claude wczytuje go automatycznie na początku każdej sesji. Nie jest to plik konfiguracyjny npm, który zastępowałby

package.json

. Nie jest to log z błędami kompilatora TypeScript. I na pewno nie jest to plik binarny z modelem Claude w środku. To zwyczajny tekst - przeczytasz go, poprawisz i wrzucisz do repozytorium tak samo jak każdy inny plik.

Co umieścić w CLAUDE.md?

• Konwencje - jak nazywać pliki, jaki styl kodu, jak formatować
• Architektura - struktura katalogów, kluczowe moduły
• Komendy - jak uruchomić projekt, testy, linter, build

Jak go wygenerować?

Najprościej - niech Claude zrobi to za Ciebie. Wpisz w sesji:

1/init

Dalej zawsze dzieje się to samo, w tej samej kolejności: wpisujesz komendę

/init

w sesji, Claude analizuje strukturę projektu, powstaje gotowy plik CLAUDE.md w katalogu głównym, a Claude automatycznie wczytuje go w każdej kolejnej sesji. Od tego momentu nie musisz o nim pamiętać - to on pamięta o Tobie. Wygenerowaną wersję możesz oczywiście dopracować ręcznie albo otworzyć prosto z sesji komendą

/memory

. I to właśnie

/memory

edytuje pamięć projektu - nie

/save

, nie

/context

ani

/file

, bo takich komend w Claude Code po prostu nie ma.

Hierarchia plików CLAUDE.md

Claude nie czyta jednego pliku, tylko całą hierarchię - od najbardziej globalnego do najbardziej szczegółowego:

• ~/.claude/CLAUDE.md

  - globalny, działa we wszystkich projektach

• CLAUDE.md

  - w katalogu głównym projektu

• CLAUDE.md

  w podkatalogu projektu - dla konkretnej części kodu

Im bliżej kodu leży plik, tym bardziej szczegółowe reguły w nim trzymasz i tym większą mają wagę. Claude scala wszystkie poziomy, a przy sprzeczności wygrywa ten najbliższy. Globalny mówi, jak pracujesz w ogóle. Projektowy opisuje ten jeden statek. Ten z podkatalogu - jeden konkretny pokład. A tak wygląda przykładowy CLAUDE.md projektu:

1# Moj Projekt - Sklep Online
2
3## Stack
4- Next.js + TypeScript
5- Tailwind CSS
6- Prisma + PostgreSQL
7
8## Komendy
9- `npm run dev` - serwer deweloperski
10- `npm test` - testy
11- `npm run lint` - linter
12
13## Konwencje
14- Komponenty: PascalCase w src/components/
15- Zawsze dodawaj typy TypeScript
16- Testy obok plikow, w katalogu __tests__/

Zapamiętaj ten układ, bo to bardzo dobry domyślny szkielet. Najpierw tytuł projektu - # Mój Projekt - Sklep Online. Zaraz pod nim ## Stack (Next.js, TypeScript, Tailwind), czyli z czego statek jest zbudowany. Dalej ## Komendy (npm run dev, npm test) - jak nim pływać. Na końcu ## Konwencje (PascalCase, typy TypeScript) - zasady obowiązujące załogę. Stack przed komendami, komendy przed konwencjami: najpierw mówisz Claude, z czym ma do czynienia, potem jak to uruchomić, a na końcu czego się trzymać przy pisaniu. Nic egzotycznego - to zwykły markdown, który sam z przyjemnością przeczytasz pół roku później.

Tryb planowania (Plan Mode) - najnowsza moc

To jedna z najnowszych i najważniejszych funkcji Claude Code. W trybie planowania Claude najpierw bada projekt i przedstawia plan, a edytuje pliki dopiero po Twojej akceptacji.

Idealne do dużych i ryzykownych zmian - widzisz, co Claude zamierza zrobić, ZANIM ruszy choćby jedną linię. Zwróć przy okazji uwagę, czego tryb planowania nie robi: nie usuwa wszystkich plików, żeby zacząć od zera, nie jest trybem offline działającym bez modelu i - wbrew nazwie - nie ma nic wspólnego z otwieraniem kalendarza. Planuje kod, nie Twój tydzień.

Jak włączyć tryb planowania?

Dwie drogi prowadzą w to samo miejsce:

1. Klawiszem Shift+Tab - przełącza tryby uprawnień w trakcie sesji, a jednym z nich jest właśnie tryb planowania
2. Flagą przy starcie:

1claude --permission-mode plan "Przebuduj system autoryzacji na JWT"

Zapamiętaj dokładną kolejność elementów: najpierw

claude

, potem

--permission-mode

, potem

plan

, a na samym końcu prompt w cudzysłowie - "Przebuduj system autoryzacji na JWT". Flaga nazywa się

--permission-mode plan

i tylko ona uruchomi sesję w trybie planowania. Po sieci krążą podobnie brzmiące zaklęcia, których w Claude Code nie ma: żadne

--temperature plan

,

--glob plan

ani

--output plan

nie zadziała. Jeśli piszesz tę komendę z pamięci, przelicz cztery elementy po kolei - to najczęstsze miejsce, w którym początkujący gubią kurs.

Tryby uprawnień (permission modes)

Claude Code ma kilka trybów, które decydują, jak dużo wolno mu zrobić samodzielnie:

• default

  - pyta o zgodę przed ważnymi akcjami (tryb domyślny)

• plan

  - tylko planuje i bada, nie edytuje, dopóki nie zatwierdzisz

• acceptEdits

  - automatycznie akceptuje edycje plików przez Claude

• bypassPermissions

  - pomija pytania o uprawnienia (ostrożnie!)

Ustaw je od najbardziej ostrożnego do najbardziej samodzielnego, a wyjdzie:

plan

, potem

default

, potem

acceptEdits

, na końcu

bypassPermissions

. Nazwa

acceptEdits

bywa myląca, więc rozłóż ją na czynniki: accept plus edits, czyli akceptuje edycje. On nie blokuje edytowania plików - robi dokładną odwrotność blokady, po prostu przestaje o nie pytać. Nie ma też nic wspólnego z temperaturą modelu i, rzecz jasna, nie kasuje Twojego CLAUDE.md. Między trybami przeskakujesz w locie klawiszem Shift+Tab albo ustawiasz je od startu flagą

--permission-mode

.

Workflow z trybem planowania

Duża zmiana rozgrywa się zawsze w czterech aktach:

1# 1. Wlacz tryb planowania
2claude --permission-mode plan "Dodaj koszyk zakupowy do sklepu"
3
4# 2. Claude bada projekt i przedstawia PLAN:
5#    - jakie pliki utworzy
6#    - jakie zmodyfikuje
7#    - w jakiej kolejnosci
8
9# 3. Czytasz plan i go akceptujesz
10
11# 4. Dopiero teraz Claude wykonuje zmiany w kodzie

Ta kolejność nigdy się nie zmienia: włączasz tryb planowania (

--permission-mode plan

), Claude bada projekt i przedstawia plan zmian, czytasz plan i go akceptujesz, a na końcu Claude wykonuje zmiany w kodzie. Krok trzeci to Twoja siatka bezpieczeństwa i najtańsza inwestycja w całym procesie. Błąd wyłapany w planie kosztuje trzydzieści sekund i jedno zdanie w rozmowie. Ten sam błąd wyłapany w piętnastu już zmienionych plikach kosztuje wieczór, a czasem i zaufanie do narzędzia. Rafę lepiej zobaczyć na mapie niż pod kilem.

Ustawienia i uprawnienia (settings.json)

Zachowaniem Claude Code sterujesz przez pliki ustawień:

• .claude/settings.json

  - ustawienia projektu (commitowane do repo)

• ~/.claude/settings.json

  - ustawienia globalne

To właśnie w

.claude/settings.json

definiujesz reguły uprawnień dla projektu, czyli wzorce allow i deny. Zapamiętaj tę ścieżkę, bo w starszych poradnikach krąży kilka nieistniejących: nie ma pliku

.claude/temperature.json

, nie ma

claude.config.js

, a

tsconfig.json

należy do TypeScriptu i o Claude nie wie zupełnie nic.

1// .claude/settings.json
2{
3  "permissions": {
4    "allow": [
5      "Bash(git*)",
6      "Bash(npm run test)"
7    ],
8    "deny": [
9      "Bash(rm -rf*)"
10    ]
11  }
12}

Wzorzec

Bash(git*)

czytaj po kawałku, od lewej do prawej: nazwa narzędzia

Bash

, nawias otwierający

(

, wzorzec komendy

git*

, nawias zamykający

)

. Cztery elementy, zawsze w tej samej kolejności. Efekt jest natychmiastowy: polecenia

git

wykonują się bez pytania i przestajesz klikać "tak" dwadzieścia razy dziennie, a niebezpieczne

rm -rf

jest zablokowane na amen - nawet gdybyś sam o nie poprosił w chwili słabości. W tym samym pliku ustawisz też zmienne środowiskowe, domyślny model i hooki, o których opowiem w następnym ćwiczeniu.

Zarządzanie kontekstem w długich sesjach

Im dłuższa rozmowa, tym więcej kontekstu zużywasz - a kontekst to ładownia o skończonej pojemności. Dwie komendy trzymają w niej porządek:

1# Wyczysc kontekst i zacznij od czystej karty
2/clear
3
4# Stresc dotychczasowa rozmowe i kontynuuj (zachowuje sedno, oszczedza tokeny)
5/compact

Różnica jest prosta:

/clear

czyści kontekst i zaczyna rozmowę od czystej karty, a

/compact

podsumowuje i kontynuuje długą rozmowę - zachowuje sedno, a odzyskuje tokeny. Tę drugą wpisujesz jako ukośnik

/

i słowo

compact

, dokładnie w tej kolejności. I to cały zestaw narzędzi do kontekstu: komendy

/context show

ani

/context clear

nie istnieją, kontekstem jak najbardziej da się zarządzać - właśnie tymi dwiema komendami - a restartowanie terminala niczego nie załatwia. Zabiera tylko sesję, do której możesz jeszcze chcieć wrócić.

A ile to wszystko kosztuje? Jedna komenda:

1/cost

/cost

pokazuje zużycie tokenów i koszt bieżącej sesji. To

/cost

i tylko

/cost

- ani

/save

, ani

/file

, ani

/context

nie pokażą Ci rachunku. Przydaje się szczególnie wtedy, gdy długi refaktor zaczyna się robić podejrzanie drogi: rzut oka na licznik zwykle wystarcza, żeby zdecydować, czy warto najpierw zrobić

/compact

, czy raczej zamknąć wątek i zacząć nowy przez

/clear

. Wyrób sobie nawyk zaglądania tam przed zejściem z pokładu - po kilku dniach sam zobaczysz, które przyzwyczajenia są tanie, a które kosztują Cię krocie.

Dyscyplina kontekstowa decyduje też o tym, jak podchodzisz do wielu plików naraz. Nie ma żadnej flagi

--glob

, która przemieliłaby cały katalog jednym poleceniem - i całe szczęście, bo taki wsad rozsadziłby kontekst po trzech plikach. Ale batch processing w Claude Code działa znakomicie, tylko sterujesz nim sam. Masz dwie sprawdzone drogi: pętla bash (

for

) wywołująca

claude -p

dla każdego pliku, albo podanie kilku plików przez

@

w jednym prompcie.

1# Plik po pliku - petla bash wywolujaca claude -p dla kazdego pliku
2for file in src/components/*.tsx; do
3  cat "$file" | claude -p "Dodaj komentarze JSDoc do tego komponentu"
4done
5
6# Albo kilka plikow naraz, podanych przez @ w jednym prompcie
7claude "Porownaj @src/api/users.ts i @src/api/orders.ts, ujednolic obsluge bledow"

Pętla daje każdemu plikowi własny, mały i czysty kontekst - i to jest dokładnie to, czego chcesz przy powtarzalnej robocie na całym katalogu, bo dziesiąty plik dostaje tyle samo uwagi co pierwszy. Jeden prompt z kilkoma odwołaniami

@

sprawdza się wtedy, gdy pliki trzeba zrozumieć razem: porównanie, wspólny refaktor, błąd rozłożony na dwa moduły. Ta sama sztuczka -

claude -p

wpięte w skrypt - stoi za zadaniami praktycznymi, które zaraz Cię czekają: generatorem commitów, fabryką komponentów i wyszukiwarką kodu rozumiejącą zwykłe zdania zamiast wyrażeń regularnych.

Podsumowanie

CLAUDE.md - pamięć projektu, wczytywana automatycznie; generujesz przez

/init

, edytujesz przez

/memory

Hierarchia - globalny

~/.claude/CLAUDE.md

, potem katalog główny projektu, potem podkatalogi Tryb planowania - Claude planuje przed edycją;

Shift+Tab

albo

--permission-mode plan

Tryby uprawnień - plan / default / acceptEdits / bypassPermissions settings.json - reguły allow/deny (np.

Bash(git*)

), zmienne środowiskowe, model Wiele plików - pętla

for

z

claude -p

albo odwołania

@

w jednym prompcie Kontekst -

/clear

,

/compact

, koszt przez

/cost

W ostatnich dwóch ćwiczeniach poznasz subagentów, skille, MCP i hooki - czyli to, co w Claude Code naprawdę nowe!

Do zobaczenia!