5 Claude Cheat Codes Only The Top 1% Use

O czym jest ten film

1. Nie potrzebujesz góry skilli i skomplikowanych narzędzi — wystarczy kilka prostych komend Claude Code, wykonanych naprawdę dobrze.
2. Komenda checkup (znana też jako doctor) sprawdza kondycję konfiguracji: serwery MCP, definicje agentów, skille, pluginy i globalnie zainstalowane pakiety.
3. Największym problemem większości użytkowników jest zaśmiecone okno kontekstu — zwłaszcza przez globalnie zainstalowane skille i pluginy ładowane do każdej rozmowy.
4. Komenda goal pozwala zlecić duże zadanie, które model realizuje autonomicznie, samodzielnie kompaktując kontekst, aż osiągnie weryfikowalny stan końcowy.
5. Autor pokazuje goal na przykładzie automatycznego przejścia przez wszystkie „smoke testy” aplikacji przez MCP sterujące symulatorem iOS.
6. Komendy status line i /context dają wgląd w zużycie tokenów w czasie rzeczywistym i pokazują, na co dokładnie idzie kontekst sesji.
7. Zadania typu goal czy pętle zużywają więcej tokenów — to naturalne, bo pracują nieprzerwanie w tle; przy planach Max to zwykle nie problem.
8. Komenda recap generuje jednoliniowe podsumowanie tego, nad czym pracowałeś w danym projekcie — pomaga zapanować nad obciążeniem poznawczym przy wielu równoległych sesjach.
9. Komenda by the way (w) pozwala na krótką rozmowę poboczną bez zalewania głównego okna kontekstem, a fork (f) pozwala odgałęzić z niej osobny wątek.
10. Wniosek końcowy: kolekcjonowanie narzędzi ma sens tylko wtedy, gdy faktycznie budujesz z nimi działające rzeczy — dla siebie, do pracy albo na sprzedaż.

Redakcyjne tłumaczenie

Wstęp: nie narzędzia, tylko dobra egzekucja

W tym materiale omawiam pięć nowych komend Claude Code, które mogą przenieść twoją pracę na wyższy poziom. Większość „vibe coderów” (Informacja dodatkowa: potoczne określenie osób programujących głównie przez konwersację z modelem AI, bez głębokiego wchodzenia w kod) sądzi, że do zbudowania czegoś, z czego mogliby być naprawdę dumni, potrzebują skomplikowanych narzędzi albo góry skilli. Rzeczywistość jest inna: wystarczy kilka prostych narzędzi, wykonanych naprawdę dobrze. Przejdę przez te pięć komend, wytłumaczę, dlaczego są cenne, i pokażę, jak z nich korzystać. Zaczynamy od najnowszej: checkup.

1.checkup (alias doctor) — kontrola kondycji konfiguracji

Zawsze zdumiewało mnie, jak ludzie potrafią przepalić plan Claude Max za 200 dolarów miesięcznie już pierwszego dnia po odnowieniu limitu, a potem bez końca narzekać na to w sieci. Częściowa przyczyna jest taka, że kiedy instalujesz mnóstwo różnych skilli i serwerów MCP, te rzeczy zapychają twoje okno kontekstu. Są ładowane domyślnie — zwłaszcza jeśli zainstalowałeś je globalnie na maszynie — i przekazywane do modelu przy każdej rozmowie. To potrafi zająć bardzo dużo miejsca.

Komenda checkup pomaga przyjrzeć się ogólnej konfiguracji: wszystkim serwerom MCP, definicjom agentów, skillom, pluginom i globalnie zainstalowanym pakietom. Chodzi o to, żeby upewnić się, że nie strzelamy sobie w stopę, zanim jeszcze cokolwiek uruchomimy.

W moim przypadku narzędzie przeszło przez około osiem parametrów. Omówmy je pokrótce:

