Claude Code w praktyce — checklista · Zasób

To jest wersja do trzymania pod ręką przy otwartym terminalu. Każdy krok zaczyna się od czasownika i da się sprawdzić — zrób, potem zobacz, czy efekt jest taki, jak ma być. Idziesz po kolei: najpierw to, co nic nie psuje, a dalej nawyki, którymi posługują się osoby wyciskające z narzędzia najwięcej.

Zasada przewodnia jednym zdaniem: nie szukaj sekretnych zaklęć — daj narzędziu kontekst i sposób, żeby samo sprawdziło swoją pracę.

0. Zanim zaczniesz

Sprawdź, co masz pod ręką i czego się spodziewać, zanim wpiszesz pierwsze polecenie.

Pobierz i uruchom Claude Code — nie czekaj na żadną konfigurację ani indeksowanie. Sprawdź, że narzędzie odpowiada od razu po starcie.
Zostań w swoim dotychczasowym edytorze kodu. Claude Code mieszka w terminalu i współpracuje z tym, co już masz — nie przesiadaj się na nowe narzędzie.
Przyjmij do wiadomości, że wita cię pusta linia. To celowy wybór, nie usterka — narzędzie nie wpycha cię w jeden gotowy sposób pracy.
Upewnij się, że rozumiesz, czym ono jest: agentowym asystentem, który dostaje cel i sam dobiera kroki. Nie podpowiada jednej linijki — potrafi napisać całą funkcję, cały plik, naprawić cały błąd.
Zapamiętaj dwie rzeczy, które uspokajają: kod nie wysyła się na żaden serwer, zostaje na twoim komputerze, a żadnego „przetrawiania” projektu na starcie nie ma.

1. Zacznij od pytań o swój projekt

Zanim cokolwiek zmienisz, najpierw pytaj. To jedyna rada, którą stawia się ponad wszystkimi.

Nie rzucaj narzędziu wielkiego zadania na dzień dobry — to częsty błąd, który kończy się rozczarowaniem. Zacznij od rozmowy.
Zadaj pytanie o konkretny fragment kodu: „jak ten fragment jest używany?”, „dlaczego to działa akurat tak?”, „co właściwie wdrożyłem w tym tygodniu?”. Sprawdź, że dostajesz odpowiedź na poziomie dobrej dokumentacji, a nie listy trafień.
Poproś o historię projektu: „przejrzyj historię i wytłumacz mi, skąd się wzięła ta dziwna funkcja”. Nie tłumacz, jak to zrobić — narzędzie samo przekopie się przez repozytorium Git i streści ci całą historię.
Wyłap przy okazji granicę: zobacz, co narzędzie zrobi od ręki, a co wymaga, żebyś poprowadził je za rękę.

2. Edytuj kod — opisuj cel, nie kroki

Gdy poczujesz się pewnie z pytaniami, przejdź do zmieniania kodu. Działa ta sama logika.

Powiedz, co ma powstać — nie wskazuj kolejnych kroków. Narzędzie ma mały zestaw narzędzi (edycja plików, polecenia w terminalu, przeszukiwanie projektu) i samo łączy je w odpowiedniej kolejności.
Nie pisz „użyj teraz tego, a potem tamtego”. Opisz cel; decyzję o kolejności (najpierw przeszukać, potem przeczytać, potem zmienić) zostaw narzędziu.

3. Przy każdym nietrywialnym zadaniu poproś o plan

To nawyk, który daje najwięcej przy najmniejszym wysiłku. Poproś o plan, zanim narzędzie zacznie pisać.

Napisz wprost: „przemyśl pomysły, ułóż plan, pokaż mi go i poczekaj na moją zgodę, zanim napiszesz kod”.
Nie szukaj żadnego specjalnego trybu ani ustawień — po prostu o to poproś, a narzędzie wie, co zrobić.
Przeczytaj plan i zatwierdź go, zanim ruszy dalej. Pięć minut na zatwierdzenie planu oszczędza godzinę poprawiania czegoś, co poszło nie tam.

4. Daj narzędziu sposób, by sprawdziło własną pracę

Jeśli masz zapamiętać jedną rzecz, niech to będzie ta: gdy narzędzie ma jak sprawdzić swoją robotę, samo doprowadza ją do znacznie lepszego stanu.

Daj mu sposób, żeby zobaczył efekt: zrzut ekranu gotowej strony, zestaw automatycznych testów albo podgląd — cokolwiek pozwala samodzielnie ocenić, czy zrobił dobrze.
Pozwól mu dostroić wynik. Sprawdź, że po dwóch–trzech podejściach efekt trafia niemal idealnie — narzędzie porówna wynik z celem, samo poprawi i sprawdzi jeszcze raz.
Trzymaj się tej samej sztuczki w każdej dziedzinie: daj jakikolwiek sposób, żeby narzędzie zobaczyło efekt swojej pracy. To jest pętla sprzężenia zwrotnego.

