Najlepszy setup Claude Code na 2026 (przewodnik 30 min)

Każdy setup Claude Code, jaki widziałem, wpada w jeden z dwóch trybów awarii. Pierwszy to goły domyślny stan: brak CLAUDE.md, brak skilli, prośby o zgodę przy każdej komendzie, a użytkownik zastanawia się, czemu Claude ciągle zapomina, jak buduje się jego projekt. Drugi to przekombinowana maszyna: 40 skilli, 9 serwerów MCP, CLAUDE.md długości pracy zaliczeniowej i okno kontekstu zużyte w połowie, zanim padnie pierwszy prompt.

Dobry setup leży gdzieś pomiędzy i zbudowanie go zajmuje około 30 minut, jeśli warstwy robisz w kolejności zależności. Ta kolejność ma znaczenie. Skille zakładają działającą instalację. Decyzje o uprawnieniach zależą od tego, jakie serwery MCP odpalasz. Podział na per-projekt ma sens dopiero, gdy wiesz, co właściwie dzielisz. To przewodnik, który dajemy nowym osobom w SkillProof pierwszego dnia, po usunięciu błędów, które sami popełniliśmy przez pół roku.

Warstwa 1: instalacja i logowanie, pięć minut

To pewnie już masz za sobą, więc krótko.

npm install -g @anthropic-ai/claude-code
cd your-project
claude

Przy pierwszym uruchomieniu /login przeprowadzi Cię przez logowanie. Masz dwie ścieżki rozliczeń: subskrypcję Claude (Pro albo Max) albo klucz API z płatnością za token. Jeśli kodujesz z Claude codziennie, subskrypcja niemal zawsze wychodzi taniej; rozliczenie API przy intensywnych sesjach agentowych rośnie szybciej, niż się wydaje. Jeśli pracujesz w zespole, sprawdź, czy firma ma miejsce Claude for Work, zanim spalisz prywatny klucz API.

Zweryfikuj to czymś banalnym ("co robi to repo?") i upewnij się, że Claude czyta Twoje pliki. To cała ta warstwa. Wszystko poniżej to miejsce, gdzie setupy naprawdę zaczynają się różnić.

Warstwa 2: CLAUDE.md, który zarabia na swoje tokeny

CLAUDE.md to plik markdown, który Claude wczytuje do kontekstu na starcie każdej sesji w danym projekcie. Każdej sesji, niezależnie od tego, czy treść jest akurat istotna. To zachowanie przy wczytywaniu dyktuje wszystko, co powinno się w nim znaleźć.

Co się nadaje: fakty istotne w niemal każdej sesji. Komendy do builda i testów. Architektura w dwóch zdaniach. Konwencje, które Claude ciągle łamie, jeśli mu o nich nie powiesz (kolejność importów, format commitów). Miejsca, gdzie leżą trupy: przestarzały moduł, którego nikt nie powinien ruszać, plik konfiguracyjny, który wygląda na nieużywany, a nie jest.

Co się nie nadaje: wiedza proceduralna potrzebna od czasu do czasu. Jak napisać migrację bazy danych. Twoja checklista wydania. Styl korporacyjny e-maili do klientów. Każda z tych rzeczy dotyczy może 5% sesji, a w CLAUDE.md płacisz za nie w pozostałych 95% też. Taki materiał chce być skillem (kolejna warstwa), który wczytuje się tylko, gdy zostanie wywołany.

Nasza zasada po testach na własnym repo: jeśli Twój CLAUDE.md przekracza 60 linijek, coś powinno z niego wylecieć. Nasz zaczynał od 400 linijek, bo traktowaliśmy go jak dokumentację. Claude stosował się do niego gorzej, nie lepiej, bo sygnał się topił. Skompresowana wersja, około 50 linijek komend i twardych ograniczeń, jest przestrzegana niemal zawsze.

Napisz pierwszą wersję w dziesięć minut i przestań. Będziesz ją dopracowywać przez tygodnie, łapiąc Claude na powtarzanych błędach; ta iteracyjna pętla to właściwa metoda. Pełne omówienie, razem z antywzorcami, które widzimy w plikach przysyłanych przez czytelników, jest w naszym przewodniku po CLAUDE.md.