• Ogólna kondycja konfiguracji — czy coś jest wprost zepsute albo czy nie zostały gdzieś „wiszące” pliki instalacyjne lub konfiguracyjne. U mnie nic do naprawy.
• Nieużywane rozszerzenia — czy w systemie są zainstalowane pluginy i podobne rzeczy, które zajmują kontekst, ale których w rzeczywistości nie używasz. Skoro ich nie używasz, można je po prostu wyłączyć i wyciąć.
• Pliki CLAUDE.md — to jedno z głównych źródeł marnotrawstwa. Jeśli naprawdę chcesz być dobry w tej robocie, musisz mieć wręcz wojskową dyscyplinę w zarządzaniu plikami CLAUDE.md i trzymać się pewnych standardów. U mnie żadnych zastrzeżeń: pliki są w porządku, mieszczą się pod progami ostrzegawczymi, wiersze nie są za długie, nic się nie kłóci ze sobą i nie ma tam bzdur.
• Kontrola kontekstu — i to jest rzecz, która okaże się kluczowa dla jakichś 90% oglądających. Największym problemem będą globalnie zainstalowane skille i pluginy. Z grubsza tylko około 1% budżetu kontekstu powinno iść na skille i komendy oraz na wiedzę o tym, do czego służą. Ja rozwijałem u siebie lokalnie mnóstwo skilli, dlatego mam ich sporo i muszę to wszystko posprzątać — widać, że przekraczam ten próg. To spowoduje problemy, bo te definicje trafiają do modelu i wpadasz w sytuacje, w których skille nie są właściwie używane albo routowane, a inne komendy również przestają działać jak należy.

Zaletą tej komendy jest to, że pomaga wszystko posprzątać. Zauważyłem właśnie, że można teraz klikać w te elementy — nigdy wcześniej tego nie robiłem, bo zawsze siedzę na klawiaturze, ale okazuje się, że da się kliknąć. Domyślnie lubię używać trybu automatycznego, więc robimy takie rzeczy, jak ustawienie trybu auto jako domyślnego. Ogólnie jednak po prostu przechodzimy przez komendę checkup/doctor, żeby upewnić się, że konfiguracja jest w porządku i nie tłuczemy głową w mur, walcząc z błędami, których w ogóle nie powinno tu być. Jeśli chcesz wyciskać z tokenów maksimum przy ograniczonym budżecie, musisz przynajmniej nie robić rzeczy kompletnie głupich.

2.goal — autonomiczna praca do weryfikowalnego końca

Komenda checkup jest właściwie warunkiem wstępnym dla następnej, którą pokażę. Jednym z niedocenianych bohaterów ostatnich miesięcy jest komenda goal — Claude ma swoją wersję, OpenAI ma swoją. Zadajesz jej cel, do którego będzie nieprzerwanie dążyć, po drodze automatycznie kompaktując kontekst w miarę potrzeby, aż zadanie zostanie faktycznie ukończone.

To świetne rozwiązanie, kiedy masz do wykonania bardzo duży zakres pracy i istnieje weryfikowalny stan końcowy — czyli sytuacja, w której da się jednoznacznie stwierdzić, że praca jest gotowa. Przykłady, które sami podają:

• duże migracje z warunkiem, że wszystkie testy przechodzą,
• wdrażanie dokumentu projektowego, aż wszystkie kryteria akceptacji są spełnione,
• refaktoryzacja bardzo dużych plików w wąsko wyspecjalizowane moduły mieszczące się pod określonym limitem rozmiaru,
• moje ulubione: przechodzenie przez zaległości (backlog) zgłoszeń, aż kolejka jest pusta.

To ostatnie posłuży za inspirację do tego, co chcę pokazać. Kiedy chcę zbudować dużo funkcji naraz i puścić je autonomicznie, zawsze pojawia się idea smoke testu (Informacja dodatkowa: podstawowy test sprawdzający, czy najważniejsze funkcje w ogóle działają). Musimy móc ręcznie sprawdzić rzeczy, które rzekomo właśnie zaimplementowaliśmy — mieć pewność, że powstały tak, jak chcieliśmy.

Jest to szczególnie ważne, gdy budujesz z agentami. Modele językowe często piszą dla ciebie testy, które w rzeczywistości niczego sensownego nie sprawdzają: test przechodzi, ale to, co miało się dziać, wcale się nie dzieje. Dlatego trzeba przejść przez logikę i faktycznie zweryfikować, że działa.

W kontekście tej aplikacji — natywnie agentowej aplikacji do śledzenia odżywiania — smoke test wyglądałby tak: gdybym powiedział „zaloguj mój bowl z kurczakiem z zeszłego wtorku”, aplikacja powinna odnaleźć to w bazie danych, zapisać i na tej podstawie zaplanować mój dzień. Dla różnych scenariuszy powinny dziać się różne rzeczy — i to wszystko chcielibyśmy realnie przetestować. W tym przypadku wdrożyliśmy sporo takich funkcji w Open Spec i każdą z nich trzeba by przetestować ręcznie. Ten proces możemy zautomatyzować właśnie komendą goal.

