CLAUDE.md i Tryb Planowania (Plan Mode)

Dotarliśmy do prawdziwych skarbów! 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 ani /file, bo takich komend w Claude Code po prostu nie ma, i nie /context, które tylko pokazuje zajęty kontekst.

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. Pliki się nie wykluczają: Claude dokleja wszystkie do kontekstu, od najbardziej ogólnego do najbliższego, a plik z podkatalogu wczytuje dopiero wtedy, gdy zacznie czytać pliki z tego podkatalogu. Gdy dwa pliki sobie przeczą, Claude może posłuchać dowolnego z nich, więc pilnuj, żeby poziomy się nie gryzły. 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# Mój 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 plików, 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?

Trzy 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. Komendą /plan wpisaną przed poleceniem, np. /plan przebuduj autoryzację
3. 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 spośród flag tylko ona uruchomi sesję od razu 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 (w interfejsie: Manual) - bez pytania tylko czyta, o edycje i komendy pyta
• plan - bada i planuje, nie edytuje kodu, dopóki nie zatwierdzisz planu
• acceptEdits - automatycznie akceptuje edycje plików przez Claude
• auto - akcje ocenia drugi model (klasyfikator) zamiast Ciebie; w nowych wersjach to w nim startuje sesja w terminalu
• dontAsk - poza odczytem odrzuca wszystko, czego nie dopuściłeś regułami (przydaje się w CI)
• bypassPermissions - pomija pytania o uprawnienia (tylko w kontenerze albo maszynie wirtualnej!)

Cztery podstawowe tryby ustaw 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. Włącz 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 kolejności
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.local.json - Twoje prywatne ustawienia dla tego projektu (poza Gitem)
• ~/.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. Tak wygląda zawartość pliku .claude/settings.json (to czysty JSON, więc nie dopisuj w nim komentarzy):

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

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. Spacja przed gwiazdką ma znaczenie: git * pasuje do git status i git log, ale już nie do gitk. Efekt jest natychmiastowy: polecenia git wykonują się bez pytania i przestajesz klikać "tak" dwadzieścia razy dziennie, a reguła deny blokuje rm -rf w każdym trybie - pamiętaj tylko, że pasuje do zapisu dosłownie, więc rm -fr to dla niej już inny tekst. 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# Wyczyść kontekst i zacznij od czystej karty
2/clear
3
4# Streść dotychczasową rozmowę i kontynuuj (zachowuje sedno, oszczędza 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. Do tego /context pokazuje, ile kontekstu zajmuje rozmowa, ale niczego nie czyści (komend /context show i /context clear nie ma). Kontekstem jak najbardziej da się zarządzać - właśnie przez /clear i /compact - 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/usage

/usage (albo /cost, które jest dziś jego aliasem) pokazuje koszt bieżącej sesji, a na planach Pro, Max, Team i Enterprise także zużycie limitów planu. Rachunku nie pokażą Ci ani /save, ani /file (tych komend nie ma), ani /context, które liczy tylko zajęty kontekst. /usage 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 - pętla bash wywołująca claude -p dla każdego pliku
2for file in src/components/*.tsx; do
3  claude -p "Dodaj komentarze JSDoc do komponentu @$file" --permission-mode acceptEdits
4done
5
6# Albo kilka plików naraz, podanych przez @ w jednym prompcie
7claude "Porównaj @src/api/users.ts i @src/api/orders.ts, ujednolić obsługę błędów"

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.

Dwa z tych skryptów przyjmują argumenty z linii poleceń. Gdy uruchamiasz ./generate-component.sh Button, słowo Button trafia do zmiennej $1, a wszystkie słowa wpisane po nazwie skryptu trafiają razem do "$*". Taką zmienną wstawiasz po prostu w treść polecenia dla Claude:

1NAME=$1
2claude -p "Utwórz komponent React $NAME w TypeScript i zapisz go w src/components/$NAME.tsx,
3  testy w src/components/$NAME.test.tsx oraz stories w src/components/$NAME.stories.tsx" \
4  --permission-mode acceptEdits

Plik .stories.tsx opisuje warianty komponentu dla Storybooka, narzędzia, które pokazuje komponenty w izolacji. Tak samo zbudujesz wyszukiwarkę: claude -p "Znajdź w projekcie kod, który dotyczy: $*" przekaże Claude całe zdanie wpisane po nazwie skryptu, a Claude sam przeszuka pliki, bo w trybie -p czytać może bez pytania.

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, /plan albo --permission-mode plan Tryby uprawnień - plan / default / acceptEdits / auto / dontAsk / 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, podgląd przez /context, koszt przez /usage

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

Do zobaczenia!

1#!/bin/bash
2# CLAUDE.md - pamięć projektu w Claude Code
3
4# Najprostszy sposób: niech Claude wygeneruje CLAUDE.md za Ciebie.
5# Wewnątrz sesji 'claude' wpisz komendę:
6#   /init
7
8# Claude przeanalizuje projekt i utworzy gotowy CLAUDE.md.
9# Możesz go potem edytować ręcznie albo komendą /memory.
10
11# Hierarchia plików CLAUDE.md (od najogólniejszego):
12#   ~/.claude/CLAUDE.md         - globalny, dla wszystkich projektów
13#   CLAUDE.md                   - w katalogu głównym projektu
14#   src/.../CLAUDE.md           - zagnieżdżony, dla części projektu
15
16# Claude wczytuje CLAUDE.md AUTOMATYCZNIE na początku każdej sesji,
17# więc od razu zna Twoje konwencje, architekturę i komendy.
18# Pliki się nie nadpisują: wszystkie trafiają do kontekstu, a plik
19# z podkatalogu wczytuje się, gdy Claude pracuje w tym podkatalogu.
20
21echo "Wpisz /init w sesji claude, aby wygenerować CLAUDE.md"