Warstwa 3: skille, warstwa, którą najczęściej się pomija

To warstwa, która odróżnia setup od zwykłej instalacji, i ta, której najczęściej nikt nie dotyka. Skill to folder z plikiem SKILL.md, który uczy Claude sposobu pracy. Kosztuje około 100 tokenów metadanych w spoczynku i wczytuje pełne instrukcje tylko wtedy, gdy zadanie pasuje do jego opisu. Zainstalowany raz, działa zawsze, w każdej sesji.

Ludzie pomijają tę warstwę z racjonalnego powodu: około połowa skilli społecznościowych na GitHubie nie działa od razu. Wiemy, bo instalowanie i testowanie ich to nasz cały biznes. Każdy skill w katalogu SkillProof przechodzi instalację na czystej maszynie i sprawdzenie triggerów, potem realne zadania na tle baseline'u bez skilla, zanim dostanie werdykt. Z 73 przetestowanych dotąd skilli, 35 przeszło.

Dla setupu developerskiego to pięć skilli do zainstalowania jako pierwsze, z wynikami z naszych testów:

1. Test-Driven Development, 9.6. Wymusza ścisły cykl red-green-refactor: najpierw test, który nie przechodzi, potem minimalna implementacja, na końcu porządki. W naszej sesji z trzema funkcjami ani razu nie pominął cyklu, nawet gdy próbowaliśmy go do tego namówić.
2. Systematic Debugging, 9.6. Zamienia naprawianie metodą zgadywania na pętlę hipoteza-test-weryfikacja. Znalazł źródłową przyczynę race condition, którą Claude wcześniej "naprawiał" trzy razy metodą zgadywania.
3. Frontend Design, 9.6. Największa różnica przed/po, jaką zmierzyliśmy dla jakiegokolwiek skilla. Ten sam brief na landing page, uruchomiony dwa razy: baseline dał neonowy gradient i wszystko wyśrodkowane, wersja ze skillem miała prawdziwą skalę typograficzną i paletę, która wyglądała na przemyślaną.
4. Memory Management, 9.2. Daje Claude trwałą pamięć między sesjami. W tygodniu testów niezawodnie przypominał sobie decyzje i preferencje projektu, a trafność przypominania nie spadała wraz ze wzrostem zbioru.
5. Webapp Testing, 8.8. Claude prowadzi Twoją aplikację w prawdziwej przeglądarce przez Playwright i zgłasza, co się psuje. Złapał regresję, którą przegapiły nasze testy jednostkowe.

Pierwsze dwa pochodzą z kolekcji Superpowers Jesse'ego Vincenta (/plugin marketplace add obra/superpowers-marketplace, potem /plugin install superpowers). Frontend Design jest częścią oficjalnego repo skilli Anthropic i kopiuje się prosto do ~/.claude/skills/. Dokładne kroki, razem z pułapkami, które zjadają pierwszą godzinę, są w przewodniku instalacji. Po instalacji zrestartuj Claude Code i przetestuj każdy trigger, prosząc o daną pracę bez wymieniania nazwy skilla. Jeśli nic się widocznie nie zmienia, skill się nie uruchamia, a zainstalowany skill, który nigdy się nie odpala, to po prostu folder.

Jeśli Twoja praca idzie w innym kierunku, nasza lista najlepszych skilli do kodowania rankinguje całą kategorię, aktualizowana wraz z nowymi testami.

Warstwa 4: serwery MCP, tylko te, których naprawdę użyjesz

Serwery MCP łączą Claude z rzeczami poza repo: Twoją bazą danych, systemem ticketów, żywą przeglądarką. Są potężne i są najdroższą pozycją w Twoim budżecie kontekstu. Każdy podłączony serwer wstrzykuje definicje swoich narzędzi do każdej sesji, użyte czy nie, a jeden gadatliwy serwer potrafi kosztować więcej stałych tokenów niż 50 zainstalowanych skilli razem wziętych. Zmierzyliśmy to w przewodniku o kosztach tokenów, a te liczby zmieniły to, jak konfigurujemy własne maszyny.

