mattpocock/skills: Learn the whole flow, end-to-end

O czym jest ten film

1. Pierwszy pełny tutorial do popularnego repozytorium „skills” Matta Pococka (162 tys. gwiazdek, 7,5 mln pobrań).
2. Instalacja skillów przez npx skills@latest add mattpocock/skills — działa tak samo na nowym i istniejącym projekcie.
3. Wybór zakresu instalacji: skille projektowe (dla zespołu) albo globalne (dla solowego dewelopera), z rekomendacją symlinków.
4. Skille są głównie „user invoked”, więc obciążają kontekst minimalnie (ok. 660 tokenów).
5. Konfiguracja przez setup mattpocock skills: wybór issue trackera (GitHub, lokalny markdown, Jira, Linear itd.), etykiety triage i dokumentacja domenowa.
6. Skill ask Matt jako interaktywny przewodnik po samym repozytorium i zalecanym przepływie.
7. Główny przepływ „od pomysłu do wdrożenia” realizowany w jednym, nieprzerwanym oknie kontekstu.
8. Start od grill with docs — agent przepytuje użytkownika, aż powstanie jasny plan.
9. Rozwidlenie: albo bezpośrednio implement, albo — dla większych prac — to spec i to tickets, dzieląc pracę na porcje wielkości jednego okna kontekstu.
10. Rola „strefy inteligencji” (ok. 140 tys. tokenów) i automatyczne code review w podagentach na końcu przepływu.

Redakcyjne tłumaczenie

Wstęp: pierwszy tutorial do repozytorium skills

Cześć, przyjaciele. Zdałem sobie sprawę, że tak naprawdę nigdy nie przygotowałem porządnego tutorialu do mojego repozytorium ze skillami. W momencie nagrywania tego materiału repozytorium ma już 162 tysiące gwiazdek, mamy 7,5 miliona pobrań — a ja nigdy nie zrobiłem do tego tutorialu. Ciągle dostaję pytania w rodzaju: w jakiej kolejności powinienem używać tych skillów, jak je zainstalować, jak je skonfigurować? Ten film będzie więc przejściem przez główny przepływ pracy, którego używa się przy korzystaniu z tych skillów.

Nie będziemy zaglądać w zaawansowane rzeczy ani w nowości. Skupimy się na głównym przepływie — na tym, co jest potrzebne, żeby zacząć.

(Informacja dodatkowa: „skille” w ekosystemie agentów AI, takich jak Claude Code, to pakiety instrukcji i procedur, które agent może wywołać do konkretnego typu zadania.)

Repozytorium testowe: AI Hero CLI

Do pokazania tego użyję jednego z moich roboczych repozytoriów — AI Hero CLI. To interfejs wiersza poleceń, który obsługuje wiele ćwiczeń wykorzystywanych na moich kursach. Nigdy wcześniej nie skonfigurowałem tu swoich skillów, więc to świetna okazja.

Jeśli chcesz skonfigurować moje skille w zupełnie nowym projekcie, robisz dokładnie to samo, tyle że w pustym katalogu. Działa to tak samo, niezależnie od tego, czy pracujesz na istniejącej bazie kodu (brownfield), czy zaczynasz od zera (greenfield).

Instalacja skillów

Otwieram wiersz poleceń i wpisuję:

npx skills@latest add mattpocock/skills

To zakłada kilka rzeczy. Zakłada, że masz zainstalowany Node.js — to z niego pochodzi npx — i uruchamia instalator wiersza poleceń skills.sh od Vercela. W praktyce instaluje on repozytorium GitHub ze skillami o nazwie mattpocock/skills i przeprowadza cię przez kilka pytań konfiguracyjnych.

Najpierw pyta o zgodę na instalację potrzebnych pakietów — dla mnie to w porządku. Potem wykonuje kilka czynności i dostajemy długą listę wszystkich skillów, które moglibyśmy zainstalować. Znalazł ich tutaj 38, co jest sporą liczbą. Jeśli przewiniesz w górę i w dół, zobaczysz, że dzielą się na dwie grupy: mattpocock/skills oraz pozostałe skille. Te pierwsze to skille, które oficjalnie zatwierdziłem jako wystarczająco dobre, by były publiczne. Pozostałe to te, z którymi obecnie eksperymentuję i które w przyszłości mogę usunąć.

