O czym jest ten film
- Autor od ponad roku nie napisał samodzielnie ani jednej linijki kodu — cały proces prowadzą agenci kodujący sterowani zestawem skilli.
- Skill dla agenta kodującego to po prostu wielokrotnego użytku prompt: workflow, który prowadzi agenta przez określony proces.
- Cała biblioteka skilli jest udostępniona jako plugin do marketplace’u Claude Code; instalacja to dwie komendy.
- Filozofia zestawu: minimalizm i zasada „wybierz, co ci pasuje” — w odróżnieniu od frameworków typu GitHub Spec Kit czy Gastown, które narzucają cały cykl wytwórczy.
- Proces składa się z dwóch pętli: zewnętrznej (planowanie wysokopoziomowe) i wewnętrznej (pisanie i walidacja kodu).
- Pętla zewnętrzna to trzy skille: PRD (co i dlaczego), spec architektoniczny (jak) oraz krojenie epiku na tickety.
- Pętla wewnętrzna to priming kontekstu, planowanie ticketu, implementacja i walidacja — powtarzane dla każdego ticketu.
- Kluczowa teza filmu: strategia walidacji zdefiniowana przed napisaniem kodu jest najważniejszą częścią planu.
- Autor przywołuje Borisa Cherny’ego, twórcę Claude Code: opisz zadanie, bariery bezpieczeństwa i kryteria wyjścia wraz z walidacją, a potem „pozwól modelowi gotować”.
- Każdy skill można łatwo dostosować — autor nigdy nie edytuje ich ręcznie, tylko zleca zmiany samemu agentowi.
Redakcyjne tłumaczenie
Rok bez pisania kodu
Od ponad roku nie napisałem samodzielnie ani jednej linijki kodu. Wypowiedzenie tego na głos wciąż wydaje mi się dziwne, bo całe życie byłem inżynierem. Kiedy zakładałem kanał na YouTubie, pokazywałem linijka po linijce, jak budować agentów AI. Dziś w każdym elemencie procesu wytwórczego opieram się na asystentach kodujących.
System, który sobie wypracowałem i który świetnie działa od pół roku, jest w gruncie rzeczy prosty, ale bardzo skuteczny. To po prostu zbiór skilli. Skill dla agenta kodującego — Claude Code czy Codex — to nic innego jak prompt wielokrotnego użytku: workflow, który prowadzi agenta przez określony proces. Mam więc kolekcję takich procesów spakowanych jako skille i właśnie ją udostępniam.
W tym materiale pokażę wszystkie skille, z których korzystam codziennie, i to, jak można je włączyć do własnej pracy. Zakładam bowiem, że masz już swój zestaw skilli i własny workflow pracy z AI — nie oczekuję, że to porzucisz i przejdziesz na moje. Jeśli wybierzesz tylko kilka dobrych albo zaczerpniesz same pomysły, to w zupełności wystarczy. Dziś jest to zresztą banalnie proste: wskazujesz agentowi kodującemu repozytorium i mówisz: „podoba mi się to, weź ten skill” — a on wpina go w to, co już masz.
Minimalizm zamiast gotowego frameworka
Najważniejsze, co trzeba zrozumieć w tych skillach: są minimalistyczne i działają na zasadzie plug and play. Nie musisz adaptować wszystkich. Możesz wziąć kilka albo nawet tylko kilka idei.
To odróżnia je od innych frameworków do agentowego kodowania, takich jak GitHub Spec Kit czy Gastown. To bardzo dobre projekty, nie chcę ich umniejszać, ale żeby z nich skorzystać, musisz właściwie przyjąć cały ich proces — mają zdefiniowany kompletny cykl wytwarzania oprogramowania. Zwykle nie sprawdza się to najlepiej, chyba że zaczynasz zupełnie od zera. Ja zakładam, że masz już jakiś proces, więc daję ci bibliotekę, z której wybierasz to, czego potrzebujesz. Każdy z tych skilli da się też bardzo łatwo dostosować do własnego repozytorium i stylu pracy — o tym też będzie mowa. A jeśli naprawdę startujesz od zera, możesz spokojnie wziąć wszystko: to kompletna lista skilli, których używam w pełnym cyklu wytwórczym.
W dalszej części omówię też podejście „validation first” — jak pozwolić modelowi pracować samodzielnie, a mimo to mieć zaufanie do jego wyników. To szczerze najważniejsza rzecz w całym procesie, który tu przedstawiam.
Instalacja
Zacznijmy od tego, jak łatwo zainstalować te skille we własnym projekcie. Wszystko opisuje README w repozytorium. Większość z was korzysta z Claude Code, więc udostępniam to jako plugin do marketplace’u Claude Code.
Kopiujesz pierwszą komendę, wklejasz ją w działającym Claude Code i dodajesz mój marketplace. Potem drugą komendą wykonujesz właściwą instalację. Do wyboru jest kilka opcji — zwykle polecam pierwszą, czyli instalację skilli globalnie, dostępnych w każdym repozytorium. Możesz też zainstalować je tylko dla bieżącego repozytorium albo dla współpracowników, jeśli pracujesz w zespole. Całość zajmuje kilka sekund.
Po instalacji polecenie odpowiedzialne za wtyczki pokazuje wszystkie zainstalowane pluginy, w tym moją kolekcję skilli. Widać je również po wpisaniu /skills — wszystko z repozytorium jest natychmiast dostępne. Kiedy wpiszę na przykład /piv, zobaczę wszystkie komendy związane z pętlami, które za chwilę omówię szczegółowo.
(Informacja dodatkowa: piv to prefiks nazw skilli autora, obejmujący kroki pętli wewnętrznej — prime, implement, validate i pokrewne.)
Jeśli używasz innego agenta kodującego niż Claude Code, instalacja jest niemal równie prosta. Zabrzmi to banalnie, ale wystarczy skopiować adres repozytorium, podać go swojemu agentowi i powiedzieć: „to jest kolekcja skilli Claude Code, chcę, żebyś zainstalował ją w tym repozytorium dla tego agenta” — Codex, Pi, GitHub Copilot. Zadziała. Zajmie kilka minut dłużej, ale efekt jest ten sam.
Dwie pętle
Skoro masz już skille zainstalowane, porozmawiajmy o tym, w co się właśnie wpakowałeś. Chcę pokazać cały proces wytwórczy i to, jak każdy skill się w niego wpisuje. Zostaniemy na dość wysokim poziomie — gdybym wchodził w szczegóły każdego skilla i faktycznie je uruchamiał, materiał byłby znacznie dłuższy. Dajcie znać w komentarzach, którą część procesu omówić szerzej w osobnym filmie. Właściwie mógłbym nakręcić osobny materiał o każdym skillu — nie dlatego, że są skomplikowane, ale dlatego, że jest mnóstwo dobrych praktyk pozwalających wycisnąć z nich maksimum.
Mój workflow pracy z AI składa się z dwóch pętli. To banalnie prosty schemat, dzięki któremu łatwiej mi zbudować cokolwiek.
Pętla zewnętrzna to planowanie na najwyższym poziomie: budowanie PRD i dokumentów specyfikacji.
Pętla wewnętrzna to miejsce, w którym powstaje kod. Bierzemy pojedynczy ticket, planujemy z agentem pracę, każemy mu napisać kod, a następnie walidujemy go — my i agent równolegle.
Pętla zewnętrzna: PRD, czyli co i dlaczego
Zacznijmy od pętli zewnętrznej, bo od niej rozpoczyna się każda praca. Wykonujesz ją rzadziej — raz na epik. W przypadku projektu od zera zarysowujesz tu MVP: co trzeba zbudować, żeby dojść do pierwszego proof of concept. W projekcie istniejącym definiujesz większą funkcję lub zestaw funkcji na kolejny sprint — kolejny etap ewolucji projektu.
Pierwszy skill to PRD. Dokument wymagań produktowych definiuje co i dlaczego dla najbliższego zakresu prac. Zakładasz kapelusz menedżera produktu i przy pomocy agenta ustalasz, co dokładnie budujemy i jaki problem naprawdę rozwiązujemy. Chodzi o to, żeby cała reszta procesu budowała coś, o czym wiemy, że warto to zbudować.
Pokażę, jak taki skill wygląda w repozytorium. W folderze ze skillami mamy plan-create-prd. Nie będę wchodził w szczegóły każdego skilla, ale ten jeden chcę omówić, żebyś zobaczył, jak zwykle działają.
Większość moich skilli przyjmuje argument. Kiedy w Claude Code wpiszę /plan-prd i wcisnę tabulator, zobaczę podpowiedzi argumentów — czyli informację, co jest wejściem dla tego skilla. Tutaj podajemy pomysł na produkt. Może być bardzo ogólnikowy, na przykład „chcę zbudować aplikację do śledzenia finansów”. Nie musisz być precyzyjny, bo skill przeprowadzi z tobą wywiad. Zada mnóstwo pytań, żeby wyciągnąć z ciebie rzeczy, które muszą znaleźć się w PRD: docelowego użytkownika, hipotezę uzasadniającą, że warto to budować — wszystko, co zwykle znajduje się w takim dokumencie. Skill uczy agenta dwóch rzeczy: co ma z ciebie wydobyć i jak to sformatować w dokumencie.
Oto przykładowy PRD wygenerowany tym skillem. Mamy opis problemu, dowody, wszystkie sekcje, o które prosimy agenta po zakończeniu wywiadu.
Rozdzielenie „co” od „jak”
Rzecz istotna: w PRD w ogóle nie opisujemy, jak zbudujemy nowe funkcje w kodzie. Trzymamy się tego, co i dlaczego, bo do „jak” mamy osobny skill tworzący specyfikację. To dokument architektoniczny opisujący faktyczną implementację.
Ten podział jest bardzo ważny, bo to naprawdę dwie osobne rozmowy z agentem kodującym. Najpierw ustalasz co i dlaczego. Potem planujesz architekturę, wchodzisz w implementację techniczną, w to „jak”. Dlatego zalecam uruchamianie tych skilli w oddzielnych konwersacjach.
Skilla od specyfikacji nie będę osobno pokazywał, bo proces jest bardzo podobny: agent przeprowadza z tobą wywiad, a następnie tworzy dokument architektury według szablonu. Masz wtedy drugi artefakt, który wchodzi na wejście do tworzenia ticketów.
Krojenie epiku na tickety
Każda rozmowa produkuje dokument zasilający ostatni krok pętli zewnętrznej. Mamy zaplanowany pełny zakres prac dla najbliższego epiku, więc teraz trzeba go podzielić na kęsy — takie, żeby nie przytłoczyć agenta zbyt dużym zadaniem na jedną rozmowę. Odpowiedzialnością tego skilla jest wzięcie dwóch wcześniejszych wyników, zmapowanie zależności i ustalenie, co da się robić równolegle. Krótko mówiąc: przygotowanie sceny dla wszystkich pętli wewnętrznych.
Skill nazywa się piv slice epic — bierzemy epik i kroimy go na drobne kawałki pracy. Przyjmuje dwa argumenty: dokument specyfikacji (architektury) i PRD. Agent zna więc co, dlaczego i jak, i może zmapować wszystkie zależności.
Można tu również wskazać strony Confluence. Wiele firm, z którymi pracuję, nie trzyma PRD i specyfikacji lokalnie, tylko właśnie w Confluence. Chciałem, żeby ten skill był naprawdę elastyczny: nie ma znaczenia, czy dokumenty są w Confluence, czy w plikach markdown — skill je pobierze, o ile ma serwer MCP sięgający tam, gdzie je przechowujesz.
(Informacja dodatkowa: MCP, Model Context Protocol, to standard podłączania agentów do zewnętrznych źródeł danych i narzędzi.)
Podajesz więc dwie ścieżki lub adresy URL, a skill tworzy wszystkie tickety do zaimplementowania w pętli wewnętrznej.
Pętla wewnętrzna: priming kontekstu
Najwięcej czasu spędzisz właśnie w pętli wewnętrznej, bo pętlę zewnętrzną wykonujesz raz na epik. Tamte skille są bardzo ważne, ale tych będziesz używać nieporównanie częściej — przy większym epiku możesz mieć nawet kilkadziesiąt ticketów. Dla każdego z nich przejdziesz proces planowania, implementacji i walidacji.
Skill do krojenia zwraca zestaw pojedynczych zadań. Mogą to być dokumenty markdown, issues na GitHubie, tickety w Jirze — nie ma to znaczenia. Istotne jest, że każdy ticket jest wejściem do całej pętli wewnętrznej. Wskazujesz agentowi ten ticket i mówisz: to chcemy zaimplementować, przeanalizuj repozytorium i pomóż mi zaplanować tę konkretną implementację.
Zwykle zaczynam od skilla primującego — prime codebase. Mam kilka wariantów, jeśli chcesz zrozumieć konkretną część repozytorium, na przykład pracujesz wyłącznie nad frontendem. prime codebase jest tym ogólniejszym: przeszukuje repozytorium, potencjalnie przez pryzmat konkretnego zadania, które mu podasz. Jeśli dasz mu ticket z Jiry albo plik markdown z opisem kolejnego kawałka pracy, przeanalizuje kod pod kątem tego, co chcesz zbudować.
Rzecz kluczowa: agent kodujący ma wprawdzie swoje reguły globalne, ale poza tym na starcie rozmowy jest raczej głupi. Robimy więc po prostu porządne ładowanie kontekstu.
Planowanie ticketu
Po skillu primującym przechodzimy do skilla planującego. Ważne: robimy to w tej samej rozmowie, w której wykonaliśmy priming. Uruchamiasz prime codebase, a po eksploracji repozytorium używasz tego jako kontekstu i wchodzisz w piv plan implementation. Możesz tu również wskazać ticket, nad którym pracujesz, jeśli nie podałeś go już na etapie primingu — to argument opcjonalny.
Proces jest bardzo podobny do tworzenia PRD czy specyfikacji. Agent zaczyna od wywiadu, zadaje mnóstwo pytań, żeby upewnić się, że jesteście co do wszystkiego zgodni. Najgroźniejsze jest bowiem to, że agent zacznie przyjmować własne założenia co do tego, co chcesz zbudować albo jak. Modele językowe potrafią z pełnym przekonaniem przyjąć fatalne założenia. Dlatego potrzebujemy pełnego workflow, w którym agent najpierw dużo pyta, potem prowadzi solidny research w kodzie, a dopiero na końcu tworzy plik z planem, który pójdzie do implementacji.
I tak, warto poświęcić dużo czasu na początku. Wiem, że nie napisaliśmy jeszcze ani jednej linijki kodu, ale tyle właśnie trzeba, żeby uzyskiwać powtarzalne wyniki z asystentami kodującymi. Upewnij się, że jesteście zgodni. Stwórz plan. Dopiero potem implementuj.
Anatomia dokumentu planu
Format planu jest zawsze taki sam — o ile nie zmodyfikujesz skilla, o czym będzie na końcu. Szablon jest jedną z rzeczy, które definiujemy w skillu planującym: zawsze chcemy mieć opis funkcji i historyjkę użytkownika. To właśnie czyni te skille niezawodnymi i powtarzalnymi — każdy skill, który produkuje dokument, ma szablon do wypełnienia przez agenta.
Mamy więc opis problemu, opis rozwiązania, zakres wyłączony i cele negatywne. Możesz zmienić każdą z tych sekcji, ale u mnie ten układ świetnie sprawdza się jako wskazówka dla agenta przed implementacją.
Ponieważ wchodzimy teraz w szczegóły konkretnego zadania, wskazujemy też konkretne rzeczy w repozytorium: kontekst do uwzględnienia, pliki, których trzeba dotknąć, dokumentację do przeczytania. Mamy nawet plan implementacji zadanie po zadaniu, z listą plików do utworzenia i edycji.
Validation first: najważniejsza część planu
Najważniejszą częścią całego dokumentu planu jest strategia testowania. Chcę poświęcić jej kilka minut, bo to ona naprawdę wyróżnia moje podejście: agent definiuje strategię walidacji, zanim powstanie choćby linijka kodu.
Ta sekcja jest dość obszerna. Mamy testy jednostkowe, testy integracyjne, przypadki brzegowe do przetestowania. Mamy konkretne komendy, które agent uruchomi: lintowanie, sprawdzanie typów, testy jednostkowe, testy integracyjne, a także walidację manualną. Jest też opis tego, jak przeprowadzić aplikację przez ścieżkę użytkownika, korzystając z narzędzi do automatyzacji przeglądarki.
Nazywam to programowaniem sterowanym testami, ale dla agentów. Jeśli jesteś inżynierem, wiesz, o co chodzi. Jeśli nie — istota jest taka, że zanim napiszemy pierwszą linijkę kodu, planujemy, jak ten kod przetestować.
To ważne, bo oznacza, że to, co dostajemy od agenta, nigdy nie jest jego pierwszym podejściem. Agent potrafi napisać i uruchomić wszystkie testy zdefiniowane w planie, więc iteruje nad własną pracą. Musimy interweniować znacznie rzadziej i dostajemy dużo mniej „AI-owego szlamu”, skoro model sam sprawdza i poprawia swoje wyniki.
Dla każdej rzeczy, którą budujemy w danym tickecie — endpointu, obsługi błędów — ustalamy w planie, jak dokładnie zostanie przetestowana. Dlatego zachęcam, żeby po wygenerowaniu planu przejrzeć go samodzielnie. Upewnij się, że walidacja wygląda sensownie i że dokumentacja, do której agent sięgnie, jest właściwa. Jeśli plan jest dobry, jesteś bardzo precyzyjny co do celu: mówisz, jak wygląda „zrobione” i jak można to zweryfikować.
Ta strategia staje się coraz potężniejsza w miarę, jak modele stają się coraz zdolniejsze. Boris Cherny, twórca Claude Code, powiedział w zeszłym miesiącu: „Chcesz opisać zadanie, chcesz opisać bariery bezpieczeństwa i kryteria wyjścia, w tym walidację, a potem po prostu pozwolić modelowi gotować i wrócić za chwilę”. Uwielbiam to. Po prostu pozwól modelowi gotować.
Mantra brzmi więc: bądź precyzyjny co do celu — czego dokładnie oczekujesz, jaka jest strategia walidacji — a drogę do niego pozwól zbudować agentowi. Nie musisz być precyzyjny co do środków. Dlatego twierdzę, że strategia walidacji jest dziś najważniejszą częścią planów: dopóki agent ma narzędzia i instrukcje, żeby testować i poprawiać własną pracę, dojdzie do celu, bo sam buduje drogę. Pisze kod i potrafi się dostosować, gdy coś pójdzie nie tak, ponieważ na bieżąco sprawdza swoje wyniki.
Podoba mi się to również dlatego, że pomaga zrozumieć, gdzie w pętli wewnętrznej faktycznie inwestować własny czas. Dokumenty planów bywają przytłaczające — cały ten kontekst, listy plików do utworzenia i edycji. Nie przejmuj się tym nadmiernie. Oczywiście warto zweryfikować cały plan, ale daję ci tu przyzwolenie, żebyś skupił się głównie na strategii walidacji i na upewnieniu się, że agent naprawdę rozumie, co chcesz zbudować.
Implementacja w nowej rozmowie
Żeby domknąć pętlę wewnętrzną: bierzemy właśnie utworzony dokument planu i przekazujemy go do skilla implementującego. Robimy to w zupełnie nowej rozmowie. Dzielimy pracę tak samo, jak przy PRD i specyfikacji, bo implementacja jest czymś zupełnie odrębnym od planowania. Twoja rozmowa planistyczna jest już zapewne bardzo długa, a chcemy uniknąć gnicia kontekstu — duże modele językowe mają swoją „strefę ogłupienia”, w której toną w nadmiarze informacji, dokładnie jak ludzie.
(Informacja dodatkowa: „context rot” to obserwowane pogorszenie jakości odpowiedzi modelu, gdy okno kontekstu wypełnia się długą, częściowo nieistotną historią rozmowy.)
Ponieważ dokument planu jest w zasadzie jedynym kontekstem potrzebnym do napisania kodu, możemy wejść w skilla implementującego w nowej rozmowie. Wpisuję /piv, a jedynym argumentem jest ścieżka do planu. Klikam prawym przyciskiem w VS Code, kopiuję pełną ścieżkę, wklejam — i puszczam agenta w bój. To wszystko.
Przechodząc przez plan, agent automatycznie wykona również zapisane w nim kroki walidacji. Krok walidacyjny jest więc wbudowany w implementację. Można go uruchomić osobno — mam do tego całkowicie odrębny skill, jeśli chcesz wykonać walidację jednorazowo — ale zwykle robi się te rzeczy jednocześnie.
Własny przegląd i pull request
Kiedy agent zgłosi, że skończył, robisz własny code review i testy manualne. Zwłaszcza jeśli jesteś bardziej techniczny, nadal zalecam sprawdzanie pracy agenta. To, że strategia walidacji została ustalona z góry, nie oznacza, że agent wykona zadanie idealnie. Zrób więc taką weryfikację, jaką uznasz za stosowną — to twój własny przegląd. Mam też skille wspierające przeprowadzenie takiego review.
Ticket kończysz otwarciem pull requesta. Zwykle korzystasz z czegoś w rodzaju GitHuba do zarządzania repozytoriami, więc masz gotową propozycję: oto praca wykonana w pętli wewnętrznej dla tego ticketu, proponuję scalić ją do głównej gałęzi. Przeprowadzasz review na pull requeście, uznajesz go za dobry, scalasz — i przechodzisz do kolejnego ticketu. I tak w kółko, aż odhaczysz wszystkie tickety wygenerowane w skillu krojącym epik.
I to cały workflow. Materiał wyszedł dłuższy, niż zakładałem, ale chciałem naprawdę przygotować cię do sukcesu. Nie uruchamialiśmy tych skilli na żywo, ale wiesz już, jak układają się w całość — kiedy trzeba zacząć nową rozmowę, a kiedy kontynuować tę samą, jak przy primingu i planowaniu.
Dostosowywanie skilli
Wszystkie te skille możesz oczywiście dopasować do siebie. Staram się, żeby były maksymalnie minimalistyczne, ale mam tu pewne opinie: jaka jest najlepsza struktura PRD albo planu, jak agent powinien przeprowadzać wywiad.
Edycja tych plików jest bardzo prosta. Zwykle otwieram rozmowę z Claude’em, biorę plik skill.md — powiedzmy dla plan implementation — kopiuję go i mówię: „Cześć, chcę zmienić w tym skillu to i to”. Nigdy nie piszę tych skilli ręcznie ani nie nanoszę poprawek osobiście. Zawsze zlecam edycję agentowi kodującemu na podstawie ogólnego opisu. Jeśli więc coś ci w tych skillach nie odpowiada, gdy wybierzesz sobie z biblioteki to, co ci pasuje, dostosowanie ich jest naprawdę łatwe. Zmiana struktury, zmiana szablonów — wszystko da się zrobić rękami agenta.
Mam nadzieję, że te skille okażą się pomocne, niezależnie od tego, czy użyjesz wszystkich, czy tylko części. Będę dalej rozbudowywał to repozytorium, żeby stało się zbiorem wszystkich skilli, których używam. Na razie jest tam głównie rdzeń mojego cyklu wytwórczego, ale planuję znacznie więcej.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozdziel proces na pętlę zewnętrzną i wewnętrzną
Na czym polega: Pętla zewnętrzna (PRD → specyfikacja → tickety) wykonywana jest raz na epik i ustala zakres. Pętla wewnętrzna (priming → plan → implementacja → walidacja) powtarza się dla każdego ticketu.
Jak stosować: Zanim zaczniesz cokolwiek kodować z agentem, ustal, w której pętli jesteś. Jeśli nie masz jeszcze zdefiniowanego zakresu, kodowanie jest przedwczesne.
Na co uważać: Kuszące jest pominięcie pętli zewnętrznej przy „małych” zmianach. To działa tylko wtedy, gdy zadanie faktycznie mieści się w jednym tickecie — inaczej agent buduje coś, czego nie zdefiniowałeś.
2.Strategia walidacji przed pierwszą linijką kodu
Na czym polega: W dokumencie planu opisujesz z agentem, jak każdy element zostanie przetestowany — testy jednostkowe, integracyjne, przypadki brzegowe, konkretne komendy lintowania i sprawdzania typów, walidacja manualna przez przeglądarkę.
Jak stosować: Traktuj tę sekcję jako miejsce, w którym inwestujesz najwięcej własnej uwagi przy przeglądaniu planu. Wymuś podanie konkretnych, uruchamialnych komend, nie ogólników typu „napisz testy”.
Na co uważać: Zdefiniowana z góry walidacja nie gwarantuje poprawności. Agent może napisać testy, które przechodzą, choć nie sprawdzają tego, co istotne — dlatego własny przegląd wciąż jest konieczny.
3.„Bądź precyzyjny co do celu, nie co do środków”
Na czym polega: Zasada przypisana Borisowi Cherny’emu: opisz zadanie, bariery i kryteria wyjścia wraz z walidacją, a drogę pozwól wybrać modelowi.
Jak stosować: Zamiast dyktować agentowi kolejne kroki implementacji, zainwestuj czas w opis stanu docelowego i sposobu jego sprawdzenia. Potem daj mu popracować bez ciągłego przerywania.
Na co uważać: To działa tylko przy naprawdę mocnych kryteriach wyjścia. Jeśli walidacja jest słaba, „pozwolenie modelowi gotować” oznacza po prostu brak nadzoru.
4.Rozdziel „co i dlaczego” od „jak”
Na czym polega: PRD zawiera wyłącznie problem, użytkownika i hipotezę. Architektura i sposób implementacji trafiają do osobnego dokumentu specyfikacji, tworzonego w osobnej rozmowie.
Jak stosować: Uruchamiaj skill od PRD i skill od specyfikacji w dwóch niezależnych konwersacjach. Jeśli podczas pisania PRD zaczynasz opisywać schemat bazy danych — to sygnał, że mieszasz warstwy.
Na co uważać: Przy bardzo małych funkcjach dwa osobne dokumenty mogą być narzutem większym niż sama praca. Autor stosuje ten podział na poziomie epiku, nie pojedynczego ticketu.
5.Każda rozmowa produkuje artefakt, który zasila następną
Na czym polega: PRD i specyfikacja wchodzą na wejście skilla krojącego epik; ticket wchodzi do primingu i planu; plan wchodzi do implementacji. Kontekst przenosi się przez dokumenty, nie przez historię rozmowy.
Jak stosować: Po każdej fazie upewnij się, że dokument jest samowystarczalny — czy nowa rozmowa, która widzi tylko ten plik, poradziłaby sobie z zadaniem.
Na co uważać: Jeśli w rozmowie planistycznej padły ustalenia, których nie zapisano w dokumencie, przepadną przy przejściu do implementacji.
6.Implementacja zawsze w nowej rozmowie
Na czym polega: Konwersacja planistyczna jest długa i zaśmiecona; przejście do kodowania odbywa się w świeżym kontekście, gdzie jedynym wejściem jest ścieżka do planu.
Jak stosować: Skopiuj pełną ścieżkę do pliku planu, otwórz nową sesję i tam uruchom skill implementujący. Priming i planowanie zostają w jednej rozmowie, implementacja w drugiej.
Na co uważać: Nowa rozmowa nie zna niczego spoza planu. Jeśli plan pomija ważne pliki lub dokumentację, agent zacznie zgadywać.
7.Priming kontekstu jako osobny, jawny krok
Na czym polega: Osobny skill przeszukuje repozytorium — ogólnie albo przez pryzmat konkretnego ticketu — zanim zacznie się jakiekolwiek planowanie.
Jak stosować: Uruchom skill primujący jako pierwszy w rozmowie i podaj mu ticket, żeby eksploracja była ukierunkowana. Warianty wyspecjalizowane (np. tylko frontend) oszczędzają kontekst.
Na co uważać: Priming zajmuje miejsce w oknie kontekstu. Zbyt szeroka eksploracja dużego repozytorium może zostawić za mało miejsca na samo planowanie.
8.Wywiad zamiast założeń
Na czym polega: Skille od PRD, specyfikacji i planu zaczynają od zadawania użytkownikowi pytań. Cel: uniemożliwić modelowi przyjęcie własnych, „pewnych siebie” założeń.
Jak stosować: Odpowiadaj na te pytania rzetelnie, nawet gdy wydają się oczywiste — to najtańszy moment na wyłapanie rozbieżności. Ogólny pomysł na wejściu wystarczy, resztę wyciągnie wywiad.
Na co uważać: Odpowiadanie „rób jak uważasz” niweczy sens całego mechanizmu i przenosi ryzyko na etap implementacji, gdzie naprawa jest najdroższa.
9.Szablony jako źródło powtarzalności
Na czym polega: Każdy skill produkujący dokument ma zaszyty szablon — sekcje planu to opis problemu, opis rozwiązania, zakres wyłączony, cele negatywne, konteksty do referencji, pliki do zmiany i strategia testowania.
Jak stosować: Jeśli twoje wyniki z agentem bywają nierówne, przyczyną często jest brak stałego szablonu wyjścia. Ustal jeden i egzekwuj go w skillu.
Na co uważać: Szablon autora jest jego opinią, nie standardem. Sekcje należy dopasować do własnego kontekstu — nadmiarowe pola agent wypełni watą.
10.Skille edytuj agentem, nie ręcznie
Na czym polega: Autor nigdy nie pisze ani nie poprawia plików skill.md samodzielnie — wkleja skilla do rozmowy i opisuje zmianę słowami, a agent nanosi edycję.
Jak stosować: Traktuj bibliotekę skilli jako punkt wyjścia. Weź jeden, opisz agentowi, co chcesz zmienić w strukturze albo szablonie, i pozwól mu przepisać plik.
Na co uważać: Skille edytowane przez agenta warto przeczytać przed użyciem — zmiana promptu wpływa na każdy przyszły przebieg procesu, a błąd propaguje się po cichu na wszystkie kolejne tickety.