Konstrukcja polecenia wygląda następująco. Pamiętając, że potrzebujemy weryfikowalnego kryterium wyjścia, mówimy: „Chcę, żebyś sprawdził każdy smoke test” — odwołując się do tego pliku, na który patrzyliśmy. „Chcę, żebyś przetestował każdą z tych rzeczy, używając iOS MCP” — to sposób sterowania symulatorem. „Zrób to autonomicznie i zgłoś wyniki.” Nie proszę o naprawianie — tylko o wykonanie każdego elementu testu (było ich kilkanaście do dwudziestu kilku) i podanie rezultatu. Nie każę mu przez pięćdziesiąt godzin testować, naprawiać i ponownie testować wszystkiego — to też jest możliwe, ale nie w tym przykładzie.

Definiuję kryterium: „Zadanie uznaje się za zakończone, gdy każdy element listy w smoke teście został przetestowany, a wyniki udokumentowane. Zaznacz, czy zadziałało poprawnie, czy wystąpiła awaria, i porównuj interfejs z zamysłem danej funkcji.” To była duża migracja UI, więc chcemy mieć pewność, że działa tak, jak powinno. Zaznaczam też, żeby poszczególne fazy były wykonywane przez subagentów. Następnie odpalam całość — i zaczyna się wykonywać autonomicznie w tle.

Rzecz, na którą trzeba uważać w trakcie, to zużycie tokenów. Moja filozofia jest taka: oczywiście goal czy pętla zużywają więcej tokenów, bo cały czas pracują. Dopóki cel nie jest osiągnięty, narzędzie nieprzerwanie coś robi. Kiedy więc ludzie narzekają, że cele, pętle i workflow zużywają więcej tokenów — no jasne, że tak, bo pracują bez przerwy w tle. I to jest w porządku, trzeba tylko mieć tego świadomość. Musimy zaakceptować w głowach, że to zastępuje nas samych, robiących te wszystkie rzeczy ręcznie. Ile to jest dla ciebie warte — to już kwestia osobista. Jeśli masz plan Claude Code Max i Codex Max, każdy po 200 dolarów miesięcznie, to naprawdę trudno wyobrazić sobie, żebyś realnie wyczerpał limit tokenów, chyba że działasz skrajnie nieodpowiedzialnie. Tak, to zużyje więcej tokenów, ale pozwala ci w tym czasie zająć się czymś innym. Takie zadanie zajmie przynajmniej godzinę–dwie.

3.Kontrola wydatków: status line i /context (dwa w jednym)

Skoro zadanie mieli w tle, porozmawiajmy o tym, jak w ogóle śledzić zużycie. To będzie dwa w jednym. Pierwsze narzędzie to komenda, której używam od dawna i wciąż zaskakuje mnie, że wielu ludzi jej nie zna — pytają: „Skąd masz ten pasek na dole, który pokazuje, ile tokenów zużyłeś albo ile ci zostało?”.

Wpisujesz status line i podajesz komendę (dokładne polecenie zostawiam w opisie pod filmem). Można na przykład poprosić: chcę widzieć używany model, katalog, work tree, aktualny rozmiar okna kontekstu oraz limity zużycia kontekstu w oknie 5-godzinnym i 7-dniowym. Komenda ustawi ci to na dole ekranu, gdzie w czasie rzeczywistym widzisz, ile z alokacji tokenów faktycznie zużywasz i gdzie jesteś w systemie. Ja lubię pilnować modelu, gałęzi, na której pracuję (żeby mieć pewność, że jestem na właściwej), i trzymać laserowy fokus na dokładnym rozmiarze bieżącej sesji. Limitów 5-godzinnego i 7-dniowego zwykle nie muszę śledzić, bo nawet się do nich nie zbliżam — poza sytuacją, gdy używam modelu Fable (Informacja dodatkowa: Fable to jeden z najnowszych, wydajnych modeli z rodziny Claude). To jedyny raz, kiedy realnie musiałem zwrócić uwagę na zużycie 7-dniowe.

Druga komenda to /context. Daje wgląd w zużycie twojej sesji: w miarę jej rozrastania się pokazuje, dokąd trafia kontekst. Wracając do komendy doctor — jeśli zastanawiasz się, gdzie skille zjadają za duży budżet i dokąd w ogóle idzie twój kontekst, to właśnie tu możesz to zwizualizować. Myślę, że twórcy zbudowali to dlatego, że tylu ludzi próbowało tworzyć własne biblioteki open source do obsługi tego typu rzeczy, że w końcu postanowili zrobić to sami. Widzimy więc, ile idzie na prompt systemowy, na używane narzędzia, na własnych agentów, pliki pamięci, skille i wysyłane wiadomości.