Polecam, żebyś przeszedł na samą górę listy, zaznaczył wszystko spacją i zatwierdził klawiszem Enter — w ten sposób wybierzesz wszystkie oficjalne skille. Muszę przyznać, że nie jestem zachwycony CLI Vercela, jest trochę toporne, więc być może w przyszłości je zmienię albo nawet dostarczę własne. Na razie to tyle, na ile mnie stać.

Wybór agenta i zakresu instalacji

Dobre jest to, że instalator skonfiguruje twoje skille tak, by działały z dowolnym agentem. Ja używam Claude Code, ale możesz po prostu wybrać te, których potrzebujesz. Domyślnie wspierane są uniwersalne opcje — Cursor, Codex, Claude i tak dalej. Natomiast wszystko, co korzysta ze skillów w stylu Claude, jak Claude Code, musisz skonfigurować samodzielnie. Zatwierdzam więc konfigurację dla Claude Code.

Kolejny wybór to zakres instalacji — czy skille mają być zainstalowane tylko w bieżącym katalogu, czy globalnie. To zależy od konwencji twojego zespołu. Jeśli pracujesz w zespole, uważam, że właściwym wyborem są skille projektowe. Wtedy wszyscy używają tego samego zestawu na każdym projekcie, można wspólnie je rozwijać i wspólnie podejmować decyzje. Ale globalna instalacja jest w porządku, jeśli pracujesz solo nad własnymi rzeczami, tak jak ja. Zatwierdzam więc instalację w katalogu domowym.

Wybieram też symlink jako rekomendowany sposób. Chodzi o to, czy pliki mają być skopiowane do folderu agents obok folderu .claude. Symlink to po prostu ładny, prosty sposób — nawet bym się nad tym nie zastanawiał, po prostu wybierz symlink.

Instalator pokazuje teraz podsumowanie wszystkiego, co instalujemy. Pojawia się jakiś alert na Sockecie dotyczący jednej ze specyfikacji — przyjrzę mu się później. Potwierdzam instalację i wszystkie skille zostają zainstalowane.

(Informacja dodatkowa: Socket to narzędzie skanujące pakiety open source pod kątem zagrożeń bezpieczeństwa; taki alert warto zweryfikować przed produkcyjnym użyciem.)

Lekki narzut kontekstu

Teraz mogę uruchomić Claude wewnątrz repozytorium (albo dowolnego agenta, którego używasz). W zależności od twojego środowiska (harness) skille pokażą się w różny sposób, ale w Claude Code mogę wcisnąć ukośnik i widzę kilka dostępnych skillów: grill me, grilling, wayfinder, grill with docs i mnóstwo innych.

Różnica między moimi skillami a wieloma innymi repozytoriami polega na tym, że moje skille są w większości wywoływane przez użytkownika (user invoked). To znaczy, że gdy sprawdzę kontekst, niewiele z nich wciska się do opisu, a opisy, które mam, są krótkie i precyzyjne. Dzięki temu, mimo że pobraliśmy wszystkie skille, zajmują one tutaj zaledwie 660 tokenów. Są więc bardzo, bardzo lekkie pod względem obciążenia kontekstu.

Konfiguracja: setup mattpocock skills

Mamy skille. Teraz trzeba uruchomić setup mattpocock skills. Moje skille opierają się na pewnej konfiguracji wewnątrz repozytorium i ten skill ustawia ją za ciebie.

Pierwsza rzecz: musisz używać systemu śledzenia zgłoszeń (issue tracker). Będziemy zapisywać specyfikacje i tickety, więc trzeba je gdzieś przechowywać. Masz tu praktycznie nieskończoność wyborów. Możesz użyć GitHuba, lokalnych plików markdown albo dosłownie czegokolwiek. Skill działa tak, że patrzy na twoją lokalną konfigurację — możesz go ustawić pod Jirę, pod Lineara. Robisz to po prostu mówiąc agentowi, pod co chcesz to skonfigurować, a on to załatwi.

Chcę to podkreślić, bo ludzie ciągle mnie pytają: „Jak sprawić, żeby skille działały z Jirą, z Beads, z Linearem?”. One już to robią. Wystarczy uruchomić setup mattpocock i powiedzieć: „Skonfiguruj to z Jirą”. Ja jednak nie chcę Jiry — po prostu ustawiam lokalny markdown.

