O czym jest ten film
- Czym są agent skills — SOP-y dla AI zapisane w plikach Markdown, które eliminują konieczność powtarzania preferencji przy każdej sesji.
- Dlaczego dziś AI jest „jednoosobowe” — dobre skille powstają lokalnie i zostają na dysku jednej osoby.
- Analogia do ery Microsoft Word: brak wspólnego źródła prawdy, krążące kopie plików, brak wersjonowania.
- Dlaczego wysyłanie skilli Slackiem, Dropboxem, Google Drive albo Obsidianem zawodzi w praktyce.
- Rekomendowane rozwiązanie: repozytorium GitHub ze skillami udostępnione jako plugin i marketplace.
- Praktyczna instrukcja instalacji przez
/pluginw Claude Code oraz analogicznie w Codeksie. - Podział skilli na pluginy według działów firmy i kontrola dostępu, a także osobne repo prywatne.
- Argument o wartości przedsiębiorstwa: skille jako aktywo firmy, nad którym organizacja zachowuje własność.
- Nadbudowa w postaci aplikacji webowej: graf powiązań skilli, asystent doradzający, które uruchomić, oraz licznik użycia oparty na hooku.
- Filozofia projektowania: „cienkie agenty, grube skille”, łańcuchy skilli i pętla samodoskonalenia na końcu każdego pliku.
Redakcyjne tłumaczenie
Wprowadzenie
Greg Isenberg: Ludzie, którzy rozumieją, jak korzystać ze skilli i pluginów w Codeksie i Claude Code, mają po prostu nieuczciwą przewagę. Ale narosło wokół tego mnóstwo pytań: jak używać tego z zespołem, jak wrzucić to na GitHuba, jakie skille trzeba znać. W dzisiejszym odcinku rozkładamy to na czynniki pierwsze. Zaprosiłem mojego znajomego Remy’ego, który jasno tłumaczy, jak używać skilli, jak używać pluginów i jak prowadzi całą swoją firmę na zestawie skilli, które wyciągają z Claude Code najlepszy możliwy rezultat. Co ważne, Remy udostępnia też prompty, dzięki którym można to wszystko zbudować samodzielnie — wyjaśnia dokładnie, co trzeba zrobić, żeby wdrożyć łańcuchy skilli, czyli kilka skilli działających razem, i dzięki temu żyć produktywniej, a najlepiej też zarabiać więcej.
(Informacja dodatkowa: „agent skills” to format wprowadzony przez Anthropic — katalog z plikiem SKILL.md, który agent wczytuje na żądanie, gdy uzna, że pasuje do zadania.)
Greg: Błagałem go, żeby wrócił. AI with Remy, tak go znacie. Witaj z powrotem. Czego widzowie nauczą się do końca odcinka?
Remy: Nauczysz się, jak skutecznie zarządzać skillami i dystrybuować je w całym zespole.
Greg: Dobrze. A dlaczego to ma dla kogoś znaczenie?
Remy: Bo agent skills to prawdopodobnie najważniejsza pojedyncza koncepcja w tym momencie. To one realnie oszczędzają czas, kiedy próbujesz zautomatyzować powtarzalne procesy. A mam wrażenie, że nikt jeszcze naprawdę nie rozgryzł, jak porządnie nimi administrować i dzielić się nimi w zespole. Więc jeśli ktoś interesuje się agentami wykonującymi zadania i chce robić to zespołowo — ten odcinek jest dla niego.
Czym właściwie jest skill
Remy: Zanim wejdziemy głębiej, krótkie wprowadzenie dla tych, którzy nie wiedzą, czym jest skill. Kto wie, ten pewnie skorzysta z rozdziałów pod filmem i przewinie dalej.
Skille to dosłownie SOP-y dla AI. Bez skilla stara droga wygląda tak: chcesz mieć napisaną ofertę, więc otwierasz nową sesję albo nowy czat, prosisz Claude’a o ofertę. Prawdopodobnie od razu dostajesz coś, z czego nie jesteś zadowolony, więc od nowa tłumaczysz wszystkie swoje preferencje: kolory, logo, „przenieś cenę na dół zamiast na górę” i tak dalej. W końcu dochodzisz do wersji, która ci odpowiada. Ale co się dzieje w przyszłym tygodniu, kiedy tworzysz kolejną ofertę? Model zapomniał wszystko — chyba że ciągniesz tę samą sesję, co po pewnym czasie rodzi zupełnie inne problemy. Preferencje przepadły.
Skill natomiast pozwala zapakować cały twój sposób robienia rzeczy w jeden dokument — plik Markdown, który Claude czyta. To dosłownie SOP, instrukcja krok po kroku, jak wykonać dany proces. Odpaliłem sobie chwilę przed nagraniem małe demo: napisałem „stwórz ofertę dla Grega Isenberga, dla Startup Ideas, na sponsoring newslettera” — i poszło za pierwszym strzałem. Model wyciągnął skill do generowania ofert, który zbudowałem, i wygenerował tę ładną, opatrzoną brandingiem ofertę dokładnie tak, jak chciałem. Nie musiałem tłumaczyć ani jednej rzeczy od nowa.
Greg: I co najważniejsze — to nie był „slop”. Myślę, że wielu ludzi używa AI i dostaje slop właśnie dlatego, że nie mają dopracowanych skilli.
(Informacja dodatkowa: „slop” to potoczne określenie generycznej, bylejakiej treści generowanej przez AI.)
Remy: Dokładnie. Mam bardzo konkretny sposób, w jaki lubię, żeby rzeczy były zrobione. Kiedy raz go dopnę, buduję z tego naprawdę dobry skill i potem trafiam w dziesiątkę za każdym razem.
To, jak myślę o pracy agenta ze skillami, wygląda tak: wyobrażam sobie agenta jako najzdolniejszego pracownika, jakiego kiedykolwiek zatrudniłem. Siedzi przy biurku, ma komputer z podłączonymi narzędziami, czyli MCP. Ma plik z instrukcjami, który czyta przed każdym zadaniem, i dodatkowy kontekst, jeśli go potrzebuje. I ma wielki regał z SOP-ami — to właśnie skille. Kiedy otworzysz taki skill, na górze jest nazwa i opis; to jest jak grzbiet książki na półce. A kiedy agent uzna, że dany skill jest mu do zadania potrzebny, ściąga go z półki i czyta całość, która uczy go dokładnie, jak wykonać zadanie.
Skille są niesamowicie wartościowe. Dobry skill potrafi dosłownie zaoszczędzić dwie godziny tygodniowo, a jak takich nazbierasz kilka, to jest pozamiatane.
Problem: AI jest dziś jednoosobowe
Remy: Jeden z problemów, z którymi się teraz mierzymy, polega na tym, że AI jest bardzo „single player”. Każdy członek zespołu ma własną konfigurację Claude’a albo Codeksa na swoim komputerze. Jeśli zbuduje coś genialnego, świetny skill, to zostaje na jego maszynie. Bardzo trudno się tym porządnie podzielić.
To ten sam problem, który mieliśmy, gdy pojawiły się komputery osobiste i ludzie zaczęli korzystać z Microsoft Word. Tworzyłeś dokument, leżał na twoim komputerze, a żeby go komuś przesłać, musiałeś go wyeksportować i wysłać mailem. Krążyło mnóstwo kopii i nie było żadnego centralnego źródła prawdy. Na szczęście Google Docs to rozwiązał: jeden dokument w Google Drive, wszyscy w nim współpracują, jedno źródło prawdy.
Ze skillami jesteśmy dziś w erze Microsoft Worda. Wszyscy tworzą skille, są bardzo wartościowe, ale leżą na maszynach poszczególnych osób, a dzielenie się nimi i zarządzanie nimi w zespole jest naprawdę trudne.
Przykłady skilli wartych rozdystrybuowania
Remy: Kilka przykładów, które zbudowałem dosłownie w tym tygodniu i które okazały się przełomowe na tyle, że chciałem je dać zespołowi.
Pierwszy to skill do formatowania Notion. To był dokument, w którym przygotowywałem się do tego podcastu. Lubię, żeby wszystkie moje dokumenty w Notion miały określony format: dużo światła, żeby były czytelne, dużo linii oddzielających, małe niebieskie wyróżnienia elementów. Jeśli po prostu każesz Claude’owi zbudować dokument w Notion, wychodzi bałagan — tekst jest ściśnięty, kompletnie nieczytelny. Nauczyłem więc Claude’a konkretnego sposobu formatowania i zapakowałem to jako skill. Za każdym razem, gdy proszę o coś w Notion, model ściąga z półki ten skill i wie, co robić. Chcę, żeby korzystał z niego cały zespół, żeby wszystko wyglądało spójnie i porządnie.
Drugi to brand voice — głos marki AI with Remy, używany do treści mailowych, copy na landing page i tak dalej.
Trzeci to formatowanie maili. Korzystam z Resend jako jednego z dostawców wysyłki. Mam swój format maila: wyróżnienia podobne jak w Notion, dużo światła, niebieskie przyciski, podpis na dole i logo na górze. Nauczyłem Claude’a raz, jak dokładnie lubię sformatowane maile, zapisałem jako skill — i teraz chcę, żeby cały zespół miał ten sam skill, kiedy buduje maile powiadomieniowe albo marketingowe.
(Informacja dodatkowa: Resend to usługa do wysyłki maili transakcyjnych i marketingowych, popularna wśród zespołów deweloperskich.)
Sposoby dzielenia się skillami, które nie działają
Remy: Jak więc dzielić się skillami? Pierwotny sposób: zapisujesz plik skilla albo archiwum ZIP, wysyłasz na Slacku lub mailem, druga osoba wgrywa to u siebie i ma. Niby działa, ale wpadasz w koszmar: gdy wprowadzasz zmianę, jej plik się nie aktualizuje — to duplikat. A jeśli ona coś zmieni, ty tego nie dostajesz. Przy całym zespole, gdzie każdy ulepsza skille — a powinien to robić — kończysz z dziesięcioma różnymi kopiami i zerowym źródłem prawdy.
Innym sposobem, którego kiedyś używałem, były Drive, Dropbox albo Obsidian. Jeśli zainstalujesz aplikację desktopową Google Drive czy Dropboksa, foldery pojawiają się w systemie plików i teoretycznie możesz otworzyć taki folder w Claude. Można by więc stworzyć folder ze skillami. Problem pierwszy: Claude nie czyta skilli z folderu w Google Drive. Musi czytać ze swojego specjalnego katalogu .claude/skills. Żeby to w ogóle zadziałało, trzeba robić dowiązania symboliczne i mnóstwo prowizorki.
To da się przełknąć, jeśli masz mały, technicznie ogarnięty zespół, który rozumie strukturę katalogów. Ale w momencie, gdy dołącza junior albo ktoś z marketingu, kto nie jest techniczny ani AI-native, a chcesz, żeby korzystał z twoich skilli — wszystko się non stop psuje. Ludzie nie rozumieją, co zrobili, ani jak to poprawnie skonfigurować. To po prostu bardzo nieefektywne. Z Obsidianem jest tak samo, z tą różnicą, że każdy musi jeszcze zainstalować i skonfigurować Obsidiana, co jest udręką.
Rozwiązanie: repozytorium GitHub jako plugin
Remy: Werble, proszę. Jak dzielić się skillami w zespole? Najlepszy sposób, jaki znalazłem, to wrzucić je wszystkie do repozytorium GitHub i zrobić z tego plugin. Brzmi banalnie, ale jest niesamowicie skuteczne.
Większość widzów to rozumie, ale w skrócie: GitHub to taki Google Drive dla kodu. Tak jak Drive’em dzielisz się plikami, filmami i obrazkami, tak GitHubem dzielisz się kodem. Najprostsze podejście to wypchnąć wszystkie skille do repozytorium. Mam takie repo o nazwie team-skills, gdzie podzieliłem je według działów. W sekcji brandowej mam dwa skille, pozostałe działy mają swoje. I od razu masz centralne źródło prawdy, jedno miejsce, gdzie żyją wszystkie skille. A część „plugin” odpowiada za to, żeby Claude miał do nich łatwy dostęp.
Greg: Remy, wiele osób słyszy „repo” i „plugin”, robi się z tego kod, a jeśli ktoś nie jest techniczny, to się trochę przestraszy. Ale to naprawdę nie jest trudne.
Remy: Wcale nie jest trudne. Dobrze, że o tym mówisz — przygotowałem prompt, który damy widzom po odcinku. Zamieni istniejące foldery ze skillami dokładnie w taki setup: repo plus plugin. Ale szczerze, to prosta rzecz. Nie mam żadnego zaplecza programistycznego. Wystarczy zrozumieć, że GitHub to miejsce do przechowywania plików w chmurze, a plugin to sposób, w jaki Claude uzyskuje do nich dostęp. Tyle wiedzy w zupełności starczy.
Krótko o tym, czym jest plugin. Plugin to po prostu paczka skilli, MCP i hooków. Nie musisz pakować MCP ani hooków — możesz mieć plugin wyłącznie ze skillami albo wyłącznie z MCP, albo dowolną kombinację. Nasz konkretny plugin to paczka skilli.
(Informacja dodatkowa: MCP, czyli Model Context Protocol, to standard podłączania narzędzi i źródeł danych do agenta; hooki to skrypty uruchamiane automatycznie w reakcji na zdarzenia agenta.)
Instalacja krok po kroku
Remy: Instalacja jest banalnie prosta. Otwieram terminal, uruchamiam Claude Code i wpisuję /plugin. Pojawia się proste menu do zarządzania pluginami i ich instalowania. Przechodzę do sekcji marketplaces — tutaj dodajesz swoje repo jako marketplace. Wybierasz „add marketplace”, kopiujesz link do repozytorium i wklejasz. U mnie już to istnieje w systemie, bo mam to repo zainstalowane jako plugin, ale cała operacja to dosłownie podanie adresu URL repozytorium jako marketplace’u.
Kiedy wyjdę poziom wyżej, widać, że moje team-skills już się tam pokazują. Marketplace jest jak App Store, a same pluginy są jak aplikacje. Rozbiłem wszystkie skille według działów i każdy dział ma swój plugin. Na przykład osobie, która pomaga mi z copywritingiem, raczej nie kazałbym instalować pluginu ze skillami finansowymi. Można więc uzyskać ładny podział kompetencji według działów, co jest bardzo fajne.
Jeśli wejdę w pakiet skilli newsletterowych, zobaczysz: badania tygodniowe, intake, pisanie, historie, TL;DR i tak dalej.
Jedna rzecz naprawdę istotna: każdy, kto to instaluje, musi mieć włączoną automatyczną aktualizację. U mnie jest włączona, więc system proponuje mi jej wyłączenie. To ona sprawia, że skille aktualizują się na twojej maszynie, gdy ktoś inny wprowadzi zmianę. Teraz, po instalacji, gdy wpiszę na przykład „newsletter”, widać, że skille należą do pluginu newsletterowego i mogę z nich korzystać dokładnie tak samo jak w zwykłej, osobistej konfiguracji.
Greg: I to nie jest ograniczone do Claude Code. Osoby korzystające z Codeksa też mogą tego użyć, prawda?
Remy: Dokładnie tak. Testowałem to w Codeksie i w Claude. Innych harnessów jeszcze nie sprawdzałem, ale zakładam, że działają bardzo podobnie. Mam to zainstalowane w Codeksie jako plugin ze wszystkimi skillami zespołowymi — mogę w to wejść i je zobaczyć. Działa tak samo. Otwieram nowy czat, wpisuję „newsletter” i mam wszystkie skille do użycia. Więc tak, można tego używać w wielu harnessach naraz.
(Informacja dodatkowa: „harness” to tu określenie środowiska uruchamiającego agenta — Claude Code, Codex i podobne narzędzia CLI.)
To, co czyni plugin pluginem, to fakt, że masz repo na GitHubie, do którego wrzuciłeś skille, plus kilka małych plików JSON, które Claude i Codex czytają i które zamieniają repo w plugin. Nie mam zielonego pojęcia, jak to działa pod spodem. I nie muszę — po prostu poprosiłem Claude’a, żeby mi to skonfigurował. Zbudowałem do tego ładny prompt, który trafi do was, prawda, Greg?
Greg: Zgadza się.
Remy: Świetnie. Kiedy już to działa, wystarczy, że wszyscy w zespole zainstalują plugin u siebie w Claude i Codeksie. I masz skille w jednym centralnym źródle prawdy, rozdystrybuowane po całym zespole. Dostajesz przy okazji kontrolę wersji: jeśli ktoś zmieni skill i kompletnie go zepsuje, możesz cofnąć się do starszej wersji. Kiedy zbuduję coś świetnego, jak mój skill do formatowania Notion, i chcę, żeby korzystał z tego cały zespół, po prostu dodaję to do repo — i, o ile mają włączoną autoaktualizację, trafia to na konta Claude i Codeksa wszystkich osób.
Gotowe skille od innych i osobne repo prywatne
Greg: Fajne jest też to, że można pobrać sporo dobrych skilli. Zauważyłem, że masz skille marketingowe Corey’a Haynesa.
Remy: Tak, pozdrowienia dla Corey’a. Są rewelacyjne.
Greg: No i „the boring marketer” ma swoje boring marketing skills. Są zaufani twórcy, którzy publikują skille w internecie, więc nie musisz zaczynać od zera. Pobierasz część z nich jako fundament, dokładasz własne w zależności od tego, jaki masz biznes i czego potrzebujesz — i nagle twój zespół też ma do tego dostęp.
Remy: Dokładnie. Jedna rzecz, o której warto wspomnieć: mam osobne repo o nazwie remy-skills, w którym trzymam skille prywatne. To takie, których z jakiegoś powodu nie chcę dawać zespołowi, albo takie, które ściągnąłem z internetu i nie jestem gotowy wdrażać ich zespołowo — jeszcze się nimi bawię. To mój osobisty piaskownica. Do tego dochodzą skille czysto osobiste: mam skill do triage’u skrzynki, który uczy Claude’a, jak chcę obsługiwać maile, oraz morning brief, bardzo specyficzny dla moich aplikacji i mojego sposobu pracy. Tych nie ma sensu rozsyłać po zespole — każdy powinien zbudować własne wersje. To repo, jak się domyślacie, też jest skonfigurowane jako plugin. Mam je zainstalowane u siebie, zespół nie.
Greg: Ale po co w ogóle je tam trzymać, skoro nie dzielisz się nimi z zespołem? Chodzi o kontrolę wersji?
Remy: Po prostu lubię mieć jedno źródło prawdy. Wolę też, żeby były gdzieś w chmurze — jeśli uruchamiam agenta Hermes na VPS-ie albo jakieś agenty chmurowe, mają wtedy sposób na dostęp do moich skilli, zamiast trzymać wszystko lokalnie na dysku. No i kontrola wersji jest fajna. To chyba dwa główne powody.
Greg: Sensowne. Poza tym coś na lokalnym komputerze może zostać przejęte, a tak masz to w chmurze.
Remy: Mam dla ciebie historię. Jakieś dwa miesiące temu Claude usunął mi katalog .claude ze 150 skillami, w które włożyłem pewnie ponad 500 godzin pracy. Nie miałem żadnego backupu. To było ciężkie przeżycie. Więc to też jest obrona przed takim scenariuszem.
Greg: Czyli masz lekki PTSD. Mówisz w zasadzie: nie bądź jak Remy sprzed dwóch miesięcy, bądź jak Remy dzisiaj.
Remy: Dokładnie. To było głupie, że nie miałem backupów, ale jakoś tak wyszło.
Greg: Rozumiem. Wszyscy pędzimy na oślep, wszyscy próbujemy wycisnąć z AI jak najwięcej i chcemy budować, bo widzimy mnóstwo okazji. Czasem przez to tempo coś umyka. Bezpieczeństwo to jedna z takich rzeczy. Backupy to druga.
Remy: Tak. To osobiste repo ze skillami sprawdza się u mnie świetnie. Ale traktujcie to z przymrużeniem oka — jeśli macie własny setup, który działa, to trzymajcie się go. To po prostu mój sposób pracy i okazał się na tyle skuteczny, że chciałem się nim podzielić.
Skille jako aktywo firmy
Remy: Jeszcze jedna rzecz. Szczerze wierzę, że skille — może nie od razu, ale na pewnym etapie — zostaną z nami na dobre i będą dosłownie dodawać wartości przedsiębiorstwa firmom. Bo to dokładnie ta sama logika co SOP-y, którymi szkolisz pracowników do wykonywania zadań. Jeśli zbudujesz dobre skille, które uczą agentów wykonywania realnie wartościowych ekonomicznie zadań w biznesie, to są bardzo wartościowe aktywa.
Ten system daje ci ładne, centralne miejsce, w którym to firma ma własność skilli. U mnie jest to zbudowane w ramach mojej organizacji na GitHubie. Dzięki temu, jeśli pracownicy zbudują naprawdę wartościowe skille i trzymają je na swoich komputerach, a potem odejdą, ja zachowuję własność i kontrolę nad tymi skillami. To bardzo fajny produkt uboczny tego systemu.
Nadbudowa: interfejs nad repozytorium
Remy: Zbudowałem też ładny interfejs nad moimi skillami. Zanim pomyślisz „o nie, kolejny graf jak w Obsidianie” — ten jest naprawdę niezły. Wszystkie skille siedzą w repo na GitHubie. Tak jak masz backend w Supabase, który przechowuje dane aplikacji, tak repo team-skills jest backendem dla tej aplikacji webowej. Każdy skill, który tu widzisz, jest pobierany na żywo z tego repozytorium.
Mam sporo skilli, które wywołują inne skille. Na przykład mój workflow publikacji na YouTubie: uruchamiam jeden skill, który jest orkiestratorem, a on po kolei odpala skille od tytułów, miniatur i opisów. Interfejs pokazuje, jak te skille łączą się ze sobą i co wywołują. Mogę kliknąć i zobaczyć połączenia wchodzące i wychodzące z danego skilla, a także podejrzeć cały plik skilla.
Zauważyłem też, że przy wdrażaniu nowych osób, które nie są mocno obeznane z AI, to bardzo dobry sposób na zwizualizowanie wszystkich tych AI-owych SOP-ów, które zbudowałeś.
Dodałem jeszcze przycisk „ask” na dole. Zadałem kiedyś pytanie: jakie są najlepsze skille do podejmowania decyzji? System przeszukuje twoją prywatną bazę, bibliotekę skilli firmy, i odpowiada: te są najlepsze do decyzji. Jest LLM council, jest skill „grill me” od Matta PCO, jeszcze jeden od Corey’a Haynesa. A jeśli wpiszę „zrobiłem już tygodniowe badania do newslettera, jakie skille uruchomić dalej?”, pokaże wszystkie dostępne skille newsletterowe i powie: skoro zrobiłeś research, teraz uruchom ten, a potem tamten.
To taki miły asystent skilli — pomaga osobom w zespole mniej obeznanym z AI, a czasem też tobie samemu, gdy zbudowałeś tyle skilli, że przestajesz nad nimi panować.
I jeszcze jedno, dodałem to dosłownie dzisiaj, więc jest zupełnie nowe: pasek użycia. W pluginie siedzi hook — za każdym razem, gdy Claude użyje skilla, hook to zlicza. Śledzę więc, ile razy używam skilli, a także kto z zespołu jakich skilli używa i ile razy. Myślałem sobie, że mógłbym zrobić z tego takie małe Spotify Wrapped na koniec roku: „użyłeś skilla do ofert 56 razy”. Ale poza tym chcę widzieć skille, których nigdy nie używam — pokaż mi po pół roku wszystkie, których ani razu nie tknąłem, bo pewnie mogą zniknąć. Dzięki temu można przycinać swój stos, żeby się nie rozdął.
Greg: Albo odwrotnie: pokaż mi skille, których nie używam, a powinienem.
Remy: Tak, dokładnie. To może być pytanie do asystenta skilli.
I to właściwie tyle. Mamy repo ze skillami jako jedno centralne źródło prawdy dla firmy. Każdy dodaje je jako plugin w swoim Claude. Jeszcze drobiazg: jeśli masz konto Claude Enterprise, możesz mieć pluginy organizacyjne. Więc jako techniczny założyciel możesz to zbudować sam albo zlecić CTO, a potem wpiąć na stałe w konta Claude i Codeksa wszystkich pracowników. Wtedy mniej techniczni ludzie nie muszą w ogóle wchodzić do terminala ani wpisywać komendy ze slashem. To też fajny sposób.
Ile skilli budować i jak je projektować
Greg: Jak ludzie powinni myśleć o tym, ile skilli tworzyć? Widzę tu podział na działy: brand, content, newsletter, marketing, general. Czy myślenie o skillach sprowadza się do pytania, jakie zadania wykonuję i jak używam do nich modeli językowych? Jaki jest ogólny framework projektowania skilli i decydowania o ich liczbie?
Remy: Jestem głęboko przekonany, że można zautomatyzować praktycznie każdy proces w firmie, o ile nie jest fizyczny, jak zmywanie naczyń. Każdy proces online da się zautomatyzować naprawdę dobrym skillem albo serią skilli połączonych w łańcuch. Więc przy każdym powtarzalnym zadaniu, które wykonuję na co dzień, myślę: zamieńmy to w skill, nie chcę już tego dotykać.
Mam też workflow’y, gdzie proces — jak ten youtube’owy — jest rozbity na trzy skille uruchamiane po kolei. O łańcuchach skilli myślę tak: jeśli mam większy proces, na przykład wzięcie zmontowanego filmu i wrzucenie go na YouTube’a, to mógłby to być jeden skill. Ale jeśli w ramach tego większego procesu będę kiedykolwiek chciał uruchomić któryś z podprocesów osobno, to robię z tego łańcuch. Przy YouTubie to świetny przykład: czasem chcę tylko miniatury, czasem tylko tytuły, czasem tylko opisy. Dlatego w mojej głowie sensowniej jest mieć łańcuch niż jeden skill.
Ogólnie wygląda to tak: cały dzień pracy spędzam w Claude albo w Codeksie. Praktycznie nie otwieram już frontendów aplikacji. Mówię Claude’owi, co ma zrobić, a on wchodzi do aplikacji i wykonuje zadania za mnie. I za każdym razem, gdy wykonam z nim jakieś zadanie i wiem, że będę je robił ponownie, mówię: „zamień to w skill”. Tak właśnie skończyłem z taką liczbą skilli.
Greg: Zakładając, że pamięć działa dobrze, można też powiedzieć Claude’owi czy Codeksowi: za każdym razem, gdy proszę cię o powtórzenie czegoś, zrób z tego skill. Albo wpisać to do pliku MD.
Pętla samodoskonalenia w skillach
Remy: Zabawne, że o tym mówisz, bo niedawno coś takiego dodałem. Nie jestem pewien, czy jest już w każdym skillu, bo to świeża rzecz. Przy okazji, mam też widok biblioteki, gdzie można przejrzeć wszystkie skille w ładniejszej formie i je edytować. Weźmy skill, który stworzyłem niedawno — na przykład ten do ofert. Na samym dole powinien mieć sekcję self-improvement loop. Dodaję ją na końcu wszystkich moich plików SKILL.md.
Mówi ona mniej więcej tak: na koniec każdego uruchomienia tego skilla, zanim go zakończysz, przejrzyj — czy któryś krok się nie powiódł albo wymagał obejścia? Czy użytkownik poprawił lub odrzucił coś istotnego? Czy odkryłeś coś, co przyda się przy kolejnych uruchomieniach? I zaproponuj zmianę tylko wtedy, gdy jest wystarczająco istotna.
Na koniec każdego uruchomienia skilla dostaję zwykle jedną albo dwie sugestie ulepszeń. Odpowiadam „nie, niepotrzebne” albo „tak, świetny pomysł, wprowadź to” — i skill się aktualizuje. To taka mała pętla samodoskonalenia wbudowana na końcu wszystkich moich skilli. Bardzo się sprawdza.
Greg: To naprawdę sprytne. Czy jest coś jeszcze, co ludzie powinni wiedzieć o skillach, zanim skończymy?
Cienkie agenty, grube skille
Remy: Chyba tyle. Powiedziałbym tylko, że ludzie nie budują wystarczająco dużo skilli i wystarczająco dobrych jakościowo skilli.
Greg: Skillsmaxxing.
Remy: Tak. Jestem zwolennikiem tego, co mówi Russ Mike: cienkie agenty, grube skille. Trzymam pliki z instrukcjami dla agentów bardzo oszczędnie, a same skille robię grube i mocno szczegółowe. Wtedy agenty mają tylko wykonywać skille — a skille zawierają cały kontekst i wystarczająco dokładne instrukcje krok po kroku. Dzięki temu możesz otworzyć dowolny harness, uruchomić skill i zadanie zostanie wykonane tak, jak chcesz.
Greg: W pewnym sensie oddelegowujesz część strategii do skilli. Mówisz: przy miniaturach na YouTubie wiem, jak wygląda dobra robota, i zaraz to rozłożę na czynniki pierwsze. Albo, jak w twoich przykładach z dokumentami w Notion czy mailami: wiem, co jest dla mnie dobre, proszę bardzo. I dzięki temu nie musisz powtarzać tych instrukcji w kółko. To układ, na którym wszyscy wygrywają: dostajesz lepszy wynik, nie musisz się powtarzać, model robi to, w czym jest dobry, czyli wykonuje polecenia, a na dodatek jest w stanie sprawdzić, czy to faktycznie to, o co prosiłeś.
Remy: Dokładnie. Nawet dzisiaj, przy tym systemie: jeden z moich ludzi, Harold, budował nowego maila w Resend, do którego trzeba było wrzucić obrazki. Korzystał ze skilla do formatowania maili, który przygotowuje je w Resend. Natrafił na błąd przy wgrywaniu obrazków i znalazł obejście, dzięki któremu Claude ostatecznie wypracował poprawny sposób. Zaktualizował skill — a ja tę aktualizację od razu dostałem. Cały proces AI się poprawił dzięki innemu członkowi zespołu, a my wszyscy odbierzemy to ulepszenie przy następnym uruchomieniu skilla. To bardzo eleganckie.
Więc: idźcie i twórzcie skille.
Greg: Twórzcie skille, budujcie swoją firmę.
Remy: I zróbcie z tego plugin.
Greg: Tak, załóżcie repo. Zdziwicie się, jaki dostaniecie efekt. Jak mówiłem na początku, wielu ludzi próbuje różnych narzędzi AI i się frustruje, bo wynik nie jest dokładnie taki, jakiego chcieli.
Multiplayer AI
Greg: Zgadzam się też z tobą co do szansy w AI wieloosobowym kontra jednoosobowym. W oprogramowaniu w ogóle zawsze zaczyna się od trybu jednoosobowego — jak w twoim przykładzie z Microsoft Word czy Excelem. Jako twórcy oprogramowania musimy najpierw zrozumieć, czy ludzie naprawdę chcą danego produktu. Figma, czyli narzędzie do wspólnego projektowania, by nie wypaliła bez wcześniejszego Photoshopa. Wygląda na to, że wchodzimy w erę multiplayer AI. Doceniam, że tak jasno rozłożyłeś na czynniki pierwsze, co się dzieje, dlaczego, jak to wykorzystać i dokąd to zmierza. Dużo się nauczyłem. Dzięki, Remy.
Remy: Dzięki, Greg. Wielkie dzięki za zaproszenie.
Greg: Linki, gdzie śledzić AI with Remy, będą w opisie. Sprawdźcie. Damy wam też ten prompt, który możecie po prostu dać Claude’owi, a on weźmie wasze istniejące foldery ze skillami i zbuduje plugin na GitHubie, działający w Codeksie i w Claude Code. I to by było na tyle. Dzięki, Remy.
Remy: Dziękuję, Greg.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Skill to SOP dla agenta, a nie kolejny prompt
Na czym polega: Skill to plik Markdown opisujący krok po kroku, jak wykonać powtarzalny proces, wraz z twoimi preferencjami. Agent wczytuje go na żądanie, więc nie musisz przy każdej sesji od nowa tłumaczyć kolorów, układu czy tonu.
Jak stosować: Kiedy po serii poprawek dojdziesz z modelem do wyniku, który cię satysfakcjonuje, od razu poproś o zamianę tej ścieżki w skill. Zapisz w nim nie tylko kroki, ale i preferencje, które musiałeś tłumaczyć.
Na co uważać: Skill zbudowany na jednym niedopracowanym przykładzie utrwala błędy. Dopnij najpierw wynik ręcznie, a dopiero potem go zapakuj.
2.Główna bolączka to dystrybucja, nie tworzenie
Na czym polega: Skille powstają lokalnie i tam zostają. Zespół pracuje w trybie „single player” — dobre rozwiązanie jednej osoby nie dociera do reszty.
Jak stosować: Zanim zaczniesz masowo produkować skille, ustal, gdzie będą mieszkać i jak trafią do innych. Kolejność „najpierw dystrybucja, potem produkcja” oszczędza późniejszej migracji.
Na co uważać: Jeśli pracujesz solo, ten problem wygląda na nieistotny — do momentu, gdy zatrudnisz pierwszą osobę i będziesz mieć 100 skilli bez struktury.
3.Wysyłanie plików i dyski współdzielone nie skalują się
Na czym polega: ZIP na Slacku tworzy duplikaty bez synchronizacji. Google Drive, Dropbox i Obsidian wymagają dowiązań symbolicznych, bo agent czyta wyłącznie ze swojego katalogu skilli.
Jak stosować: Traktuj te metody jako tymczasowe, wyłącznie dla małego i technicznego zespołu. Przy pierwszej nietechnicznej osobie w zespole zmień podejście.
Na co uważać: Prowizorka z symlinkami psuje się cicho — ludzie nie zauważają, że pracują na starej wersji skilla, i winią za wynik model.
4.Repozytorium GitHub jako marketplace i plugin
Na czym polega: Wszystkie skille trafiają do jednego repo, do którego dokładasz kilka plików JSON zamieniających je w plugin. Repo dodajesz w Claude Code komendą /plugin jako marketplace, a poszczególne pakiety instalujesz jak aplikacje.
Jak stosować: Podziel skille na katalogi według działów i zrób z każdego osobny plugin, żeby copywriter nie instalował skilli finansowych. Nie musisz rozumieć struktury JSON — możesz poprosić agenta, żeby ją wygenerował.
Na co uważać: To rozwiązanie działa, o ile każdy ma włączoną autoaktualizację. Bez niej wracasz dokładnie do problemu rozjeżdżających się kopii, tylko z dodatkową warstwą złudzenia, że wszystko jest zsynchronizowane.
5.Działa w wielu harnessach naraz
Na czym polega: Ten sam plugin Remy używa równolegle w Claude Code i w Codeksie i działa tak samo. Innych narzędzi nie testował.
Jak stosować: Jeśli zespół pracuje na różnych narzędziach, i tak buduj jedno wspólne repo skilli — nie duplikuj biblioteki per narzędzie.
Na co uważać: Zgodność poza Claude Code i Codeksem to w tym materiale przypuszczenie, nie sprawdzony fakt. Przetestuj na jednym skillu, zanim ogłosisz zespołowi, że działa wszędzie.
6.Osobne repo prywatne obok zespołowego
Na czym polega: Skille eksperymentalne, pobrane z internetu i czysto osobiste (triage skrzynki, poranny brief) żyją w drugim repo, zainstalowanym tylko u ciebie.
Jak stosować: Traktuj prywatne repo jako piaskownicę — tam testujesz cudze skille i własne prototypy, a do repo zespołowego promujesz dopiero to, co się sprawdziło.
Na co uważać: Bez jasnej granicy między piaskownicą a repo produkcyjnym zespół dostanie surowe eksperymenty i straci zaufanie do biblioteki.
7.Skille w chmurze to backup i dostęp dla agentów zdalnych
Na czym polega: Remy stracił katalog .claude ze 150 skillami i około 500 godzinami pracy, bo Claude go usunął, a backupu nie było. Repo w chmurze rozwiązuje to i dodatkowo daje agentom działającym na VPS dostęp do skilli.
Jak stosować: Wypchnij skille do repo, zanim zbudujesz kolejny. Traktuj to jako element higieny pracy, nie usprawnienie.
Na co uważać: Repo prywatne to nie to samo co repo bezpieczne. Jeśli skille zawierają klucze, dane klientów lub wrażliwe procesy, sprawdź uprawnienia w organizacji na GitHubie.
8.Skille jako aktywo firmy, nie osobisty dorobek
Na czym polega: Skille to odpowiednik SOP-ów szkolących pracowników, tyle że dla agentów wykonujących zadania o realnej wartości ekonomicznej. Trzymane w organizacji na GitHubie zostają w firmie, gdy pracownik odchodzi.
Jak stosować: Utwórz repo w organizacji, a nie na prywatnym koncie. Wpisz do onboardingu, że skille budowane w pracy trafiają do repo firmowego.
Na co uważać: Roszczenie sobie własności do wszystkiego, co ktoś zbuduje, może zniechęcić do dzielenia się. Rozgraniczenie „repo firmowe kontra osobista piaskownica” warto powiedzieć wprost, a nie egzekwować po fakcie.
9.Łańcuchy skilli zamiast jednego monolitu
Na czym polega: Workflow publikacji na YouTubie to skill-orkiestrator uruchamiający po kolei skille od tytułów, miniatur i opisów. Kryterium podziału: czy kiedykolwiek zechcesz uruchomić podproces samodzielnie.
Jak stosować: Rozbijaj proces na ogniwa tam, gdzie realnie potrzebujesz pojedynczych elementów. Gdzie zawsze uruchamiasz całość, zostaw jeden skill.
Na co uważać: Dzielenie na siłę mnoży pliki i utrudnia utrzymanie. Przy dużej liczbie skilli tracisz orientację, co masz — dlatego Remy dobudował graf powiązań i licznik użycia, żeby przycinać nieużywane.
10.Pętla samodoskonalenia i zasada „cienkie agenty, grube skille”
Na czym polega: Na końcu każdego pliku SKILL.md Remy dodaje sekcję każącą agentowi po wykonaniu zadania sprawdzić, czy któryś krok zawiódł, czy użytkownik coś istotnego poprawił i czy pojawiło się coś przydatnego na przyszłość — i zaproponować zmianę tylko wtedy, gdy jest znacząca. Instrukcje agenta pozostają minimalne, cały kontekst siedzi w skillu.
Jak stosować: Dopisz taką sekcję do skilli, których używasz najczęściej, i realnie decyduj o każdej sugestii. Ulepszenie wprowadzone przez jedną osobę rozchodzi się po całym zespole przez autoaktualizację — tak jak u Harolda, który znalazł obejście błędu przy wgrywaniu obrazków w Resend.
Na co uważać: Automatyczne akceptowanie sugestii prowadzi do rozrostu skilli i dryfu jakości. Ponieważ zmiany trafiają do wszystkich, kontrola wersji i możliwość cofnięcia do starszej wersji nie są opcjonalne.