Poprzeczka dla serwera MCP powinna więc być wysoko: zasługuje na miejsce tylko, jeśli Claude musi dosięgnąć czegoś, do czego inaczej nie ma dostępu. Trzy zwykle przechodzą ten test dla developerów:

Serwer bazy danych (Postgres albo cokolwiek u Ciebie działa). Claude piszący zapytania na Twoim prawdziwym schemacie zamiast zgadywanym to zupełnie inny produkt. To pojedyncze połączenie MCP o najwyższej wartości dla większości zespołów.

Automatyzacja przeglądarki (Playwright MCP), jeśli wypuszczasz UI i nie korzystasz z własnego setupu skilla Webapp Testing. Zobaczenie wyrenderowanej strony zawsze bije wnioskowanie z JSX.

Twój system ticketów, ale tylko jeśli faktycznie pracujesz ticket po tickecie wewnątrz Claude Code. Jeśli zerkasz do Linear dwa razy dziennie, przeglądarka wystarczy, a tokeny się nie opłacają.

Zauważ, czego brakuje: serwera MCP dla GitHuba. CLI gh robi wszystko to samo, Claude już wie, jak go używać, i kosztuje zero stałego kontekstu. Ten wzorzec zastępowania się uogólnia. Zanim dodasz jakikolwiek serwer, zapytaj, czy narzędzie CLI, które Claude może wywołać, da Ci ten sam zasięg za darmo. A jeśli zastanawiasz się, czy problem w ogóle potrzebuje MCP, czy tylko skilla, reguła decyzyjna jest w skille vs MCP: skille zmieniają, co Claude potrafi zrobić, MCP zmienia, czego może dotknąć.

Warstwa 5: uprawnienia i ustawienia bezpieczeństwa warte zmiany

Domyślne doświadczenie uprawnień to prośba o zgodę przy niemal każdej komendzie, co uczy ludzi klikać "zezwól" odruchowo. To najgorszy możliwy wynik: całe tarcie, zero bezpieczeństwa. Dwie zmiany to naprawiają.

Po pierwsze, dodaj do allowlisty komendy, które i tak byś zatwierdził. W .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Po drugie, zwróć uwagę na blok deny, bo to ta połowa, którą ludzie pomijają. Claude nie ma czego szukać w Twoim .env, a reguła deny sprawia, że to cecha systemu, a nie nadzieja. Jeśli odpalasz skille albo serwery MCP od stron trzecich, ma to jeszcze większe znaczenie, bo złośliwa instrukcja nie wyciągnie tego, czego harness nie odczyta. Nasz przewodnik po bezpieczeństwie pokrywa stronę audytu.

Co do --dangerously-skip-permissions: nazwa flagi jest szczera. Wewnątrz jednorazowego kontenera bez żadnych poświadczeń to niezły sposób na odpalanie długich, bezobsługowych zadań. Na Twoim laptopie, z Twoimi kluczami SSH i zalogowanymi sesjami przeglądarki, to sposób na to, by wystąpić w postmortemie. Używamy tego w sandboksach CI i nigdzie indziej.

Per-projekt vs globalnie: gdzie leży każdy element

Wszystko powyżej istnieje na dwóch poziomach, a pomieszanie ich to najczęstszy bałagan konfiguracyjny, jaki widzimy. Podział:

Element	Globalnie (~/.claude/)	Per-projekt (.claude/ w repo)
CLAUDE.md	Twój osobisty styl: długość odpowiedzi, języki, drobne przyzwyczajenia	Komendy builda, architektura, konwencje projektu (commituj to)
Skille	Wszystko ogólne: debugowanie, TDD, pisanie	Tylko workflow specyficzne dla zespołu
Ustawienia	Twoja osobista allowlista	Allowlista zespołu i reguły deny (commituj to)
settings.local.json	—	Twoje nadpisania tylko na tej maszynie (dodaj do gitignore)
Serwery MCP	Serwery, których używasz wszędzie	.mcp.json projektu, żeby zespół miał te same połączenia