Następne pytanie dotyczy etykiet triage. To zestaw etykiet, na których opiera się skill, by przekazywać informacje o produkowanych ticketach. Nie jest to tutaj szczególnie ważne, więc przyjmuję domyślne wartości. Jeśli chcesz dowiedzieć się więcej, zajrzyj do dokumentacji skilla triage.

Kolejne pytanie dotyczy dokumentacji domenowej. Moje skille lubią mieć w repozytorium trochę dokumentacji: plik context.md i ADR (Informacja dodatkowa: ADR, Architecture Decision Record, to krótki dokument zapisujący ważną decyzję architektoniczną i jej uzasadnienie). Pytanie brzmi, czy chcesz pojedynczy kontekst, czy wiele kontekstów. Sądzę, że pojedynczy kontekst to właściwy wybór. Wiele kontekstów przyda się, jeśli masz duże monorepo i potrzebujesz w nim wielu oddzielnych, wydzielonych kontekstów (bounded contexts). Ale dla 99% ludzi pojedynczy kontekst w zupełności wystarczy.

Skill zapisał teraz kilka rzeczy. Wewnątrz claude.md dodał kilka linków — do dokumentacji issue trackera, do etykiet triage i do dokumentacji domenowej. Wszystkie znajdują się w docs/agents/domain. Widzimy, że wszystkie zgłoszenia i specyfikacje będą zapisywane w pliku roboczym (scratch file). Tym samym konfiguracja tego repozytorium jest kompletna.

Skill ask Matt — ja jako skill

Możesz się zastanawiać, jak zacząć. Zanim jednak przejdziemy dalej, pokażę ci jeszcze jedną naprawdę fajną rzecz. Jeśli robisz to razem ze mną, możesz teraz zatrzymać film i użyć skilla ask Matt. To zasadniczo ja w formie skilla. Wie wszystko, co trzeba wiedzieć o repozytorium skillów i o tym, co powinieneś zrobić najpierw.

Możemy powiedzieć: „Ask Matt, jak zacząć? Chcę tu wprowadzić zmiany w kodzie. Jakiego głównego przepływu powinienem użyć?”. Zatwierdzam i patrzę, co odpowie. (Informacja dodatkowa: autor wspomina, że jako transkrypcji mowy na tekst używa narzędzia Whisper Flow.)

Odpowiada: główny przepływ to „od pomysłu do wdrożenia” (idea to ship). Skoro masz bazę kodu, zacznij od góry głównego przepływu i przejdź w dół w jednym, nieprzerwanym oknie kontekstu. Mocno podkreśla to, jak wykorzystywać swoje sesje. Wierzę, że świadomość okna kontekstu, którego używasz, i liczby zużywanych tokenów jest kluczowa dla dobrego korzystania z AI.

Główny przepływ krok po kroku

Odpowiedź mówi: zacznij od grill with docs. Ten skill przepytuje cię, żeby wyostrzyć pomysł, a ponieważ jesteś w repozytorium, jest stanowy (stateful) — zapisuje to, czego się dowiaduje, w context.md i w ADR-ach. To tu zamieniasz „chcę zmienić X” w konkretny, dobrze uzasadniony plan.

Kluczowe pytanie: czy da się rozstrzygnąć wszystkie otwarte kwestie samą rozmową? Jeśli jakieś pytanie wymaga odpowiedzi, którą trzeba uruchomić, możesz użyć skilla prototype (Informacja dodatkowa: autor poświęcił mu osobny film), wchodząc i wychodząc z niego przez handoff. Jeśli nie — pomijasz ten krok.

Po zakończeniu wywiadu w grill with docs możesz albo przejść prosto do skilla implement, albo — jeśli praca wymaga wielu sesji — przejść do to spec i to tickets.

Uporządkujmy to. Domyślny przepływ wygląda następująco. Zaczynasz od grill with docs, który przepytuje cię na podstawie pomysłu, który chcesz zrealizować.

grill with docs w praktyce

Wychodzę z ask Matt. Mówię grill with docs i uruchamiam to pomysłem: „Chciałbym usunąć większość wewnętrznego oprzyrządowania z tego CLI, żeby zostało tylko to, co publiczne. Jest tu dużo dopracowanego kodu, ale chcę zejść z tym repozytorium o poziom niżej”.

