O czym jest ten film
- Twórca Claude Code, Boris Cherny, w ciągu dziewięciu miesięcy przeszedł od „większość sesji zaczynam w plan mode” do „plan mode nie jest już przydatny” — rady sprzed roku są nieaktualne.
- Plan mode nigdy nie zmieniał możliwości modelu: doklejał do promptu przypomnienie „jeszcze nie koduj”, co ratowało sytuację ze starszymi modelami, rzucającymi się od razu na robotę.
- Nowy schemat pracy to krótki brief z trzech elementów — zadanie, granice i definicja „gotowe” — a kontrola przenosi się na koniec: sprawdzasz wynik, nie plan.
- Przy większych zmianach najlepsi proszą o diagram albo interaktywne demo wykonanej pracy; Anthropic dodało właśnie wbudowane dashboardy i animowane omówienia.
- Magiczne frazy typu „think hard” czy „ultra think” są dziś czytane jak zwykłe słowa; sterowanie intensywnością myślenia przeszło do ustawienia „effort”, którego lepiej nie ruszać.
- Najbardziej aktualna rada sprzed stycznia: daj Claude’owi test weryfikujący pracę — podnosi to jakość wyniku dwu-, trzykrotnie. Test, a nie prośba o „jeszcze raz sprawdź”, która tylko podnosi koszt.
- Komenda /goal automatyzuje pętlę poprawek, ale mały model-sędzia nie uruchamia poleceń ani nie czyta plików — cel musi być precyzyjny i mieć limit tur.
- CLAUDE.md ma być spisem treści warsztatu (poniżej 200 linii): cztery kategorie informacji, a cała reszta to ścieżki do plików otwieranych dopiero wtedy, gdy są potrzebne.
- Skille buduje się dziś na opak: najpierw zadanie bez skilla i lista realnych błędów. W teście 450 przebiegów siedem z dziewięciu popularnych paczek nie wypadło lepiej niż plik-atrapa.
- Gwarancje dają hooki (deterministyczne skrypty) zamiast zakazów wielkimi literami, skład zespołu podagentów model dobiera sam (ty ustawiasz limit), a nowe „projects” uruchamiają pracę zdarzeniowo — nawet przy wyłączonym komputerze.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Koniec z planowaniem z góry — pisz krótki brief i oceniaj wynik
Na czym polega: Boris Cherny, twórca Claude Code, w styczniu zalecał zaczynanie od plan mode, a we wrześniu przyznał na Hacker News, że tryb już nie jest potrzebny. Plan mode nigdy nie zmieniał możliwości modelu — doklejał tylko przypomnienie „jeszcze nie koduj”. Starsze modele (Sonnet 4.6, wczesny Opus) rzucały się na pracę bez przygotowania; nowe planują w trakcie wykonywania zadania.
Jak stosować: opisz w trzech liniach zadanie (np. raport tygodniowy z eksportu CRM), granice (nie zmieniaj szablonu, nie wysyłaj maili) i definicję „gotowe” (każda liczba zgadza się z eksportem). Nie czytasz planu przed startem — sprawdzasz efekt po zakończeniu.
Na co uważać: nie przenoś starego nawyku rozpisywania każdego kroku. Brief mówi, co zrobić i czego nie wolno — nie mówi, jak model ma myśleć.
2.Po zakończonej pracy żądaj jednostronicowego omówienia
Na czym polega: przy większych zmianach najlepsi użytkownicy proszą Claude’a o diagram lub interaktywne demo tego, co zostało zrobione. Anthropic właśnie dodało wbudowaną możliwość tworzenia żywych dashboardów i animowanych omówień, więc taki materiał dostaje się łatwiej niż kiedykolwiek.
Jak stosować: gdy zadanie się kończy, poproś o jednostronicową wizualizację dwóch rzeczy: co zostało zrobione i co przy okazji założono. Ty piszesz wyłącznie brief; wraca do ciebie wynik plus omówienie.
Na co uważać: omówienie nie zastępuje testu — to materiał do szybkiego rozeznania, nie dowód poprawności.
3.Poziom wysiłku zostaw w spoczynku — „think hard” już nie działa
Na czym polega: zeszłoroczne frazy „think”, „think hard”, „ultra think” podbijały budżet rozumowania; dziś Claude Code czyta je jako zwykłe słowa w prompcie. Sterowanie przeszło do ustawienia poziomu wysiłku (effort), a każdy model ma wartość zalecaną — Opusowi 5.5 przypisano „medium”, na którym według Anthropic dorównuje lub prześciga Opusa 5 ustawionego na „high”.
Jak stosować: przy zdecydowanej większości zadań nie dotykaj tego ustawienia. Domyślna konfiguracja robi dziś to, co kiedyś robiłeś ręcznie — mniejszym kosztem i mniejszą liczbą kroków.
Na co uważać: nie doklejaj magicznych formuł do promptów — to martwy zwyczaj. Warto się przygotować, że suwak w ogóle zniknie, a dobór intensywności przejdzie do tła.
4.Definicję „gotowe” zamień na test zaliczenia — nie pisz „sprawdź się”
Na czym polega: według posta Borisa z stycznia danie Claude’owi sposobu weryfikacji własnej pracy podnosi jakość wyniku dwu-, trzykrotnie — to też pierwsza rada w dokumentacji Anthropic. Ale nie chodzi o dopisek „sprawdź jeszcze raz”: Opus 5 i tak weryfikuje własny wynik, a takie zdanie jedynie podnosi koszt. Chodzi o kryteria z werdyktem zdane/niezdane.
Jak stosować: wróć do linii „gotowe” z briefu i przerób ją na test. W przykładzie z raportem — mały skrypt check report, który porównuje każdą liczbę z eksportem i sprawdza, czy wszystkie sekcje szablonu są wypełnione. Gdy test się wysypie, Claude sam poprawia i odpala go ponownie; ty czytasz dowody. Test nie musi być kodem — posłuży też dokument tonu marki, wobec którego porównuje się szkic.
Na co uważać: im bardziej mechaniczny (deterministyczny) test, tym więcej błędów wyłapie. Mgliste kryteria model zaliczy sobie zbyt łaskawie.
5./goal zamyka pętlę poprawek — ale cel musi być bezdyskusyjny
Na czym polega: /goal wpisuje „kontynuuj” za ciebie: po każdej turze mały model (Haiku) ocenia, czy cel osiągnięty, a jeśli nie — Claude podejmuje kolejną próbę. Haczyk: ów sędzia nie uruchamia poleceń ani nie zagląda do plików; widzi wyłącznie rozmowę i wynik.
Jak stosować: dobry cel ma jeden stan końcowy, sposób jego udowodnienia, listę rzeczy, które nie mogą się zmienić, oraz limit tur. Przykład: „skrypt check report przechodzi i pokazujesz wynik; szablon bez zmian; stop po piętnastu turach”.
Na co uważać: mętny cel („raport jest skończony”) domknie pętlę przedwcześnie — model ogłosi sukces, zanim faktycznie go osiągnie. Bez limitu tur pętla może kręcić się bez końca.
6.CLAUDE.md traktuj jak spis treści warsztatu, nie podręcznik
Na czym polega: przy premierze Opusa 5 Anthropic usunęło ponad 80 procent własnych instrukcji Claude Code, bo większość łatała błędy starych modeli. Dokumentacja od dawna zaleca plik poniżej 200 linii — dłuższy więcej kosztuje i jest słabiej przestrzegany. W nowym ujęciu claude.md pełni rolę spisu treści, tak jak skill.md w folderze skilla.
Jak stosować: zostaw cztery kategorie: narzędzia i komendy, których model nie zgadnie; rzeczy robione inaczej niż standardowo; potknięcia powtarzające się więcej niż raz; granice typu „napisz tylko szkic maila”. Resztę zamień w odnośniki — pisane jako ścieżka z warunkiem otwarcia („przeczytaj brief klienta przed każdą pracą dla klienta”), a nie @-import, który ładuje cały plik do każdej sesji. Każdy plik wskaż bezpośrednio z claude.md, bo plik osiągalny tylko pośrednio jest podglądany wyłącznie w pierwszych stu liniach; plikom dłuższym niż sto linii dodaj u góry spis treści.
Na co uważać: przy przebudowie starego pliku każda nowa linia to kandydat do przeniesienia osobno. Porządki przyspieszy komenda /doctor prompt audit: wypatrzy instrukcje pisane pod stare modele, martwe ścieżki i wzajemnie sprzeczne pliki — i nic nie zmieni bez twojej zgody.
7.Skille buduj odwrotnie: najpierw zadanie bez skilla
Na czym polega: większość układa proces w głowie i od razu każe zbudować skilla — zanim Claude choć raz spróbuje zadania „z pudełka”. Poradnik Anthropic każe działać odwrotnie: najpierw wykonaj zadanie bez wsparcia, na prawdziwych materiałach, i spisz, gdzie model zszedł z toru. Skilla ma rozwiązywać realne problemy, nie dokumentować wyobrażone. Najlepsze skille zespołu Anthropic zaczynały się od kilku linii i jednej poprawki.
Jak stosować: uruchom proces na dobrym modelu bez żadnego skilla, notuj wyłącznie korekty, które doprowadziły do twojej definicji „gotowe”, i z nich złóż plik. Alternatywa: nagranie skilla w aplikacji desktopowej, która obserwuje twoją pracę — autor przetestował to na automacie wiadomości na Instagramie i wyszedł zaskakująco mały plik, bo utrwalał tylko to, czego model nie zrozumie sam.
Na co uważać: testuj na modelu, na którym będziesz faktycznie pracować — inne modele potrzebują mniej albo więcej instrukcji. I nie pisz podręcznika całego procesu: skilla to lista realnych potknięć.
8.Testuj skille na twardo — większość paczek to balast
Na czym polega: jeden z deweloperów przetestował pod koniec września dziewięć popularnych paczek skilli — 450 przebiegów na Opusie 5.5. Tylko dwie z dziewięciu wypadły lepiej niż plik-atrapa o tej samej długości; w siedmiu scenariuszach na dziewięć kontekst zapisany w środku nie poprawiał wyniku.
Jak stosować: użyj wbudowanego mechanizmu plugin eval — uruchamia to samo zadanie z twoim skillem i bez niego, a potem ocenia różnicę (narzędzie pomyślano o wtyczkach, ale da się je przerobić na pojedyncze skille). Zacznij od /skill doctor, który pokazuje koszt i częstotliwość użycia każdego skilla: nieużywane wyrzuć, resztę poddaj testowi.
Na co uważać: równe wyniki z testem i bez testu oznaczają, że skilla tylko zjada tokeny i zaśmieca folder. Stare, nieprzeglądane biblioteki to pierwsza rzecz do porządków — jeszcze dziś.
9.Gwarancje dają hooki, nie wielkie litery
Na czym polega: dopiski „WAŻNE” czy „MUSISZ TO ZROBIĆ” w regułach przestały działać. Jeśli potrzebujesz pewności, że coś się wydarzy albo nigdy się nie wydarzy, pisz hooki — drobne, wykonywalne skrypty uruchamiane w zdefiniowanym momencie, np. przy każdym użyciu narzędzia przez Claude’a. Są całkowicie deterministyczne, nie zużywają tokenów i wykonają się zawsze.
Jak stosować: przejrzyj claude.md i znajdź wszystko pisane wielkimi literami. Każdy taki zapis to albo coś, co Claude robi i tak (do usunięcia), albo coś, co nie może się nigdy zdarzyć — jak wysyłka maila do klienta — i wtedy robisz z tego hooka, który ją blokuje.
Na co uważać: granice wpisane do promptu to prośba, nie zabezpieczenie. Tylko hook faktycznie blokuje działanie.
10.Skład zespołu agentów i harmonogram zostaw modelowi — ty ustawiasz limity
Na czym polega: na początku roku zespoły agentów składano ręcznie (orkiestrator, pliki agentów, routing), ale Opus 5 sam chętniej niż jakikolwiek poprzednik oddaje pracę podagentom. Przy drobnych zadaniach mnożenie głów tylko podnosi koszt i czas, więc Anthropic radzi ograniczyć liczbę podagentów w konfiguracji. Z kolei nowe „projects” to jedna ciągła rozmowa, która sama otwiera wątki i działa nawet przy wyłączonym komputerze — a połączenie jej odizolowanego kontekstu z zadaniami wyzwalanymi zegarem albo zdarzeniem (lead w CRM, pozycja na liście) pozwala pracować bez ciebie.
Jak stosować: przy briefie badawczym bez przygotowanych plików Claude sam uruchomi odpowiednich pomocników — twoim zadaniem jest tylko limit i granice. Jeden wyjątek: gdy budujesz skilla z ciężkim krokiem badawczym albo połączeniem z MCP, każ ten krok wykonać w podagencie, żeby główny czat pozostał czysty. W projektach ustaw rutyny w kodzie albo zaplanowane zadania w trybie czatu czy co-worku — autor tak produkuje cały content na Instagrama, klikając wyłącznie „zatwierdź”.
Na co uważać: poziom „ultra code” potrafi bez końca dokładać kolejnych podagentów — bez limitu rachunek rośnie. I nie myl automatyzacji z pełną autonomią: twoją rolą pozostaje potwierdzanie wyników każdego procesu.
Redakcyjne tłumaczenie
Dziewięć miesięcy, które zmieniły zasady gry
Przez cały ostatni rok każda porada o Claude Code brzmiała tak samo: zaczynaj w plan mode. Tak radził nawet człowiek, który to narzędzie zbudował. (Informacja dodatkowa: chodzi o Borisa Cherny’ego, twórcę Claude Code — narzędzia Anthropic do pracy z agentem AI z poziomu terminala, używanego głównie w programowaniu i automatyzacjach.) W styczniu opowiadał, że większość sesji rozpoczyna od trybu planowania. Dwa tygodnie temu na Hacker News stwierdził natomiast, że plan mode nie jest już przydatny. Dziewięć miesięcy różnicy — a sposób, w jaki Boris i pozostali najlepsi użytkownicy pracują z Claude, zmienił się nie do poznania. Poniżej dziesięć rzeczy, które robi dziś ta czołówka, żebyś mógł dopiąć nowoczesny setup i przestać tracić czas na przestarzałe rady. Zaczynamy od tego, co zajęło miejsce plan mode’u.
Czym naprawdę był plan mode
Jeśli się zastanowić, czym plan mode był naprawdę, szybko widać, że nigdy nie zmieniał tego, co Claude potrafi. Doklejał po prostu do każdej wiadomości przypomnienie w stylu: „Jesteś w trybie planowania, jeszcze nie zaczynaj kodować”. Boris wymyślił to kiedyś późnym wieczorem w niedzielę, bo miał dość proszenia Claude’a o plan, zanim cokolwiek zbuduje. Dziś aż trudno uwierzyć, że pomysł z jednej niedzielnej nocy na dobre zagościł w codziennej pracy ludzi korzystających z Claude Code.
W swoim czasie był jednak naprawdę przydatny. Starsze modele — wystarczy przypomnieć sobie Sonnet 4.6 czy pierwsze wydania Opusa — miały zwyczaj rzucać się na robotę bez preludium. To była wada modeli, nie metody. Nowsze generacje planują już w trakcie wykonywania zadania, więc Boris po prostu przestał tego używać.
Zamiast planu: trzy linie briefu
Jak tłumaczył na Startup School (Informacja dodatkowa: cykl wykładów akceleratora Y Combinator), dziś opisuje zadanie, granice, w których ma się ono zmieścić, oraz to, co uznamy za gotowe — a resztę model wypracowuje sam. Przy cotygodniowym raporcie dla klienta wystarczą często trzy linie. Zadanie: raport z bieżącego tygodnia na podstawie eksportu z CRM. Granice: nie zmieniaj ustalonego szablonu i nie wysyłaj maili do nikogo. „Gotowe”: każda liczba zgadza się z eksportem. Zamiast czytać przed startem plan, sprawdzasz po fakcie, co zostało zrobione. Taka jest obecnie cała doktryna.
Dowód zamiast obietnicy: jednostronicowe omówienie
Przy większych zmianach Boris prosi Claude’a o diagram, a niekiedy o interaktywne demo tego, co zostało przerobione. Na marginesie: Anthropic zapowiedziało właśnie wbudowaną funkcję tworzenia interaktywnych dashboardów i animowanych omówień, więc taki materiał dostaniemy jeszcze łatwiej. Gdy zadanie się kończy, warto poprosić o jednostronicową wizualizację: co zostało zrobione i co przy okazji założono.
Obrazek, który tu wspólnie budujemy, wygląda tak: z jednej strony jesteś ty, a jedyne, co piszesz, to brief. Claude wykonuje pracę, a do ciebie wracają dwa elementy — wynik i jednostronicowe omówienie. Oceniasz więc efekt, zamiast z góry rozpisywać każdy krok.
„Think hard” przestało być zaklęciem
Nasz brief mówi dokładnie, co zrobić i jakich granic nie przekraczać — a mimo to wielu ludzi próbuje dodatkowo sterować tym, jak intensywnie Claude myśli. Nowa rada brzmi: odpuść. Może pamiętasz zeszłoroczne porady, by wpisywać „think”, „think hard”, „think harder” albo „ultra think” — każda formuła dawała większy budżet rozumowania. Dziś Claude Code czyta „think hard” po prostu jako fragment promptu, czyli jako zwykłe słowa. To sterowanie przeniosło się do osobnego ustawienia — poziomu wysiłku (effort) — a przy nim każdy model ma wartość zalecaną przez producenta. Opusowi 5.5 przypisano „medium”, a Anthropic zapewnia, że na tym poziomie dorównuje lub prześciga Opusa 5 ustawionego na „high” w kodowaniu i pracy z wiedzą. Mówiąc po ludzku: domyślna konfiguracja załatwia dziś to, co kiedyś robiłeś ręcznie — mniejszym nakładem kroków i tokenów. Przy zdecydowanej większości zadań po prostu nie ruszaj tego suwaka. Jedna rzecz mniej do pilnowania. Nie zdziwiłbym się, gdyby wkrótce to ustawienie całkiem znikło, a dobór intensywności działał w tle. Sedno: zaufaj ustawieniom Claude’a.
Weryfikacja: tani sposób na dwu-, trzykrotnie lepszy wynik
Kolejne dwa punkty odpowiadają na pytanie, jak Claude udowadnia, że zadanie faktycznie wykonał. Jedna rzecz ze styczniowego posta Borisa pozostała świeża: jeśli dasz Claude’owi sposób na sprawdzanie własnej pracy, jakość końcowego wyniku wzrośnie dwu-, trzykrotnie. W dokumentacji Anthropic to dziś pierwsza rada na liście. Test, który Claude może sam uruchomić, rozstrzyga, czy sesja wymaga twojej obecności, czy możesz od niej odejść od biurka. Jeśli zależy ci na układach, które wystarczy nadzorować — ten punkt będzie kluczowy.
Nie chodzi o wpisanie do promptu „sprawdź jeszcze raz swoją pracę”. Poradnik dla Opusa 5 mówi wprost, że model i tak weryfikuje własny wynik, więc takie zdanie jedynie dopala tokeny, niczego nie poprawiając. Zamiast tego zawsze podawaj kryteria, którym pracja może podołać albo nie — czyste zdane/niezdane. W naszym przykładzie prosimy Claude’a o napisanie małego skryptu check report, który sprawdzi raport klienta według definicji „gotowe” z briefu: porówna każdą liczbę z eksportem i upewni się, że wszystkie sekcje szablonu są wypełnione.
Jak to wygląda w praktyce? W pierwszym przebiegu jeden test się wywali — jakaś liczba nie zgadza się z eksportem. Claude cofa się, poprawia, uruchamia testy ponownie i dopiero gdy wszystko przechodzi, pokazuje wynik. Dla nas oznacza to, że czytamy dowody, zamiast samodzielnie przekładać raport na dane źródłowe. Przepis jest prosty: wróć do definicji „gotowe” z briefu i przerób tę jedną linię na test, który Claude będzie mógł odpalić. Test nie musi być wykonywalnym kodem — równie dobrze posłuży dokument tonu marki, wobec którego porównywany jest szkic. Im bardziej mechaniczny warunek, tym więcej błędów wyłapie.
/goal, czyli kto ma wpisywać „kontynuuj”
Claude przejmuje coraz więcej pracy i przynosi nam dowód, że zrobił to, co trzeba. Ale z tego jest pożytek tylko wtedy, gdy może pracować aż do zaliczenia testów — w przeciwnym razie sam będziesz co chwilę wpisywać „kontynuuj”, żeby doprowadził dowody do porządku. Tu wchodzi /goal. Ta komenda wpisuje „kontynuuj” za ciebie. Można mieć nadzieję, że w przyszłości wystarczy ustawić kryteria i model sam będzie się kręcił w pętli do ich spełnienia — ale na dziś używamy /goal.
Jest jednak haczyk i to poważny. Po każdej turze osobny, mały model — Haiku — czyta twój cel i rozstrzyga, czy warunek spełniono; jeśli nie, Claude podejmuje kolejną próbę. Problem w tym, że ów sędzia nie uruchamia poleceń ani nie zagląda do plików. Dostaje wyłącznie waszą rozmowę i wynik Claude’a. Jeśli więc cel jest mętny — „gotowe, kiedy raport jest skończony” — pętla domknie się przedwcześnie: model uzna, że spełnił kryterium, choć wcale nie spełnił. Cel musi być jasny i jednoznaczny — najlepiej po prostu odesłanie do testu z poprzedniego punktu. Zgodnie z zaleceniami Anthropic dobry cel ma jeden stan końcowy, mówi, jak go udowodnić, wymienia, co nie może się zmienić, i ma limit tur, żeby nie kręcił się w nieskończoność. Mój przykład jest maksymalnie prosty: „Skrypt check report przechodzi i pokazujesz wynik. Szablon pozostaje bez zmian. Po piętnastu turach się zatrzymujesz”. Dzięki temu pętla sprawdzania działa bez nas — nie pilnujemy jej, tylko potwierdzamy, że wyniki są dokładnie takie, jakich oczekiwaliśmy.
Fundament: claude.md jako spis treści warsztatu
Nasi agenci kręcą już pętle wokół nas, więc pora się upewnić, że podstawowe instrukcje w claude.md nie rozmijają się z najnowszymi zaleceniami Anthropic. (Na marginesie: jeśli coś z dotychczasowej części było dla ciebie nowe, autor zaprasza do nadchodzącego kursu w jego społeczności Agentic Academy, poświęconego przekazywaniu codziennych obowiązków Claude’owi, Codexowi i innym narzędziom; link w opisie filmu.)
Wszystko, o czym mówiliśmy, stoi na fundamencie, o którym teraz mowa. Gdy niedawno wychodził Opus 5, Anthropic zrobiło rzecz niesłychaną: usunęło ponad 80 procent własnych instrukcji Claude Code, bo większość z nich łatała pomyłki starych modeli. Nie jest też nowością, że dokumentacja każe trzymać claude.md poniżej 200 linii — dłuższy plik więcej kosztuje i jest słabiej respektowany. Tak natomiast ja dziś o tym myślę, i może przydać się tobie: claude.md to spis treści twojego warsztatu. Pełni tę samą rolę, jaką w folderze skilla pełni skill.md.
W claude.md powinny zostać cztery rzeczy. Po pierwsze: narzędzia i komendy, których Claude nie zgadnie sam. Po drugie: wszystko, co robicie inaczej, niż zrobiłby to Claude z własnej inicjatywy. Po trzecie — blisko związane z poprzednim — potknięcia, które zdarzyły się więcej niż raz. Po czwarte: granice, o których już mówiliśmy, w stylu „napisz tylko szkic maila”. Cała reszta pliku staje się odnośnikiem do innego dokumentu, z którego model dociągnie szczegóły wtedy, gdy ich potrzebuje.
Trzy zasady odnośników i audyt /doctor
Same odnośniki też mają trzy reguły. Pierwsza: pisz referencję jako ścieżkę, nie jako import. Symbol @ załaduje cały plik do każdej sesji — zamiast tego podajemy ścieżkę w odwrotnych apostrofach wraz z warunkiem otwarcia, na przykład: „przeczytaj brief klienta przed każdą pracą dla klienta”. Wtedy Claude otworzy plik dopiero we właściwym momencie i dopiero wtedy zabierze go do kontekstu. Druga: każdy plik wskaż bezpośrednio z claude.md. Zgodnie z dokumentacją plik osiągalny wyłącznie pośrednio — zagnieżdżony pod innym plikiem — jest podglądany tylko w pierwszych stu liniach, a więc można przegapić właśnie te szczegóły, o które nam chodzi. Trzecia: każdy plik dłuższy niż sto linii powinien mieć u góry spis treści. Ta zasada obowiązuje oficjalnie pliki skilli, ale ja stosuję ją do wszystkiego, na co wskazuje indeks, bo częściowy odczyt pierwszych stu linii dotyczy każdego pliku.
To sporo reguł. Możesz wprowadzić je ręcznie albo po prostu uruchomić /doctor prompt audit. Komenda przejrzy claude.md, skille i reguły: wypatrzy instrukcje pisane pod starsze modele, ścieżki, które przestały istnieć, i pliki, które sobie przeczą. Niczego nie zmieni, dopóki tego nie zatwierdzisz. Potem wycina z instrukcji wszystko, co Claude robi i tak, a z reszty robi spis treści — indeks z odnośnikami do kolejnych plików.
Na naszej tablicy claude.md leży pod spodem, bo jest czytany przed wszystkim innym i jest fundamentem każdej pracy. To indeks; każda strzałka prowadzi do pliku, który Claude otwiera tylko wtedy, gdy go potrzebuje. To tzw. progressive disclosure — stopniowe doładowywanie: kontekst zjawia się dopiero wtedy, kiedy jest potrzebny. Sam claude.md trzyma wyłącznie informacje zawsze prawdziwe.
Skille na opak: najpierw błędy, potem plik
Wracając do tygodniowego raportu: sposób jego przygotowania trafi do skilla wtedy i tylko wtedy, gdy Claude nie radzi sobie z nim dobrze od razu, bez wsparcia — „z pudełka”, jak mówią Anglicy. To punkt, na którym sam wielokrotnie się potykałem przy budowaniu skilli. Większość z nas układa proces w głowie i od razu każe zbudować skilla, zanim Claude choć raz spróbuje zadania na czysto. Poradnik Anthropic każe działać dokładnie odwrotnie, zwłaszcza że modele są dziś znacznie sprawniejsze. Pierwszy krok: wykonaj zadanie bez skilla. Pracujesz z Claude’em po prostu, uruchamiasz go na prawdziwych zadaniach i notujesz, gdzie faktycznie zszedł z toru. Skilla rozwiązuje wtedy problemy realne, zamiast dokumentować wyobrażone. Nie budujemy „skilla dla procesu” — robimy de facto inżynierię wsteczną: plik ma zaradzić temu, czego Claude nie potrafił naprawić sam.
Zauważ nurt zmian z ostatnich pół roku: zostaw Claude’owi spokój, dopóki nie zacznie się mylić, a wtedy dopiero dodawaj infrastrukturę — pliki takie jak skille — jako podporę na drodze do celu. Zespół Anthropic sam przyznaje, że ich najlepsze skille zaczynały się od kilku linii i jednej poprawki rzeczy, którą Claude psuje sam z siebie. Skill to więc lista tego, co poszło nie tak, a nie podręcznik całego procesu.
Jest i druga droga: dziś można nagrać skilla w aplikacji desktopowej, a narzędzie zrobi resztę, patrząc na twoją pracę. Gdy testowałem to na automacie obsługi wiadomości na Instagramie, zapisywał rzeczy, które sam popsułem w demie — i dokładnie je udokumentował. Pamiętam, jak zaskakująco mały wyszedł ten plik. Dziś wiem dlaczego: utrwalał tylko to, czego Claude nie zrozumie bez podpowiedzi. Przepis: wybierz proces do automatyzacji, przeprowadź go bez skilla na dobrym modelu i wypisz wyłącznie korekty, które doprowadziły do twojej definicji „gotowe”. I koniecznie testuj na modelu, na którym będziesz potem pracować — inne modele radzą sobie inaczej i potrzebują mniej albo więcej instrukcji.
Na tablicy skille stoją obok indeksu claude.md.claude.md opisuje to, co zawsze prawdziwe dla całego warsztatu czy firmy; skilla opisuje jeden konkretny proces — i w większości są to same korekty.
Biblioteki skilli: test z atrapą
Krótko o paczkach skilli, bo popularne zestawy krążące po sieci zbierają tysiące gwiazdek. Jeden z deweloperów pod koniec września wziął na warsztat dziewięć z nich: 450 przebiegów na Opusie 5.5. Tylko dwie paczki z dziewięciu wypadły lepiej niż plik-atrapa o tej samej długości. To mówi samo za siebie. Wśród najlepiej ocenianych skilli dla agentów kodujących kontekst zapisany w środku nie poprawiał wyniku w siedmiu scenariuszach na dziewięć. Na szczęście Claude Code ma dziś wbudowany sposób, by to sprawdzić: plugin eval uruchamia to samo zadanie z twoim skillem i bez niego, a potem ocenia różnicę. Widzisz czarno na białym: skilla kontra brak skilla — jak model radzi sobie z zadaniem, które chcesz wykonać. Narzędzie pomyślano głównie o wtyczkach, ale da się je przerobić na pojedyncze skille; tak zrobiłem dla członków mojej społeczności. Zasada odczytu: jeśli oba wyniki wyszły tak samo, skilla tylko zjada tokeny. To dekoracja. Do tego zaśmieca folder.
U mnie porządki wyglądały tak: najpierw /skill doctor, który pokazuje, ile każdy skilla kosztuje i jak często bywa używany — nieużywane wyrzuciłem. Potem plugin eval na pozostałych i jeszcze kilka poszło do kosza. Nic dziwnego, jeśli pomyśleć, jak dobre są dziś modele — większość z nas po prostu nie odświeżyła starych bibliotek. Jeśli z całego materiału masz wynieść jedną rzecz, niech będą to porządki w skillach, jeszcze dziś.
Wielkie litery wyrzucić, napisać hooki
Mamy już prawie całą krytyczną infrastrukturę. Zostały trzy elementy, które wyraźnie przyspieszą pracę bez szkody dla jakości. Pierwszy: pewnie zauważyłeś, że dopisywanie słów „WAŻNE” albo „MUSISZ TO ZROBIĆ” do reguł — bo Claude ciągle coś psuł — przestało działać. Jeśli chcesz mieć gwarancję, że coś się wydarzy albo nigdy się nie wydarzy, pisz dobre hooki. Hook to drobny, wykonywalny skrypt uruchamiany w zdefiniowanym przez ciebie momencie — na przykład tuż przed każdym użyciem narzędzia przez Claude’a albo przy każdym takim użyciu. Działa całkowicie deterministycznie: nie zużywa tokenów i wykona się zawsze, bez wyjątków. W naszym przykładzie zamiast reguły „nigdy nie wysyłaj maila do klienta” usuwamy tę linię i zamieniamy w hooka, który blokuje każdą wysyłkę do klienta. To jest właśnie gwarancja — skrypt odpali się zawsze, gdy tylko zajdzie warunek. Przepis na porządki: przejrzyj claude.md i znajdź wszystko pisane wielkimi literami. Każdy taki zapis to albo coś, co Claude robi i tak — do usunięcia — albo coś, co nie może się nigdy zdarzyć — do przerobienia na hooka. Wracając do pierwotnej rady Borisa: to po prostu barierki przypięte do działań, których Claude może podjąć się w twoim imieniu.
Zespół agentów dobiera model, ty trzymasz hamulec
Ostatnie dwa punkty dotyczą tego, jak daleko możemy się odsunąć od samej pracy i pozwolić, by działo się bez nas — na przykład czy sami stawiać podagentów i zespoły agentów, czy i to oddelegować. Na początku roku zespoły składaliśmy ręcznie: orkiestrator, pliki agentów, routing. Był jeden agent prowadzący, mogliśmy rozmawiać z każdym podagentem i zlecać mu zadania. Tymczasem poradnik Opusa 5 mówi, że ten model chętniej niż jakikolwiek poprzednik oddaje pracę podagentom. Przy drobnych zadaniach — ostrzega Anthropic — takie mnożenie głów tylko podnosi koszt i wydłuża czas. Ich rada: ograniczyć w konfiguracji liczbę podagentów, żeby przy prostym zadaniu nie nasiąkało ich bez końca. Po ludzku: ocena, jakiego zespołu wymaga praca, ilu członków potrzeba i co komu zlecić, należy dziś do Claude’a. Twoja rola to ustawienie, jak duży zespół wolno mu zbudować — granice i hamulce, które nie pozwolą przepłacić zadania, które tego nie wymaga. Sprawdziłem to na briefie mocno badawczym, bez przygotowanych plików agentów: w panelu zadań widać, że domyślnie uruchamia własnych pomocników — rozumie, jaki wybrać tok pracy i którym podagentom co przydzielić. Może pamiętasz też modę na „ultra code” jako poziom wysiłku: ten tryb wypluwa całe zestawy podagentów i potrafi bez końca dokładać kolejne do ekipy.
Jedno zastrzeżenie przy tym delegowaniu: jeśli właśnie budujesz skilla — bo Claude na czysto ma ograniczenia — a proces zawiera duży krok badawczy albo podłączenie do MCP lub konektora, każ ten krok wykonać w podagencie. Główny czat zostaje wtedy czysty dla pracy, która naprawdę się liczy. W końcu jeden z powodów, dla których w ogóle sięgamy po podagentów, to niezasmiecony główny kontekst. Podsumowując: Claude sam dobierze pomocników do procesu — ty kontrolujesz limit w konfiguracji.
Projekty: praca, która dzieje się bez ciebie
Ostatnie odblokowanie dotyczy uruchamiania wszystkiego bez twojego udziału. Marzenie o leżaku z drinkiem, podczas gdy agenci prowadzą całą firmę, jeszcze się nie spełniło — ale zbliżamy się do celu. Najnowsza odsłona projektów w Claude Code idzie właśnie w tę stronę. Projekt to teraz jedna nieprzerwana rozmowa, która sama otwiera własne wątki (kiedyś trzeba było ręcznie zakładać sesje) i pracuje dalej, nawet gdy komputer jest wyłączony. Równolegle puszcza wielu agentów nad konkretnym zadaniem. Skąd ta siła? Z połączenia odizolowanego kontekstu projektu z zadaniami odpalanymi zegarem albo zdarzeniem: nowa pozycja na liście rzeczy do zrobienia, nowy kontakt czy lead w CRM. Można ustawić rutyny w kodzie albo zaplanowane zadania w trybie czatu czy co-worku — i takie układy załatwiają pracę, gdy nas nie ma. Tak powstają dziś wszystkie moje karuzele i krótkie materiały na Instagrama; moja rola sprowadza się do kliknięcia „zatwierdź” we własnoręcznie zbudowanym panelu. Tym setupem dzielę się z członkami Agentic Academy — a sprawa zyskuje na wadze, bo Codex ogłosił właśnie zdarzenia MCP dla wtyczek: podłączone aplikacje mogą same wyzwalać wykonanie, gdy coś się stanie. W efekcie wszystko, o czym rozmawialiśmy, pakujemy w pudełko, które działa samo, a ty przechodzisz do kolejnego procesu do automatyzacji — bo jedyne, co ci zostaje, to potwierdzanie wyników. Jeśli chcesz przeprowadzić pierwszą taką automatyzację z czyjąś pomocą, od tego właśnie jest Agentic Academy.
W następnym materiale przejdę przez wszystkie zmiany w budowaniu skilli z ostatniego roku. Do zobaczenia.