Zestaw status line plus /context daje dwa potężne wglądy. Po pierwsze: czy w trakcie rozmów zużywam tokeny w naprawdę głupi sposób, nawet o tym nie wiedząc. Po drugie: czy nie przegrywam bitwy, zanim się zaczęła. Jeśli odpalasz sesję i już na starcie masz zużyte mnóstwo tokenów, masz problem — za dużo załadowanych skilli, może za dużo definicji agentów, plików pamięci, rzeczy zjadających tokeny potencjalnie zupełnie bez powodu. To ogromne marnotrawstwo.

4.recap — panowanie nad obciążeniem poznawczym

Wracając do sesji z goal — wciąż działa, automatycznie steruje symulatorem, testuje wszystko i loguje dokładnie, co się dzieje. To świetne, ale rodzi inny problem. Jeśli prowadzisz taką pracę w trzech, czterech, czasem pięciu sesjach agentowych naraz, a potem musisz odejść od komputera, powstaje kłopot. Nie chcę wchodzić w filozoficzną dygresję, ale ludzie mają naprawdę trudno z zarządzaniem obciążeniem poznawczym przy wielu otwartych pętlach. Otworzyłeś pięć takich rzeczy, musisz gdzieś wyjść — i właśnie wygenerowałeś masę kontekstu, który nie został domknięty ani powiązany. Po powrocie do komputera bardzo trudno odtworzyć ten kontekst.

Z pomocą przychodzi komenda recap. Wyobraź sobie, że skończyłem wczoraj o 20:00, a rano wracam do maszyny i mam otwarty stos okien terminala. Pracuję nad automatycznym systemem pozyskiwania tematów do social mediów, buduję workflow, które generują rzeczy same z siebie, debuguję kilka innych skilli — trzy, cztery, pięć rzeczy naraz. Wchodzę i chcę sprawdzić: co ja tu właściwie wczoraj robiłem?

Wpisuję recap i dostaję jednoliniowe podsumowanie dokładnie tego, nad czym pracowałem w tym projekcie. W moim przypadku mam projekt Topic Genie — importowałem zeszłoroczne filmy i różne „outliery” (Informacja dodatkowa: nagrania odstające wynikami od średniej kanału) dla mojego kanału. Chciałem też dodać cotygodniowe przypomnienie, żeby aktualizować dane zarówno swoje, jak i konkurencji. Narzędzie wszystko zbudowało, a następny krok należy do mnie — więc nie ma tu wiele do roboty, to jest gotowe.

To bardzo ważne, bo naprawdę wyrobisz sobie nawyk zaczynania rzeczy w połowie i nigdy niedoprowadzania ich do końca, bo ciągle łapiesz taki „strzał w kark” pomiędzy rosnącym stosem na wpół zrobionych rzeczy. To jest złe z oczywistych powodów, a komenda taka jak recap pomaga to okiełznać.

5.by the way — rozmowa poboczna i fork

Ostatnia komenda, którą naprawdę bardzo doceniam — gdy jest potrzebna, jest znakomita — nazywa się by the way. Wpisując w, możesz odbyć szybką rozmowę poboczną z modelem, nie zalewając tym kontekstem głównego okna. Sesja z goal wciąż testuje aplikację — przeszukuje bibliotekę, próbuje coś zrobić, robi swoje. Ja tymczasem mogę być na jakimś torze myślowym, na którym chcę o coś zapytać, ale nie chcę przerywać głównego procesu. Komendy by the way używam więc, żeby „wyrzucić coś z siebie”.

Przykład z tego projektu: skoro to aplikacja mobilna i nie mamy właściwie serwera na backendzie, używamy edge functions Supabase (Informacja dodatkowa: funkcje uruchamiane „na brzegu” sieci; Supabase to otwartoźródłowa platforma backendowa) do wywoływania API modeli językowych i uruchamiania naszej pętli agentowej. Zastanawiam się w trakcie: czy na pewno poprawnie zmodyfikowaliśmy te funkcje? Zmienialiśmy kilka wewnętrznych mechanizmów, więc chcę mieć pewność. Wpisuję by the way i zadaję pytanie — może zupełnie podstawowe: gdzie zapisywane są wszystkie raporty? Widzimy katalog smoke results.