Naprawdę może być tak ogólnie. Nie musisz robić tu zbyt wiele. To grill with docs wykona ciężką pracę, zadając serię pytań uzupełniających. Właśnie eksploruje kod. Przy okazji: używam Claude Code, modelu Opus 4.8 na średnim poziomie wysiłku (medium effort), ale naprawdę nie musisz mieć takiej samej konfiguracji jak ja. Z tych skillów korzysta mnóstwo różnych osób, na różnych środowiskach, modelach i poziomach wysiłku.

Widzimy, że już zadał pierwsze pytanie. Ma jasną mapę całego repozytorium. Przygląda się przestrzeni nazw internal z jedenastoma podkomendami. Tak wygląda sesja przepytywania (grilling): odpowiadasz na pytania, aż ty i agent poczujecie, że osiągnęliście wspólne zrozumienie.

Nie trwało to zbyt długo — skończyło się na sześciu pytaniach. To niewiele jak na sesję grillowania; zwykle moje kończą się na jakichś dwudziestu pytaniach, w zależności od rozmiaru zadania. Mamy porządny plan: usuniemy 10 plików komend, usuniemy trzy testy, przełączymy współdzielone moduły. Wszystko, co zrobiłem, to odpowiadanie na pytania, aż powiedział: „Dobrze, przeszliśmy całe drzewo, osiągnęliśmy wspólne zrozumienie, przedstawię plan”.

Zwróć uwagę, że nie używałem tu trybu planowania (plan mode). Byłem w trybie automatycznym (auto mode) w Claude Code, czyli w zasadzie trybie domyślnym.

Rozwidlenie: implement albo to spec + to tickets

Teraz masz rozwidlenie. Jeśli sądzisz, że praca będzie na tyle duża, że wymaga wielu sesji agenta, możesz pominąć kroki drugi i trzeci i przejść prosto do implement — po prostu mówisz /implement this. W tym przypadku uważam, że tak właśnie powinniśmy zrobić.

Mam jeszcze około 100 tysięcy tokenów budżetu. Myślę o swoim oknie kontekstu tak, że zaczyna się kończyć albo znacząco głupieć w okolicach 140 tysięcy tokenów. Traktuję to jako „strefę inteligencji” modelu (smart zone). Jeśli przekroczysz 140 tysięcy, dochodzi do degradacji uwagi (attention degradation) — model głupieje, zaczyna dziwnie halucynować. Mam więc jakieś 100 tysięcy tokenów budżetu na usunięcie 10 komend. To wydaje się banalnie proste, na pewno damy radę.

Normalnie po prostu powiedziałbym implement, zostawił to, pozwolił temu działać i praca zostałaby ukończona. Jednak żeby pokazać ci wszystko, udam, że ta praca zajmie więcej niż jedną sesję — że skończył mi się kontekst albo skończyła się strefa inteligencji w bieżącym oknie i muszę rozłożyć to na wiele okien kontekstu. Wywołam więc to spec.

to spec — kompresja rozmowy do dokumentu

Zamiast pisać implement this, mówię to spec. To weźmie całą dyskusję, którą odbyłem — te 46,1 tysiąca tokenów — i skompresuje ją do dokumentu, którego użyjemy później. Tu wkracza nasz issue tracker. Używamy lokalnych plików markdown, więc spec zostanie zapisany do lokalnego katalogu.

Ten spec to cel, do którego zmierzamy przez cały ten wielobiletowy sprint. Innymi słowy: to opis tego, co ma powstać na końcu i jak ma to wyglądać. Tickety będą natomiast opisem tego, jak tam dojdziemy.

Spec został zapisany i opublikowany w issue trackerze. Jest bardzo ładny i szczegółowy: ma opis problemu, rozwiązanie, zestaw historyjek użytkownika (user stories), decyzje implementacyjne, decyzje dotyczące testów, mnóstwo rzeczy. To będzie bardzo przydatne, bo na końcu będziemy mogli porównać implementację ze specem i upewnić się, że wszystko się zgadza.

to tickets — plan wdrożenia w porcjach