Zasada: wszystko, czego potrzebowałby ktoś z zespołu, idzie do repo, wszystko, co dotyczy Ciebie osobiście, idzie globalnie. Wypłata przychodzi, gdy ktoś nowy klonuje projekt, a Claude od razu zna komendy builda i konwencje, z gotowym połączeniem do bazy danych. Ich warstwa 2 i połowa warstwy 4 są za darmo.

Mój setup po sześciu miesiącach

Co naprawdę przetrwało na mojej maszynie, dla kalibracji: 54-liniowy projektowy CLAUDE.md, dziewięć skilli, dwa serwery MCP (Postgres i Playwright) i powyższy blok uprawnień. Sesje setupu wyglądają identycznie jak sześć miesięcy temu; różnica to wszystko, co usunąłem.

Usunięcia nauczyły mnie więcej niż dodatki:

Usunąłem serwer MCP dla GitHuba. Trzymałem go cztery miesiące z bezwładności. Definicje jego narzędzi kosztowały tysiące stałych tokenów na sesję, a gh robił tę samą robotę. Nic się nie pogorszyło. To jedno usunięcie zwróciło mi czas na napisanie tego artykułu.

Usunąłem serwer pamięci MCP na rzecz skilla Memory Management. Serwer był kolejnym procesem do pilnowania i kolejnym logowaniem do utrzymania. Skill robi tę robotę w zwykłych plikach, które mogę sam czytać i edytować. Gdy pamięć się psuje, otwieram markdown i naprawiam, czego nigdy nie mogłem zrobić z nieprzejrzystym magazynem.

Skróciłem CLAUDE.md z 400 do 54 linijek. Długa wersja czytała się jak dobra dokumentacja, a działała jak szum. Przestrzeganie zasad, które miały znaczenie, wzrosło, gdy usunąłem te, które go nie miały. Teraz traktuję każdą linijkę jak czynsz.

Odinstalowałem 19 z 28 skilli. Większość to były instalacje "może się przyda", które nigdy nie odpaliły w realnej pracy. Leniwe ładowanie sprawia, że kosztują mało, ale nakładające się opisy powodowały dwa realne konflikty triggerów, a audyt, który je znalazł, był żmudny. Dziewięć skilli, które odpalają co tydzień, bije 28, które przeważnie nie.

Wycofałem ogólną regułę Bash(*) allow. Dodałem ją w tygodniu przed deadline'em, trzymałem za długo. Dnia, w którym Claude z pełnym przekonaniem uruchomił destrukcyjną migrację na bazie deweloperskiej, która okazała się mniej jednorazowa, niż była oznaczona, przywróciłem prośby o zgodę dla wszystkiego, co zapisuje.

Wzorzec we wszystkich pięciu: ani razu nie pożałowałem usunięcia. Regularnie żałowałem dodatków.

Częste błędy pierwszego tygodnia

Pięć rzeczy, które robi prawie każdy w pierwszym tygodniu, więc możesz je sobie odpuścić:

1. Pisanie 500-liniowego CLAUDE.md pierwszego dnia. Jeszcze nie wiesz, co Claude robi źle w Twoim repo. Zacznij od 15 linijek i rozwijaj go na podstawie zaobserwowanych błędów.
2. Instalowanie każdego ciekawego serwera MCP. Każdy obciąża każdą sesję. Zacznij od zera i dodawaj jeden, gdy trafisz na ścianę, którą rozwiązuje.
3. Odpalanie --dangerously-skip-permissions na głównej maszynie, bo prośby o zgodę irytowały. Zamiast tego dodaj bezpieczne komendy do allowlisty; to zabija 90% próśb bez ryzyka.
4. Instalowanie skilli i nigdy niesprawdzanie, czy się odpalają. Połowa wartości skilla umiera w niejasnym polu opisu. Przetestuj każdy naturalną prośbą, bez wymieniania nazwy skilla.
5. Trzymanie configu poza repo. Jeśli Twój projektowy CLAUDE.md i settings.json nie są zacommitowane, każdy z zespołu odbudowuje Twój setup z pamięci, i robi to źle.