Chciałem to pokazać, bo mamy tu opcję forka czatu. Wpisując f, możemy kontynuować tę rozmowę od tego konkretnego punktu — to niemal tak, jakbyśmy odgałęzili zupełnie osobny czat, w którym działamy we własnym subagencie, żeby ciągnąć dalej ten tok rozumowania. Przykładowo mógłbym poprosić: zacznij priorytetyzować i badać główne przyczyny wszystkiego, co dotąd zawiodło. Znów dzieje się to wewnątrz subagenta, a cała nasza główna praca — właściwe testowanie — trwa dalej w głównym wątku.

Uwielbiam tę funkcjonalność by the way i forkowania: możesz wtrącić się, kiedy trzeba, a jeśli z jakiegoś powodu chcesz od razu podążyć tym wątkiem, robisz to na miejscu, nie gubiąc się w kontekście wszystkiego, co się dzieje.

Zakończenie

Zbieranie narzędzi i wiedzy w ten sposób bywa cenne, ale nic nie znaczy, jeśli nie wdrażasz tego w budowanie rzeczy, które faktycznie działają — takich, których używasz sam, w pracy, albo które pakujesz w aplikację lub SaaS i próbujesz sprzedać. Nie bądź gościem, którego skille pokrywają się kurzem na półce. Jeśli chcesz pomocy z wdrożeniem czegokolwiek z tego, sprawdź linki w opisie. To tyle w tym materiale — do zobaczenia w następnym.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Zacznij od checkup/doctor, zanim odpalisz cokolwiek

Na czym polega: Komenda audytuje kondycję konfiguracji Claude Code — serwery MCP, definicje agentów, skille, pluginy i globalne pakiety — i wskazuje, co jest zepsute, nieużywane lub zjada kontekst.

Jak stosować: Uruchamiaj ją okresowo (zwłaszcza po instalowaniu nowych rozszerzeń) i przechodź przez ~8 parametrów, wyłączając to, czego nie używasz. Korzystaj z trybu auto do sprzątania.

Na co uważać: To narzędzie diagnostyczne, nie magiczny przycisk — sam musisz zdecydować, co wyciąć. Nie usuwaj skilli, których faktycznie używasz w innych projektach, tylko dlatego, że w tej sesji nie zostały wywołane.

2.Trzymaj dyscyplinę w plikach CLAUDE.md

Na czym polega: Pliki CLAUDE.md to jedno z głównych źródeł marnowania kontekstu; powinny być krótkie, spójne, bez zbyt długich wierszy i wewnętrznych sprzeczności.

Jak stosować: Trzymaj je pod progami ostrzegawczymi, które wskazuje checkup. Wpisuj tylko to, co realnie kieruje modelem; usuwaj bzdury i powtórzenia.

Na co uważać: Sprzeczne albo rozdęte instrukcje potrafią pogorszyć zachowanie modelu bardziej niż ich brak. Przeglądaj te pliki regularnie, bo rozrastają się niepostrzeżenie.

3.Pilnuj, by skille i komendy nie przekraczały ~1% budżetu kontekstu

Na czym polega: Globalnie instalowane skille i pluginy ładują się do każdej rozmowy; gdy jest ich za dużo, model przestaje poprawnie routować i używać skilli oraz komend.

Jak stosować: Instaluj skille lokalnie w projekcie zamiast globalnie tam, gdzie to możliwe. Utrzymuj definicje skilli/komend w okolicach 1% budżetu kontekstu.

Na co uważać: Objawem przekroczenia nie jest błąd, lecz ciche pogorszenie — skille „nie odpalają się” albo komendy działają nie tak. Nie zwalaj tego od razu na model; najpierw sprawdź /context.

4.Używaj goal do dużych zadań z weryfikowalnym stanem końcowym

Na czym polega: goal realizuje zadanie autonomicznie, samodzielnie kompaktując kontekst, aż spełni jasno zdefiniowane kryterium ukończenia.

Jak stosować: Nadaje się do migracji („wszystkie testy przechodzą”), wdrażania dokumentów projektowych („wszystkie kryteria akceptacji spełnione”), refaktoryzacji dużych plików czy opróżniania backlogu. Zawsze podaj precyzyjne, weryfikowalne kryterium wyjścia i zdecyduj, czy ma tylko raportować, czy też naprawiać.

Na co uważać: Bez jednoznacznego kryterium końca zadanie może kręcić się w nieskończoność. Rozdziel „przetestuj i zaraportuj” od „testuj, naprawiaj i retestuj” — to drugie potrafi pochłonąć wielokrotnie więcej czasu i tokenów.