Teraz, w tej samej sesji (nie zmieniam sesji), mówię to tickets. To zamieni spec w plan wdrożenia. Każdy z tych ticketów ma mieć rozmiar dokładnie jednego okna kontekstu, jednej strefy inteligencji.

Widzimy, że dał nam trzy tickety, czyli trzy plasterki (slices). Uważam, że te trzy plasterki to trochę za dużo — sądzę, że da się to zrobić w jednym. Mówię więc, żeby zrobił to w jednym plasterku. Zapisuje ticket do tickets.md.

To akurat kiepski przykład, bo trochę kopiuje to, co jest już w naszym dokumencie wymagań produktowych (PRD). Pokażę ci więc prawdziwy przykład. Oto spec, który wdrożyłem kilka dni temu, żeby usunąć sporo rzeczy z pewnego repozytorium — ostatnio jestem na fali usuwania. Widać, że ten spec ma pod sobą 11 podzgłoszeń, czyli 11 ticketów. To bardzo szczegółowy spec, a każdy ticket to sesja jednego okna kontekstu. Jeśli w niego wejdziemy, jest całkiem krótki — większość kryteriów akceptacji jest już w głównym specie, więc ticket mówi dosłownie tylko, co budujesz w tej sesji. To sesja pierwsza, potem druga, potem trzecia. Widać, jak to rozbija ogromny kawał pracy na łatwe do ogarnięcia kawałki, które agent może kolejno wykonać.

Implementacja ticketów

W naszym przypadku został jednak jeden zarządzalny kawałek. Czyszczę kontekst (clear). Mamy teraz wszystko, czego potrzeba, żeby uruchomić agentów do rozwiązania problemu. Czyszczę kontekst, po czym mówię implement this @tickets.

Ponieważ mamy spec, który decyduje, dokąd zmierzamy, oraz tickety, które decydują, jak tam dotrzemy, agent ma wszystko, czego potrzebuje, i jesteśmy gotowi do implementacji.

Kiedy robisz to ręcznie, zamysł jest taki, że wdrażasz każdy ticket jeden po drugim. Nie mówisz „zrób wszystkie tickety naraz” — mówisz: implementujemy jeden, sprawdzamy, czy trafiliśmy w strefę inteligencji. Jeśli nie, może uda się wcisnąć jeszcze jeden ticket, ale zwykle radzę czyścić kontekst między każdym ticketem. Gdy skończysz całą implementację i masz wszystko wdrożone, przechodzisz do code review i robisz końcowe sprawdzenie względem speca.

Widzimy, że to naprawdę był bardzo mały kawałek pracy — zaledwie 42,7 tysiąca tokenów.

Automatyczne code review w podagentach

W ramach implement uruchamiany jest teraz code review. Skrypt implement wykonuje sprawdzenie typów (type check), uruchamia build, robi jeszcze więcej weryfikacji — sprawdza wewnętrzną pomoc AI Hero, pokazuje tylko edytowane commity — i wczytuje skill code review.

To review opiera się na dwóch osiach. Po pierwsze, porównuje wykonaną pracę z oryginalnym specem. To bardzo przydatne, gdy zrobiłeś ogromny kawał pracy, a agent mógł o czymś zapomnieć w ticketach albo tickety były niedoprecyzowane. Końcowy przebieg pozwala dopiąć wszystko na ostatni guzik. Po drugie, sprawdza pracę względem dokumentacji standardów, którą masz we własnym repozytorium. W tym repozytorium nie mamy nigdzie udokumentowanych standardów kodowania, ale jeśli skill żadnych nie wykryje, korzysta z klasyków — z reguł w stylu Martina Fowlera. Szuka „code smells”, próbuje wychwycić złe rzeczy.

(Informacja dodatkowa: „code smells” to symptomy w kodzie sugerujące głębszy problem projektowy; Martin Fowler to autor klasycznych publikacji o refaktoryzacji.)

Robienie tego w podagentach (sub agents) jest naprawdę ważne. Gdybyś zrobił to w głównym agencie, ten agent już napisał ten kod — a agenty często są bardzo słabe w edytowaniu czy poprawianiu kodu, który same przed chwilą napisały. Skoro go napisały, myślą sobie: „W porządku, to jest świetne, jest dobrze”. Natomiast jeśli powołasz osobne agenty, będą mieć czyste okno kontekstu i wykonają recenzję znacznie lepiej.

