Większość poradników uczy tego samego: nowe zadanie, nowy agent. Jeden do prezentacji, drugi do analizy konkurencji, i tak w kółko. Tymczasem dwie osoby, które zbudowały w Anthropic mechanizm skilli, przestały tak pracować. Nie dlatego, że agenci zawiedli, tylko dlatego, że agent pod spodem okazał się dużo bardziej uniwersalny, niż zakładały. Zamiast budować kolejnego agenta, dokładają temu jednemu skille. Pokażę ci, na czym polega ta zmiana, a potem cztery praktyki, które decydują, czy skill zdejmie ci robotę z głowy, czy zostanie plikiem, do którego nikt nie zagląda.
Procesor, system, aplikacje
Najłatwiej zobaczyć to na telefonie. W środku jest procesor, na nim system operacyjny, a na wierzchu aplikacje, z których korzystasz codziennie. Procesor i system operacyjny pochodzą od kilku wielkich firm i ty ich nie wymieniasz. Wymieniasz aplikacje, a każda daje temu samemu telefonowi jedną konkretną zdolność. Nikt nie kupuje nowego telefonu po to, żeby mieć skaner dokumentów. Instaluje aplikację.
Układ narzędzi AI zaczyna wyglądać podobnie. Model jest tu procesorem. Środowisko agenta (po angielsku agent runtime), czyli program, który pozwala modelowi czytać pliki, uruchamiać narzędzia i prowadzić zadanie do końca, jest systemem operacyjnym. Skille są aplikacjami.
Doprecyzuję jedno pojęcie, bo wraca w całym tekście. Skill (po polsku umiejętność) to spisany zwykłym tekstem przepis na jedno zadanie, po który asystent sięga wtedy, gdy jest potrzebny. Nic technicznego, żadnego programowania.
Asystent taki jak Claude Code już czyta pliki, pisze kod, wywołuje narzędzia i pilnuje zadania od początku do końca. Tego nie musisz odtwarzać za każdym razem, gdy potrzebujesz prezentacji, notatki o firmie albo posta. Dajesz temu samemu ogólnemu agentowi skill, w którym siedzi proces, kontekst, gotowe skrypty i przykłady dla tej jednej roboty. Reszta zostaje bez zmian.
Ta zmiana przenosi ciężar w inne miejsce. Przestajesz projektować agentów, a zaczynasz opisywać własną pracę. O wartości całości decyduje więc jakość tych opisów, a nie sprytna architektura. Stąd cztery praktyki poniżej.
Nie płać asystentowi za rozwiązanie, które już masz
Zespół pracujący nad skillami zauważył u siebie coś banalnego i kosztownego. Za każdym razem, gdy asystent miał nadać styl slajdom, pisał praktycznie ten sam skrypt w Pythonie od zera. Palił na to tokeny, a że budował go za każdym razem na nowo, wynik potrafił się różnić między jednym a drugim uruchomieniem. Prezentacje wychodziły podobne, ale nigdy identyczne.
Rozwiązanie okazało się proste. Asystent dostał polecenie, żeby zapisać ten skrypt wewnątrz skilla jako narzędzie dla swojej przyszłej wersji; to sformułowanie samego zespołu. Od tego momentu skill nie prosi o nowy kod, tylko wskazuje plik, który już działa.
Programiści robią tak od dziesięcioleci i mają na to nazwę: DRY, od angielskiego don't repeat yourself, czyli nie powtarzaj się. Raz rozwiązany problem zapisujesz i używasz ponownie, zamiast pisać rozwiązanie od nowa. Z asystentem działa to tak samo.
W praktyce wygląda to tak. Następnym razem, gdy asystent napisze kod, którego wynik naprawdę ci się spodoba, nie zostawiaj go w oknie czatu, żeby przepadł razem z sesją. Powiedz mu wprost: zapisz skrypt, którego przed chwilą użyłeś, w folderze skryptów tego skilla, zaktualizuj instrukcję skilla tak, żeby kolejne uruchomienia wywoływały ten plik zamiast pisać go od nowa, a potem uruchom skill jeszcze raz i sprawdź wynik.
I sprawdź to sam, bo samo polecenie niczego nie gwarantuje. Uruchamiasz to samo zadanie dwa razy, porównujesz te elementy, na których ci zależy, i upewniasz się, że skill faktycznie sięgnął po zapisany plik, a nie napisał sobie nowy. Tekst dookoła nadal może się trochę różnić, bo to wciąż generowanie. Ale w środku masz już sprawdzony kod zamiast kolejnego zgadywania.
Skill, którego asystent nie znajdzie, to skill, którego nie masz
Mechanik ma w warsztacie setki narzędzi, ale nie wysypuje ich wszystkich na stół przed wymianą koła. Rozpoznaje zadanie, bierze te kilka, których potrzebuje, i zostawia resztę w skrzynce.
Skille działają tak samo dzięki mechanizmowi, który w Anthropic nazwano progresywnym ujawnianiem (po angielsku progressive disclosure). Przy starcie asystent nie czyta pełnych instrukcji, przykładów i skryptów ze wszystkich twoich skilli, bo to byłaby ogromna strata czasu i tokenów. Czyta wyłącznie nazwę i opis każdego z nich, zapisane w krótkim nagłówku pliku. Dopiero gdy twoje polecenie pasuje do któregoś opisu, wczytuje cały skill, a większe dokumenty pomocnicze i skrypty leżą w folderze, aż zadanie faktycznie ich zażąda.
Efekt jest praktyczny: instrukcje niezwiązane z bieżącą robotą nie zaśmiecają pamięci roboczej asystenta. Unikasz przeciążenia kontekstu, czyli sytuacji, w której model gubi się w nadmiarze rzeczy, o których musi jednocześnie pamiętać.
Ten mechanizm opiera się jednak na elemencie, który piszesz ty: na opisie. Jeśli jeden skill mówi „pomoc przy treściach”, a drugi „przygotowanie treści marketingowych”, asystent zgaduje. Te opisy zachodzą na siebie i żaden nie mówi, kiedy ma się uruchomić.
Mocny opis nazywa jedno i drugie: co skill robi i po czym poznać, że to właśnie ta sytuacja. Na przykład: „Ten skill tworzy karuzele na LinkedIn na podstawie tematu, transkrypcji albo konspektu. Użyj go, gdy użytkownik prosi o karuzelę, o slajdy karuzeli albo o post dokumentowy na LinkedIn”. Teraz asystent wie i co, i kiedy.
Pilnuj przy okazji dwóch rzeczy. Jeden skill ma obsługiwać jedno konkretne zadanie, opisane słowami, których naprawdę używa żywy człowiek. I żadne dwa skille nie mogą walczyć o to samo polecenie.
Przegląd możesz zlecić samemu asystentowi. Poproś go: przejrzyj opisy wszystkich moich skilli, przy każdym napisz, co robi, kiedy powinien się uruchomić i gdzie zachodzi na inny skill, a potem przepisz wyłącznie te opisy, które są niejednoznaczne. Resztę zostaw w spokoju.
Potem sprawdzasz to trzema poleceniami. Pierwsze jest oczywiste i skill ma się po nim uruchomić. Drugie mówi o tym samym zupełnie innymi słowami i skill też ma się uruchomić. Trzecie dotyczy czegoś innego i skill ma milczeć. Dopiero komplet trzech wyników mówi ci, czy opis działa.
To błąd, który widzę najczęściej ze wszystkich: ludzie dopieszczają procedurę w środku pliku, a przegrywają na jednym zdaniu w nagłówku. Skill, którego asystent nie znajdzie, to skill, którego nie masz.
Każdą poprawkę przenieś do skilla
Za każdym razem, gdy poprawiasz asystenta, a potem zamykasz okno rozmowy, prawdopodobnie właśnie wyrzuciłeś tę lekcję do kosza. Użył złego tonu, pominął sprawdzenie, sformatował wynik tak, jak nie chcesz go więcej oglądać. Mówisz „popraw to” i owszem, poprawi. Tyle że poprawi wynik, a proces zostanie zepsuty. Jutro zrobi dokładnie to samo.
Weź prostą sytuację: agent twierdzi, że nie może znaleźć pliku, o którym wiesz, że istnieje. Odruch podpowiada podać mu ścieżkę i iść dalej. Lepiej jest cofnąć go po własnych śladach: niech pokaże, gdzie szukał i dlaczego nie trafił, a potem zaktualizuje instrukcję albo ścieżkę wyszukiwania tak, żeby następny przebieg zaczynał się we właściwym miejscu.
Skille są pomyślane właśnie pod takie uczenie się. Gwarancja jest tu jedna: to, co asystent raz zapisze, jego przyszła wersja umie wykorzystać. Trzeba jednak wiedzieć, czego skill nie robi. Nie zapamiętuje wszystkiego ani nie archiwizuje twoich rozmów. Trzyma wiedzę proceduralną, czyli sposób wykonania tej konkretnej roboty.
Z tego wynika prosty podział poprawek. Gdy zawodzi proces, zmieniasz instrukcje w samym skillu. Gdy asystentowi brakuje twojego głosu, marki albo przykładów, dokładasz plik pomocniczy z wzorcami. A gdy ten sam błąd wraca po raz trzeci, dopisujesz jawną regułę, która go wprost zakazuje.
Możesz to zlecić jednym poleceniem: przejrzyj, co poszło nie tak w tym przebiegu, ustal, czy przyczyną był proces, brakujący kontekst, słaba reguła czy niepewny kod, zaktualizuj skill w najmniejszym trwałym miejscu, a potem uruchom to samo zadanie jeszcze raz i sprawdź, czy poprawka zadziałała. Po kilkunastu takich rundach skill staje się żywym zapisem tego, jak chcesz mieć tę robotę zrobioną.
Chcę tu być precyzyjna co do jednego określenia, które krąży wokół skilli: „odporny na zmianę modelu”. Żaden skill nie zmusi słabszego modelu, żeby pracował jak mocniejszy, a różne modele interpretują te same instrukcje po swojemu. Przenośny jest natomiast proces. Skille są otwartym formatem, więc ten sam folder może działać w różnych zgodnych środowiskach agentowych. Weź jeden ze swoich ważniejszych skilli i uruchom go z innym agentem. Jeśli wynik się rozpada, szukaj ukrytych założeń, brakujących przykładów albo sformułowań, które rozumie tylko jeden model, a potem dociągnij opis i testuj dalej.
Skill ma sprawdzić swoją pracę, zanim ci ją odda
Z całej czwórki ta praktyka jest najważniejsza i najczęściej pomijana. Typowy przebieg wygląda tak: uruchamiasz skill, on tworzy rzecz, zapisuje plik i melduje, że skończył. Otwierasz i widzisz rozjechane formatowanie, źródła, które nie potwierdzają tego, co napisano, albo tekst, który do twojego odbiorcy zwyczajnie nie trafia. Asystent zrobił większość roboty, a resztę domykasz ręcznie ty.
Jeśli i tak wiesz, jak sprawdziłbyś tę pracę osobiście, to wpisz właśnie te kroki do skilla. Wtedy asystent domyka większą część tej luki za ciebie.
Wygląda to inaczej w zależności od rodzaju pracy:
- Prezentacja. Skill renderuje każdy slajd jako obrazek, ogląda zrzuty, poprawia wszystko, co jest ucięte, nieczytelne albo wychodzi poza kadr, i renderuje ponownie.
- Raport z analizy. Skill otwiera źródła pierwotne, zestawia każde twierdzenie z dowodem, który ma je potwierdzać, i usuwa to, czego nie udało mu się potwierdzić.
- Scenariusz, reklama, tekst oceniany subiektywnie. Kilku pomocniczych agentów w różnych rolach czyta rzecz i ją omawia. Początkujący mówi, w którym miejscu przestał rozumieć. Sceptyczny kupujący mówi, w co nie wierzy. Ktoś z twojej realnej grupy odbiorców mówi, gdzie by się wyłączył.
Nie każda uwaga z takiego przeglądu jest dobra i przyjęcie wszystkich pogorszyłoby wynik. Skill ma znaleźć zastrzeżenia, które powtarzają się u kilku recenzentów, wprowadzić najmocniejsze poprawki i puścić przegląd jeszcze raz.
Zaznaczę wyraźnie, bo tu ludzie oszukują sami siebie: weryfikacją nie jest asystent czytający własny tekst i stwierdzający, że wygląda dobrze. Weryfikacja potrzebuje dowodu spoza tego pierwszego szkicu. Zrzutu ekranu, wyniku testu, źródła, wzorca do porównania albo opinii z innej perspektywy niż ta, w której tekst powstał.
Do niemal każdego skilla możesz dopisać ten sam akapit: zanim zwrócisz wynik, zapisz kryteria odbioru. Zrób pierwszą wersję, obejrzyj ją metodą weryfikacji właściwą dla tego rodzaju pracy, popraw każdy znaleziony problem i zrób kolejne przejście. Zwróć wynik dopiero wtedy, gdy spełnia kryteria, i dołóż krótkie podsumowanie tego, co sprawdziłeś. Jeśli czegoś nie dało się zweryfikować, napisz wprost, co zostało otwarte.
Najlepiej działa to, gdy da się ustawić miarę sukcesu, którą widać obiektywnie, i pozwolić agentom pracować, aż ją osiągną.
Ta jedna zmiana przesuwa moment, w którym wchodzisz do procesu. Pierwszy wynik przestaje trafiać do ciebie i staje się wewnętrznym szkicem. Asystent sam wyłapuje oczywiste problemy i poprawia je, zanim zobaczysz cokolwiek. Ostatnie słowo zostaje przy tobie, bo tam, gdzie w grę wchodzi smak, strategia albo decyzja biznesowa, żaden agent cię nie zastąpi. Zmienia się to, na co idzie twoja uwaga: przestajesz wyłapywać usterki, które maszyna mogła złapać sama.
Tak uczysz ogólnego agenta, jak pracujesz właśnie ty
Te cztery praktyki układają się w jedną linię. Zapisujesz sprawdzony kod zamiast płacić za pisanie go od nowa. Dajesz każdemu skillowi opis na tyle precyzyjny, że asystent sięga po właściwy. Zamieniasz każdą poprawkę w trwałą instrukcję. I każesz skillowi sprawdzić swoją pracę, zanim ta praca dotrze do ciebie.
Zasada, którą stąd zabieram, brzmi tak: ogólny agent staje się twoim agentem dopiero wtedy, gdy spiszesz mu własną robotę, a potem poprawiasz ten zapis po każdym nieudanym przebiegu. Osobny agent do każdego zadania to praca, którą wykonujesz w kółko. Skill to praca, którą wykonujesz raz, a potem tylko dokładasz do niej to, czego się nauczyłeś.
Zacznij od najmniejszego kroku. Wybierz jeden skill, którego używasz najczęściej, i dopisz mu dwie rzeczy: kryteria odbioru oraz jedną metodę weryfikacji, którą sam stosujesz, gdy sprawdzasz ten wynik ręcznie. Twoje pierwsze spojrzenie na wynik nie powinno być pierwszym spojrzeniem agenta.