5.Weryfikuj logikę, nie ufaj samym „zielonym” testom

Na czym polega: Modele często piszą testy, które przechodzą, ale niczego sensownego nie sprawdzają — funkcja rzekomo działa, a naprawdę robi co innego.

Jak stosować: Zdefiniuj smoke testy odwzorowujące realne scenariusze użytkownika (np. „zaloguj mój posiłek z zeszłego wtorku”) i przechodź je manualnie lub automatycznie, porównując interfejs z zamysłem funkcji.

Na co uważać: Przechodzący zestaw testów to fałszywe poczucie bezpieczeństwa, zwłaszcza przy budowaniu z agentami. Wymagaj jawnego porównania działania z intencją, a nie tylko statusu „pass”.

6.Zaakceptuj wyższe zużycie tokenów przy pracy autonomicznej

Na czym polega: goal, pętle i workflow zużywają więcej tokenów, bo pracują nieprzerwanie w tle — to nie usterka, tylko koszt zastąpienia twojej ręcznej pracy.

Jak stosować: Traktuj tokeny jako cenę za odzyskany czas. Przy planach Max (np. Claude Code i Codex po 200 USD/mies.) realnie trudno wyczerpać limit rozsądnym użyciem.

Na co uważać: „Rozsądnym” to słowo klucz — puszczanie w kółko drogich pętli naprawczych bez nadzoru wciąż potrafi przepalić budżet. Monitoruj zużycie w trakcie, nie po fakcie.

7.Ustaw status line, żeby widzieć stan w czasie rzeczywistym

Na czym polega: Komenda status line umieszcza na dole ekranu na bieżąco aktualizowany pasek: model, katalog, work tree, rozmiar okna kontekstu i limity 5-godzinne/7-dniowe.

Jak stosować: Skonfiguruj ją tak, by pilnować przede wszystkim modelu, właściwej gałęzi i rozmiaru bieżącej sesji. Autor udostępnia gotową komendę w opisie filmu.

Na co uważać: Limity 5h/7d rzadko są problemem — zaczynają nim być głównie przy najbardziej „żarłocznych” modelach (jak Fable). Nie ignoruj gałęzi: praca na złej to łatwy, kosztowny błąd.

8.Diagnozuj kontekst komendą /context

Na czym polega: /context pokazuje, dokąd trafia kontekst sesji: prompt systemowy, narzędzia, agenci, pliki pamięci, skille i wiadomości.

Jak stosować: Sprawdzaj ją na starcie sesji i gdy kontekst rośnie. Dwa pytania: czy zużywam tokeny głupio, nie wiedząc o tym, oraz czy nie przegrywam, zanim zacznę (dużo zużytego kontekstu tuż po odpaleniu).

Na co uważać: Wysokie zużycie na starcie to sygnał nadmiaru skilli, agentów lub plików pamięci — potraktuj to jako wskazówkę do sprzątania (checkup), a nie tło do zignorowania.

9.Domykaj otwarte pętle komendą recap

Na czym polega: recap generuje jednoliniowe podsumowanie tego, nad czym pracowałeś w danym projekcie, wraz z kolejnym krokiem — pomaga wrócić do wielu równoległych sesji.

Jak stosować: Używaj jej po przerwie albo przy wielu otwartych terminalach, by szybko odtworzyć kontekst i zobaczyć, czy następny ruch należy do ciebie, czy do modelu.

Na co uważać: To pomoc w orientacji, nie zamiennik dokończenia pracy. Uważaj na nawyk zostawiania rzeczy „na wpół zrobionych” — recap ma go ograniczać, a nie usprawiedliwiać.

10.Wtrącaj się przez by the way i odgałęziaj przez fork

Na czym polega: by the way (w) pozwala odbyć rozmowę poboczną bez zaśmiecania głównego okna kontekstem, a fork (f) tworzy z tego punktu osobny wątek działający w subagencie.

Jak stosować: Gdy w trakcie długiego zadania w tle wpadnie ci pytanie („czy na pewno zmieniliśmy te funkcje?”), zadaj je przez by the way; jeśli warto ciągnąć wątek, forknij go i pracuj równolegle, nie ruszając głównego procesu.

Na co uważać: Forkowane wątki żyją własnym życiem — łatwo namnożyć kolejne otwarte pętle, ten sam problem, który rozwiązuje recap. Wtrącaj się celowo, a nie odruchowo przy każdej myśli.