Widzimy, że oba wróciły. Skontrolowały każde kryterium akceptacji względem speca, sprawdziły wszystko względem standardów — i jest dobrze. Zmiana została zacommitowana do bieżącej gałęzi. Pięknie.

Podsumowanie

I to jest nasz kompletny przepływ. Zgraliśmy się (aligned), zanim zaczęliśmy. Stworzyliśmy spec i tickety, żeby praca zadziałała przez wiele sesji. Następnie ją zaimplementowaliśmy, a sam skill implement wykorzystał code review. To główny przepływ, przez który przechodzi cała moja praca.

Rzeczy, których nie ma w głównym przepływie, to te, z którymi eksperymentuję i które ulepszam — wciąż próbuję sprawić, by ta pętla była szybsza, lepsza i łatwiejsza w obsłudze. Jeśli cię to interesuje, zajrzyj do mojego newslettera poświęconego tym skillom. Ten kanał YouTube to świetne miejsce, by lepiej zrozumieć skille, ale naprawdę dobre rzeczy są w newsletterze — tam trafiają aktualizacje tego samego dnia, gdy wypuszczam nowe skille i zmiany, o których trzeba wiedzieć.

Dziękuję, że oglądaliście. Mam nadzieję, że ten tutorial dał ci obraz tego, jak skonfigurować skille i jak ma wyglądać główny przepływ. Dzięki za uwagę, udanego skillowania i do zobaczenia wkrótce.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Instaluj cały oficjalny zestaw jednym poleceniem

Na czym polega: Skille instaluje się przez npx skills@latest add mattpocock/skills (wymaga Node.js). Instalator znajduje 38 skillów podzielonych na oficjalne (zatwierdzone) i eksperymentalne.

Jak stosować: Zaznacz spacją i zainstaluj całą grupę oficjalną. Działa identycznie na nowym i istniejącym projekcie. Wybierz symlink jako metodę instalacji — to najprostsza opcja.

Na co uważać: Skille eksperymentalne mogą zniknąć w przyszłości, więc nie opieraj na nich stałego przepływu. Instalator (CLI Vercela) bywa toporny w nawigacji, a przy instalacji może pojawić się alert bezpieczeństwa (Socket) — zweryfikuj go przed produkcyjnym użyciem.

2.Wybierz zakres instalacji zgodnie z kontekstem pracy

Na czym polega: Skille można zainstalować projektowo (w danym repozytorium) albo globalnie (w katalogu domowym).

Jak stosować: W zespole wybieraj skille projektowe — wszyscy używają tego samego zestawu i wspólnie go rozwijają. Solo możesz spokojnie instalować globalnie.

Na co uważać: Globalna instalacja oznacza, że zmiany w skillach dotkną wszystkich twoich projektów naraz; w zespole brak wersji projektowej rozjeżdża konwencje między ludźmi.

3.„User invoked” skille prawie nie obciążają kontekstu

Na czym polega: Skille Pococka są w większości wywoływane ręcznie, a nie automatycznie wstrzykiwane do opisu. Cały zestaw zajmuje ok. 660 tokenów.

Jak stosować: Nie bój się zainstalować wszystkich — narzut jest minimalny. Wywołuj konkretny skill ukośnikiem, gdy jest potrzebny.

Na co uważać: To zaleta akurat tego repozytorium; inne zestawy skillów potrafią mocno „przeciekać” do kontekstu. Zawsze sprawdzaj realne zużycie tokenów komendą kontekstu.

4.Skonfiguruj repozytorium przez setup mattpocock skills

Na czym polega: Skill konfiguruje issue tracker, etykiety triage i dokumentację domenową, dodając linki w claude.md oraz katalog docs/agents/domain.

Jak stosować: Wybierz issue tracker (lokalny markdown, GitHub, Jira, Linear itd.) — wystarczy powiedzieć agentowi, pod co ma to ustawić. Dla większości projektów wybieraj pojedynczy kontekst domenowy.

Na co uważać: Wiele kontekstów ma sens tylko w dużych monorepo z wydzielonymi domenami; niepotrzebne komplikuje konfigurację. Domyślne etykiety triage są w porządku na start.