Utrzymanie: co przejrzeć po każdym wydaniu Claude

Setup dostrojony do jednej wersji modelu dryfuje przy kolejnej. Po każdym istotnym wydaniu Claude poświęć 20 minut na cztery sprawdzenia.

Przeczytaj ponownie swój CLAUDE.md i usuń zasady, których nowy model już nie potrzebuje. Aktualizacje modelu regularnie unieważniają instrukcje; reguła "zawsze uruchamiaj linter", którą napisałeś rok temu, może teraz być domyślnym zachowaniem, za którego powtarzanie płacisz tokenami.

Przetestuj ponownie triggery swoich skilli. Dopasowanie triggera to zachowanie modelu, nie dopasowanie słów kluczowych, więc opis, który odpalał się niezawodnie na jednym modelu, może ucichnąć na kolejnym. Nasz katalog retestuje najlepsze skille po dużych wydaniach, a strony poszczególnych skilli noszą aktualny werdykt.

Zmierz ponownie narzut kontekstu. Nowe wydania czasem zmieniają sposób liczenia albo cache'owania definicji narzędzi MCP. Narzędzia z naszej listy skilli efektywnościowych to miejsce, do którego kierujemy ludzi chcących sprawdzić, co naprawdę zjada im budżet; kilka skilli w tej kategorii istnieje właśnie dla tego przeglądu.

I sprawdź changelog pod kątem zmian w modelu uprawnień, zanim ustawienia zespołu po cichu zaczną znaczyć coś innego. To zajmuje pięć minut i uratowało nas dwukrotnie.

FAQ

Czy 30 minut to realistyczny czas, uczciwie?

Dla warstw od 1 do 5 tak, jak są opisane, tak, mierzyliśmy to z nowymi osobami w zespole. Co zajmuje dłużej, to dostrajanie: Twój CLAUDE.md osiąga stabilną formę po dwóch-trzech tygodniach łapania powtarzających się błędów Claude. Zaplanuj 30 minut na budowę i kilka minut dziennie na dopracowanie przez pierwsze dwa tygodnie.

Czy w ogóle potrzebuję serwerów MCP?

Sporo dobrych setupów działa z zerem. Jeśli Twoja praca żyje w repo (kod, testy, dokumentacja), skille plus narzędzia CLI to pokrywają. MCP zarabia na siebie, gdy Claude potrzebuje żywego dostępu do czegoś zewnętrznego, a baza danych to najczęstszy prawdziwy przypadek. W razie wątpliwości zacznij bez i dodaj serwer, gdy pierwszy raz poczujesz ścianę.

Czy CLAUDE.md powinien być globalny czy per-projekt?

Oba, trzymające różne rzeczy. Globalny (~/.claude/CLAUDE.md) niesie Twoje osobiste preferencje i działa wszędzie. Per-projekt niesie komendy builda i konwencje, i należy do gita, żeby cały zespół je dzielił. Błąd to wsadzanie faktów o projekcie do pliku globalnego, gdzie zanieczyszczają sesje wszystkich innych projektów.

Ile skilli to za dużo?

Pod względem tokenów sufit jest wysoko: nawet 50 skilli kosztuje tylko kilka tysięcy tokenów stałych metadanych. Praktyczny sufit jest niższy, bo skille z nakładającymi się opisami zaczynają konkurować o te same triggery. My mamy dziewięć. Powyżej 15 czy tak powinieneś raczej przycinać to, co nie odpaliło się od miesiąca, niż dodawać kolejne.

Czy mogę pominąć warstwę uprawnień, jeśli pracuję w sandboksie?

Jeśli sandbox jest naprawdę jednorazowy, bez poświadczeń, bez zamontowanych wolumenów, na których Ci zależy, to tak, i --dangerously-skip-permissions istnieje dokładnie po to. Ta warstwa ma znaczenie na maszynach z prawdziwymi sekretami. Czyjś "sandbox" to zwykle laptop z produkcyjnymi kluczami AWS w dotfile'u, co sandboksem nie jest.