5. Podaj kontekst — od najprostszego

Im więcej narzędzie wie o projekcie, tym lepsze decyzje podejmuje. Twojego kontekstu nie zgadnie — trzeba mu go podać. Zacznij od najprostszego sposobu.

Załóż plik CLAUDE.md — krótkie notatki, które narzędzie czyta automatycznie na początku każdej rozmowy. Wpisz to, co przekazałbyś komuś nowemu w projekcie: najczęstsze polecenia, kilka kluczowych plików, ważne ustalenia.
Trzymaj ten plik krótko. Jeśli rozrośnie się za bardzo, zacznie zajmować miejsce i przestanie pomagać.
Zdecyduj, czy współdzielisz go z zespołem (piszesz raz, korzystają wszyscy), czy trzymasz prywatną, lokalną wersję tylko dla siebie.
Zapisz powtarzalne czynności jako komendy ukośnikowe (wywoływane znakiem /). Jeśli coś powtarzasz co tydzień, zapisz raz, używaj jednym poleceniem. Te też da się współdzielić z zespołem.
Podłącz narzędzia, których już używacie — własne programy z terminala albo system MCP (wspólny standard, dzięki któremu Claude Code rozmawia z zewnętrznymi narzędziami: systemem zgłoszeń, bazą, czymkolwiek). Powiedz mu o nich i pokaż, jak ich użyć; np. „użyj tego programu, sprawdź sam jego instrukcję”.
Na większą skalę rozłóż kontekst i reguły warstwami: osobno dla projektu (w repozytorium, współdzielone), osobno globalnie dla wszystkich twoich projektów, osobno na poziomie całej firmy.
Na warstwie firmowej z góry zatwierdź bezpieczne polecenia (żeby nikt nie klikał ich za każdym razem) i zablokuj niebezpieczne tak, żeby nikt ich nie obszedł.
Jeśli nie wiesz, od czego zacząć, zacznij od współdzielonego kontekstu projektu. Piszesz raz, dzielisz się z całym zespołem — jedna osoba wykonuje trochę pracy, a korzystają wszyscy.

6. Dołóż przydatne ruchy i pracę równoległą

Garść drobiazgów na codzienne używanie — sięgaj po nie, gdy poczujesz się swobodnie.

Włącz tryb automatycznej akceptacji zmian, gdy widzisz, że narzędzie jest na dobrej drodze (np. poprawia testy w kółko). Polecenia w terminalu nadal wymagają twojej zgody, a wszystko da się cofnąć.
Użyj znaku #, żeby coś zapamiętać. Jeśli narzędzie czegoś nie robi po twojemu, wpisz # i powiedz, o co chodzi — dopisze to sobie do notatek na przyszłość.
Naciśnij Escape, żeby bezpiecznie przerwać w dowolnym momencie. Nic się nie zepsuje, sesja nie ucierpi — przerywasz, mówisz, co zmienić, ruszacie dalej.
Wznów sesję później, zamiast zaczynać od zera. Wróć do tej samej rozmowy i kontynuuj.
Gdy nabierzesz wprawy, rozważ kilka sesji naraz — osobne kopie projektu albo robocze odgałęzienia Gita, żeby każda sesja pracowała w izolacji. To nie jest punkt obowiązkowy, raczej kierunek do wyboru.
Zapamiętaj, że Claude Code da się prowadzić także ze skryptów — podajesz polecenie, narzędzie oddaje gotowy wynik, a ty wpinasz go w większy automatyczny przepływ. Nie ruszaj tego na start, ale wiedz, że ta droga istnieje.

Na co uważać

Pułapki, które najczęściej psują pierwsze podejście.

Wielkie zadanie na dzień dobry. Rzucanie ogromnego polecenia bez planu czasem wychodzi, a czasem powstaje coś zupełnie innego, niż się chciało — i zaczyna się frustracja. Najpierw pytania, potem plan.
Pomijanie planu przy nietrywialnym zadaniu. Pięć minut na zatwierdzenie planu oszczędza godzinę poprawiania. Nie pozwól narzędziu pisać, zanim pokaże ci, co zamierza.
Brak sposobu na samokontrolę. Bez zrzutu ekranu, testu czy podglądu narzędzie nie ma jak ocenić własnej pracy i zatrzymuje się na „nieźle” zamiast dojść do „niemal idealnie”.
Za długi plik CLAUDE.md. Gdy notatki rozrosną się za bardzo, zaczynają zajmować miejsce i przestają pomagać. Trzymaj go krótko.
Próba zgadywania twojego kontekstu. Historii, ustaleń i powodów „dlaczego tu robimy tak” narzędzie nie zgadnie — trzeba mu je podać.

Najmniejszy ruch na dziś: otwórz swój projekt i zadaj jedno pytanie o coś, czego nigdy do końca nie rozumiałeś. To wystarczy, żeby zacząć.