5.Zacznij od ask Matt, jeśli nie znasz przepływu

Na czym polega: Skill ask Matt to autor zamknięty w formie asystenta — zna repozytorium i zalecany przepływ, i podpowiada, od czego zacząć.

Jak stosować: Zapytaj go o główny przepływ dla twojego zadania, zanim zaczniesz. Traktuj jego odpowiedź jako interaktywny tutorial.

Na co uważać: To narzędzie orientacyjne, nie wykonawcze — sam plan i implementację realizują dalsze skille. Odpowiedzi bywają utrzymane w typowym „stylu LLM”.

6.Główny przepływ: idź z góry na dół w jednym oknie kontekstu

Na czym polega: Przepływ „od pomysłu do wdrożenia” to: grill with docs → (opcjonalnie prototype) → implement albo to spec + to tickets → implementacja → code review.

Jak stosować: Przy istniejącej bazie kodu przechodź kolejne kroki w jednym, nieprzerwanym oknie kontekstu, świadomie zarządzając budżetem tokenów.

Na co uważać: Zaawansowane i nowe skille celowo są poza tym przepływem — nie mieszaj ich, dopóki nie opanujesz głównej pętli.

7.grill with docs zamienia mglisty pomysł w konkretny plan

Na czym polega: Skill przepytuje cię serią pytań (często ok. 20), eksplorując repozytorium, aż powstanie plan i wspólne zrozumienie.

Jak stosować: Rzuć nawet bardzo ogólny pomysł — skill wykona ciężką pracę. Odpowiadaj na pytania, aż agent uzna, że „przeszedł całe drzewo”. Nie musisz używać trybu planowania; wystarczy tryb automatyczny.

Na co uważać: Krótka sesja (np. 6 pytań) przy dużym zadaniu może oznaczać niepełne zrozumienie — dopytuj, jeśli czujesz, że coś pominięto. Skill jest stanowy, więc zapisuje ustalenia w context.md i ADR-ach.

8.Rozdziel decyzję: implement od razu vs. to spec + to tickets

Na czym polega: Po grillowaniu wybierasz: jeśli praca zmieści się w jednej sesji — od razu implement; jeśli nie — to spec (skompresowany cel) i to tickets (plan w porcjach wielkości jednego okna kontekstu).

Jak stosować: Oceń, czy zmieścisz się w budżecie tokenów jednej sesji. Przy dużych zadaniach twórz spec i tickety, by przetrwać wiele okien kontekstu. Możesz nadpisać sugestię agenta (np. „zrób to w jednym plasterku zamiast trzech”).

Na co uważać: Przy małym zadaniu spec potrafi zduplikować treść PRD — nie zawsze warto go tworzyć. Spec to opis stanu końcowego, tickety to droga do niego; nie myl tych ról.

9.Pilnuj „strefy inteligencji” — ok. 140 tys. tokenów

Na czym polega: Autor traktuje ~140 tys. tokenów jako granicę, powyżej której model traci uwagę, głupieje i halucynuje.

Jak stosować: Planuj każdy ticket tak, by mieścił się w jednym oknie/strefie. Czyść kontekst (clear) między ticketami. Zostawiaj sobie budżet z zapasem (np. 100 tys. tokenów na proste zadanie).

Na co uważać: Konkretna granica zależy od modelu i harnessu — 140 tys. to heurystyka Pococka na jego konfiguracji (Opus 4.8, medium), a nie twarda liczba dla każdego setupu.

10.Zawsze rób code review w osobnych podagentach

Na czym polega: Skill implement uruchamia na końcu code review na dwóch osiach: zgodność ze specem oraz zgodność ze standardami kodu (a przy ich braku — klasyki w stylu Martina Fowlera). Robi to w podagentach.

Jak stosować: Pozwól, by review działało w świeżym oknie kontekstu podagenta — recenzent bez pamięci pisania kodu ocenia go rzetelniej. Wykorzystaj oś „względem speca” do wyłapania rzeczy pominiętych w ticketach.

Na co uważać: Nie recenzuj kodu tym samym agentem, który go napisał — agenty zwykle akceptują własną pracę bezkrytycznie. Jeśli chcesz sensownej osi standardów, udokumentuj własne standardy w repozytorium; inaczej dostaniesz tylko ogólne reguły.