O czym jest ten film
- Zanim Claude przeczyta długi plik referencyjny skilla, ogląda tylko jego pierwsze sto linii (polecenie „head -100”) — treść zapisana poniżej tej granicy w praktyce dla niego nie istnieje.
- Anthropic zaktualizował przewodnik dobrych praktyk o sześć nowych reguł, które dotyczą także skilli zbudowanych według starych zasad (dobry opis, całość poniżej 200 linii, osobne pliki referencyjne).
- Każdy plik referencyjny powyżej stu linii powinien zaczynać się spisem treści odpowiadającym nagłówkom sekcji.
- Poziom szczegółowości instrukcji ma zależeć od wrażliwości zadania na błędy — Anthropic wyróżnia trzy poziomy swobody (wysoką, średnią, niską), a jeden skill może je łączyć w różnych krokach.
- Skille trzeba testować na każdym modelu, z którym będą używane: Haiku potrzebuje więcej wskazówek, Opus cierpi na ich nadmiar, a nowsze modele rozumujące (jak Fable 5) mogą dawać gorsze wyniki ze skillami pisanymi pod starsze modele.
- Struktura plików to teraz podstawa: skill.md poniżej 500 linii jako spis treści, materiały dzielone według obszarów, a wszystkie referencje linkowane bezpośrednio — maksymalnie jeden poziom głęboko.
- Skrypty, czyli miejsca o niskiej swobodzie, wykonują się identycznie na każdym modelu i nie zużywają kontekstu, bo są uruchamiane, a nie wczytywane do pamięci.
- Złożone procesy powinny dostawać checklistę odhaczaną w trakcie pracy, z warunkiem powrotu do wcześniejszego kroku — to mechanizm samoweryfikacji.
- Skill może doskonalić się sam: pętla „sprawdź — popraw — powtórz” plus propozycje nowych reguł dopisywane do dokumentu stylu po każdym przebiegu.
- Ostatnia reguła to przenośność: przy każdym skrypcie linia instalacyjna, bo na cudzej maszynie twoje zależności nie istnieją. Autor dodaje darmowy prompt do audytu skilla i zapowiada odcinek o zmianach w zaleceniach dotyczących promptów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Spis treści na początku każdego pliku referencyjnego powyżej 100 linii
Na czym polega: Claude zanim sięgnie do długiego pliku, ogląda tylko jego pierwsze sto linii („head -100”). Bez indeksu nie wie, co jest dalej, i często porzuca plik. Zasady zapisane poniżej setnej linii są więc dla niego niewidzialne.
Jak stosować: Przejrzyj katalog .claude/skills, znajdź pliki referencyjne dłuższe niż sto linii i wklej na ich początku spis treści pokrywający się z nagłówkami. Wzorem niech będzie przykład Anthropica — dokumentacja API z pięcioma pozycjami: uwierzytelnianie i konfiguracja, metody podstawowe, funkcje zaawansowane, wzorce obsługi błędów, przykłady kodu.
Na co uważać: Indeks musi odpowiadać realnym nagłówkom w pliku — martwy spis, który nie pokrywa się z treścią, pogarsza sprawę. Tę robotę można zlecić Claude’owi, ale wynik warto przejrzeć ręcznie.
2.Trzy poziomy swobody — dobierz szczegółowość do zadania
Na czym polega: Wysoka swoboda to zwykły tekst z celem (przegląd rozmowy sprzedażowej, szkic posta na LinkedIn). Średnia to szablon z przełącznikami (raport tygodniowy: wykresy tak/nie, format Markdown albo HTML). Niska to dokładne polecenie lub skrypt (migracja bazy danych: „uruchom dokładnie ten skrypt, nie dokładaj flag”).
Jak stosować: Przy każdym nowym skillu najpierw zdecyduj, do której kategorii należy zadanie, i dopiero potem pisz — zamiast odruchowo maksymalizować szczegółowość wszędzie.
Na co uważać: To, co wygląda na prostą czynność, nie zawsze jest bezpieczne. Wystawianie faktur czy usuwanie członków zespołu to operacje o niskiej swobodzie, bo dotykają pieniędzy i danych.
3.Jeden skill może łączyć różne poziomy swobody
Na czym polega: Swobodę ustala się dla każdego kroku osobno, a nie dla całego skilla. W skillu fakturującym krok „napisz treść” może mieć pełną dowolność, a krok „wystaw fakturę” — być twardo zamknięty skryptem.
Jak stosować: Dla każdego kroku zadaj jedno pytanie: co się stanie, jeśli Claude zrobi to inaczej? Odpowiedź „niewiele” — luzujesz. Odpowiedź „będzie kosztowno” — zamykasz na klucz.
Na co uważać: Nie przesadzaj w drugą stronę: zamykanie każdego kroku skryptem odbiera modelowi możliwości tam, where swoboda w niczym nie szkodzi.
4.Niska swoboda to skrypt, a nie coraz gęstszy tekst
Na czym polega: Jeśli coś ma się dziać identycznie za każdym razem, najlepszą „instrukcją” jest skrypt. Skrypt wykonuje się tak samo na każdym modelu — Haiku, Sonnet, Opus — i nie kosztuje ani odrobiny kontekstu, bo jest uruchamiany, a nie wczytywany do pamięci.
Jak stosować: W strukturze skilla wydziel katalog na skrypty i przy każdej operacji wrażliwej odwołuj się do konkretnego skryptu zamiast opisywać czynność słowami.
Na co uważać: Skrypt bez linii instalacyjnej obok (patrz punkt 10) wysypie się na pierwszej lepszej cudzej maszynie.
5.Testuj skilla na każdym modelu, na którym będziesz go używać
Na czym polega: Wynik zależy od modelu, który wykonuje skilla. Starsze modele pomijały kroki — stąd numerowane listy i „WAŻNE”. Nowsze modele rozumujące, jak Fable 5, miewają odwrotnie: nadmiar instrukcji pisany pod starsze modele pogarsza im wyniki i Anthropic zaleca takie instrukcje po prostu usuwać.
Jak stosować: Przepuść najczęściej używanego skilla przez to samo zadanie na Haiku, Opusie i Sonnecie. Haiku gubi krok — doprecyzuj go albo zamień na skrypt. Opus wypada ze skilllem gorzej niż bez niego — tnij instrukcje, aż wyniki wrócą do poziomu. Trzy pytania kontrolne: Haiku — czy ma dość wskazówek? Sonnet — czy skill jest jasny i zwięzły? Opus — czy nie tłumaczy ponad miarę?
Na co uważać: Skill musi działać na wszystkich trzech modelach, chyba że świadomie piszesz go pod jeden, konkretny.
6.Wpisz model docelowy w nagłówku YAML
Na czym polega: Blok metadanych na początku pliku skilla może zawierać informację o modelach, dla których go napisano. Bez tego ktoś inny uruchomi skilla na modelu, dla którego jest zbyt ogólny albo zbyt dyrektywny.
Jak stosować: Dodaj pole z docelowym modelem, zanim udostępnisz skilla zespołowi albo zaczniesz go sprzedawać.
Na co uważać: Dokumentacja szybko się dewastuje — po przepisaniu skilla pod nowe modele zaktualizuj też metadane.
7.Trzymaj skill.md poniżej 500 linii i traktuj go jak spis treści
Na czym polega: Główny plik skilla to mapa, nie magazyn. Zbliżając się do limitu, wynosisz treść do osobnych plików — przewodników, dokumentacji API, przykładów, skryptów — a Claude otwiera dany plik dopiero wtedy, gdy konkretny krok tego wymaga.
Jak stosować: Wzorcowa struktura skilla do PDF-ów: skill.md, forms.md (przewodnik wypełniania formularzy), reference (dokumentacja API), examples i scripts. Gdy skill obejmuje kilka obszarów, dziel referencje według obszaru: pytanie o przychody nie może wczytywać pliku o marketingu, a w skillu raportowym każdy klient dostaje własny plik.
Na co uważać: Podział ma podążać za logiką zadań, nie za estetyką katalogów — pliki, których Claude nigdy nie otwiera, tylko zaśmiecają skilla.
8.Referencje maksymalnie jeden poziom głęboko
Na czym polega: Jeśli skill.md wskazuje na plik advanced.md, a ten dopiero na details.md, plik na końcu łańcuszka zostanie co najwyżej przejrzany, czyli przeczytany fragmentarycznie. To ten sam mechanizm co „head -100”, tylko piętro niżej.
Jak stosować: Wypisz z skill.md wszystkie pliki i znajdź te osiągalne wyłącznie przez inny plik — tę kontrolę możesz zlecić samemu Claude’owi. Potem podlinkuj każdy z nich wprost ze skilla.
Na co uważać: Po każdej większej przebudowie struktury łatwo zostawić stare, pośrednie wskaźniki — audyt powtarzaj po refaktoringu.
9.Wbuduj samokontrolę: checklistę z powrotem do kroku i pętlę poprawek
Na czym polega: Przy złożonych zadaniach daj Claude’owi checklistę, którą kopiuje do odpowiedzi i odhacza w trakcie. W kroku weryfikacji dodaj warunek powrotu („jeśli przypisy są niekompletne, wróć do kroku trzeciego”) — to blokuje odhaczanie kroków, których nie wykonano. Drugi mechanizm to pętla: sprawdź, popraw, powtórz aż do przejścia, gdzie kontrolą może być zwykły dokument stylu, np. głos marki.
Jak stosować: Checklistę stosuj tylko tam, gdzie kolejność ma znaczenie (najpierw sprawdź dane, potem buduj raport); gdzie nie ma — daj sam cel. Gdy szkic obleje z powodu, którego nie ma jeszcze w dokumencie zasad, każ Claude’owi zaproponować nową regułę, zatwierdź ją i dopisz — skill zacznie doskonalić się sam.
Na co uważać: Reguły w dokumencie stylu lubią się mnożyć — co jakiś czas przeglądaj je i czyść, zanim zaczną się ze sobą gryźć.
10.Projektuj pod przenośność: linia instalacyjna przy każdym skrypcie
Na czym polega: Skill działa u ciebie, bo pół roku temu zainstalowałeś wszystkie zależności. U kolegi z zespołu albo w świeżej sesji wywali się pierwszego dnia, bo tych bibliotek tam nie ma. Nie wolno zakładać, że narzędzia są zainstalowane.
Jak stosować: Zamiast „użyj biblioteki PDF do przetworzenia pliku” pisz „zainstaluj wymagany pakiet” i podaj jego nazwę — jeśli pakiet już jest, Claude pominie ten krok, bo jest na tyle rozsądny, że to zauważy. Przy każdym skrypcie w skillu umieść jego linię instalacyjną tuż obok.
Na co uważać: Dotyczy to zwłaszcza skilli udostępnianych i sprzedawanych — to różnica między „działa od pierwszej minuty” a ciągłym pomaganiem innym w konfiguracji.
Redakcyjne tłumaczenie
Sto pierwszych linii, które decydują o wszystkim
Gdy Claude otwiera długi plik referencyjny wewnątrz któregoś z twoich skillów, nie zawsze czyta go od początku do końca. Najpierw uruchamia polecenie „head -100”, czyli w praktyce ogląda tylko pierwsze sto linii i na tej podstawie ocenia, czy plik w ogóle wnosi coś, czego akurat potrzebuje. (Informacja dodatkowa: „head -100” to polecenie terminalowe wypisujące pierwsze sto linii pliku — nic więcej.) Wniosek jest brutalny: jeśli twoje kluczowe zasady leżą poniżej setnej linii, dla Claude’a po prostu nie istnieją.
Skille wystartowały na początku tego roku i wszyscy szybko przyswoiliśmy jeden schemat: zwięzły, dobrze napisany opis, całość poniżej dwustu linii, materiały dodatkowe wyniesione do osobnych plików, a wszystko sformułowane jak zestaw poleceń. Ten schemat właśnie się zestarzał. Plik referencyjny powyżej stu linii bez spisu treści ma — według nowych zaleceń — niewielkie szanse, żeby w ogóle zostać użyty. Anthropic dopisał do swojego przewodnika dobrych praktyk sześć kolejnych reguł tego pokroju, a one obejmują także wszystko, co już dawno zbudowałeś. Zastosuj je porządnie, a twoje skille będą dawały znacznie bardziej powtarzalne wyniki — niezależnie od tego, który model akurat je wykonuje.
Zasada pierwsza: spis treści na początku każdego długiego pliku
Pierwsza nowa reguła każe wstawiać spis treści — taki mini-indeks — na sam początek każdego pliku referencyjnego dłuższego niż sto linii. Dzięki temu Claude może albo przejrzeć całość, albo od razu przeskoczyć do sekcji, której potrzebuje.
Własny przykład Anthropica to dokumentacja API: na górze pięć pozycji — uwierzytelnianie i konfiguracja, metody podstawowe, funkcje zaawansowane, wzorce obsługi błędów, przykłady kodu — a pod spodem właściwe sekcje, po jednej dla każdej pozycji.
W praktyce: wejdź do Claude Code albo do czatu Claude (Co-Work zostało już z nim zintegrowane), przejrzyj kolejno każdy skill w katalogu .claude/skills, wyławiaj pliki referencyjne powyżej stu linii i doklejaj na ich początku spis treści odpowiadający nagłówkom. Tyle. Nic więcej.
Zasada druga: dopasuj swobodę instrukcji do zadania
Ta zmiana całkowicie odwróciła moje myślenie o skillach. Do tej pory traktowałem je jednakowo: każdy miał dostawać tak samo precyzyjne instrukcje, na ile się dało. A procesy biznesowe rzadko są aż tak jednoznaczne. Anthropic mówi wprost: poziom szczegółowości ma zależeć od tego, jak bardzo zadanie jest wrażliwe na błędy i jak bardzo bywa różne w wykonaniu. Nazywają to dobieraniem właściwego poziomu swobody i wyróżniają trzy stopnie.
Wysoka swoboda to zwykłe instrukcje słowne. Przykład z dokumentacji: przegląd kodu — sprawdź strukturę, wyłap błędy, zaproponuj ulepszenia czytelności i utrzymania, pilnuj konwencji projektu. Dobrych sposobów na code review jest wiele, a właściwy zależy od konkretnego kodu, więc Claude dostaje cel i sam dobiera drogę. Modele są już na tyle sprytne, że cel im wystarcza. A jeśli nie jesteś programistą, tylko prowadzisz firmę? Wysoką swobodę masz np. w omawianiu rozmowy sprzedażowej czy pisaniu posta na LinkedIn — zwykły tekst, dopuszczalna dowolność podejścia.
Średnia swoboda to szablon z przełącznikami. Przykład: wzór raportu z ustawieniami — wykresy: tak albo nie; format: Markdown, HTML albo inny. Mamy preferowany kształt, ale pewna różnorodność jest w porządku. Typowy przykład: cotygodniowy raport dla klienta.
Niska swoboda obowiązuje tam, gdzie operacje są delikatne i łatwo o pomyłkę, gdzie liczy się żelazna powtarzalność i narzucona kolejność. Traktuj to jak precyzyjne polecenie. Przykład z dokumentacji: migracja bazy danych. Instrukcja brzmi: uruchom dokładnie ten skrypt. Nie zmieniaj komendy. Nie dokładaj flag. W twoim świecie będzie to wszystko, co dotyka pieniędzy albo kasowania danych: wystawianie faktur, usuwanie członków zespołu. Tam, gdzie stawka jest poważna, dajemy konkretny skrypt — bez parametrów albo z minimalną ich liczbą.
Z tych reguł wynikają trzy rzeczy, które zapamiętałem. Po pierwsze, jeden skill może łączyć różne poziomy: w skillu fakturującym krok „napisz treść” dostaje pełną swobodę, a krok „wystaw fakturę” jest całkowicie zamknięty. Po drugie, dla każdego kroku warto zadać pytanie: co się stanie, jeśli Claude zrobi to inaczej? Jeśli odpowiedź brzmi „niewiele się stanie”, luzujemy. Jeśli stawka jest poważna — zamykamy na klucz. Po trzecie, niska swoboda to niemal zawsze skrypt, a nie coraz bardziej szczegółowy tekst. Skrypt gwarantuje, że Claude zrobi daną rzecz dokładnie tak samo za każdym razem.
Przy okazji ogromne podziękowania: pomogliście mi dobić do stu tysięcy subskrypcji. Naprawdę doceniam cały czas, który poświęcacie na oglądanie, i te miłe komentarze.
Zasada trzecia: testuj na każdym modelu, nie tylko na najnowszym
Trzecia reguła wydaje się oczywista, a mimo to prawie nikt jej nie stosuje. Pisząc i testując skilla, robiłeś to pewnie na jednym modelu — brałeś Sonneta, Opusa albo świeże modele Fable, po prostu cokolwiek było najnowsze w danym miesiącu. Wiem, bo sam tak czasem robię. Tymczasem wynik skilla zależy od modelu, który go wykonuje — i to wystarczy, żeby wymagać testów na każdym modelu, z którym planujesz go używać. Pisać trzeba pod ilość szczegółów, jakich dany model potrzebuje, a właściwa ilość zmieniła się bardzo mocno.
Sześć–osiem miesięcy temu starsze modele miewały skłonność do pomijania kroków, więc pisaliśmy numerowane listy, wielkie litery i słowa typu „WAŻNE”. Dziś z nowszymi, mocniejszymi modelami rozumującymi jest dokładnie odwrotnie. Przewodnik dla modelu Fable 5 mówi wprost, że skille pisane pod starsze modele bywają dla niego zbyt szczegółowe i mogą pogarszać wyniki. W związku z tym Anthropic zaleca usuwanie starych instrukcji, jeśli model radzi sobie bez nich lepiej. Ale uwaga: mniejsze modele, na przykład wcześniejsze wersje Sonnet, nie posunęły się tak daleko jak flagowce.
Strona dobrych praktyk podsuwa po jednym pytaniu kontrolnym na model. Dla Haiku: czy skill daje mu wystarczająco dużo wskazówek? Dla Sonnet: czy skill jest jasny i zwięzły? Dla Opus: czy nie tłumaczy ponad miarę? (Informacja dodatkowa: Haiku, Sonnet i Opus to modele Anthropica — od najmniejszego i najszybszego po najmocniejszy. Fable 5 to wymieniany przez autora nowszy model rozumujący.) Każdy model potrzebuje innego poziomu szczegółów, więc skill musi trafić w punkt, który działa dla wszystkich trzech — chyba że wiesz, że użyjesz go wyłącznie z jednym, konkretnym.
Mocno polecam taki eksperyment: weź skilla, po którego sięgasz najczęściej, i przepuść to samo zadanie przez Haiku, potem przez Opusa, potem przez Sonneta. Jeśli Haiku gubi jakiś krok, ten krok trzeba napisać czytelniej — albo zamienić na skrypt, czyli dać mu niską swobodę, bo skrypt, przypominam, wykonuje się identycznie na każdym modelu. A jeśli Opus wypada z tym skillem gorzej niż bez niego, zacznij ciąć instrukcje, aż jego wyniki wrócą do poziomu. I jeszcze jedno: jeżeli zamierzasz skilla udostępniać, wpisz w nagłówku YAML — w tym bloku metadanych na początku pliku — z jakim modelem jest przeznaczony do pracy.
Kolejne zasady: układ plików i samokontrola
Schodzimy teraz na reguły dotyczące tego, jak skill jest poukładany w pliki i jak sprawdza własną pracę — począwszy od zagnieżdżania.
Anthropic radzi trzymać treść pliku skill.md poniżej pięciuset linii i traktować go jak spis treści całej reszty. Zbliżając się do limitu, dzielimy materiał na osobne pliki. I tu wchodzi zagnieżdżanie: skoro wynosimy treść do osobnych plików, trzeba na nie wskazać ze skilla.
Przykład: skill do PDF-ów. W skill.md siedzą instrukcje, a obok przewodnik po formularzach i dokumentacja API wraz z przykładami wypełniania formularzy. Claude, przechodząc przez skilla, otworzy plik referencyjny czy formularzowy dopiero wtedy, gdy konkretny krok tego wymaga. Struktura katalogu wygląda mniej więcej tak: folder skilla PDF zawiera skill.md, forms.md (przewodnik wypełniania formularzy), reference (dokumentacja API), examples oraz osobny katalog scripts. Skrypty to dokładnie te miejsca, gdzie nadajemy niską swobodę — gdzie coś ma zostać zrobione co do joty, za każdym razem tak samo. I ważny szczegół: skrypty są wykonywane, a nie wczytywane do pamięci, więc nie kosztują Claude’a ani odrobiny kontekstu.
Dalej jest rada: gdy skill obejmuje kilka obszarów, dziel referencje według obszaru. Przykład to skill do danych z osobnymi plikami dla finansów, sprzedaży, produktu i marketingu — pytanie o przychody nigdy nie wczyta pliku o marketingu. W twoim wydaniu może to być skill raportujący, w którym na każdego klienta przypada osobny plik.
Pułapka łańcuszków: referencje tylko jeden poziom głęboko
I tu wraca problem „head -100” z początku odcinka. Jeśli skill.md wskazuje na plik advanced.md, a ten dopiero na details.md, Claude najpewniej tylko przejrzy owy details.md — informacja na końcu łańcuszka zostanie przeczytana fragmentarycznie. Rozwiązanie: każdy plik referencyjny linkujemy bezpośrednio ze skilla, maksymalnie jeden poziom głęboko. W praktyce: otwórz skill.md, wypisz wszystkie pliki, na które wskazuje, i poszukaj tych osiągalnych tylko przez inny plik — tę robotę możesz zlecić samemu Claude’owi. Potem dopilnuj, żeby wszystkie one były podlinkowane wprost ze skilla.
Checklista, którą Claude odhacza w trakcie pracy
Dłuższe procesy potrzebują porządnej listy kontrolnej — Claude ją uwielbia. Przy złożonych zadaniach Anthropic radzi rozbić pracę na kroki i wręczyć Claude’owi checklistę, którą ten kopiuje do swojej odpowiedzi i odhacza w miarę wykonywania. W przykładzie — procesie badawczym — kroków jest pięć.
Brzmi to jak odwrotność odświeżonych rad, żeby dawać modelowi całe zadanie zamiast rozpisanych kroków? Tak wygląda, ale nie jest. Kroki są wtedy, gdy kolejność ma znaczenie — na przykład gdy dane trzeba sprawdzić, zanim zbuduje się na nich raport. Jeśli kolejność nie gra roli, checklisty nie dodajemy. Przykład z dokumentacji nie zawiera żadnego kodu: to proces syntezy badawczej, a checklista to pięć krótkich linii, bez dyktowania — „Przeczytaj wszystkie dokumenty źródłowe. Wyznacz kluczowe wątki.” Cel jest jasny, droga pozostaje swobodna. Pod każdym krokiem ląduje krótki akapit, a najciekawszy jest krok piąty: zweryfikuj przypisy — sprawdź, czy każda teza odsyła do właściwego dokumentu źródłowego, a jeśli przypisy są niekompletne, wróć do kroku trzeciego. To „wróć do kroku trzeciego” sprawia, że nieudany krok nie zostaje po prostu odhaczony i zignorowany.
To jest właśnie samoweryfikacja — i stanowi pomost do kolejnej reguły.
Pętla: sprawdź, popraw, powtórz
Wzorzec walidacji wyników skilla u Anthropica wygląda tak: uruchom sprawdzenie (albo zestaw sprawdzeń), popraw błędy i powtarzaj, aż przejdzie. Ich zdaniem radykalnie podnosi to jakość wyników. Samo sprawdzenie nie musi być kodem. W pierwszym przykładzie to po prostu poradnik stylu: Claude pisze szkic, przegląda go wobec zasad, notuje każdy problem wraz z punktem, który łamie, poprawia i przegląda ponownie — a kończy dopiero, gdy przechodzi wszystko. W twoim wydaniu tym „poradnikiem stylu” może być dokument głosu marki.
I to jest mechanizm, w którym skill zaczyna się sam doskonalić. Gdy szkic obleje z powodu, którego jeszcze nie ma w twoim dokumencie, każ Claude’owi na koniec przebiegu zaproponować nową zasadę. Ty ją zatwierdzasz, wpada do dokumentu, a kolejny przebieg jest już sprawdzany także pod jej kątem. Przewodnik Fable 5 mówi wprost, że model dobrze radzi sobie z aktualizowaniem skilli na podstawie tego, czego nauczył się podczas zadania.
Ostatnia zasada: przenośność
Może dziś pracujesz sam, ale co się stanie, gdy kolega z zespołu zainstaluje skilla, którego używasz codziennie? W pierwszym dniu się wysypie — niemal na pewno. Tobie działa, bo pół roku temu zainstalowałeś go wraz ze wszystkimi zależnościami i bibliotekami, a potem zapomniałeś, co tam w ogóle było. Na maszynie kolegi albo w świeżej sesji kodowania tych bibliotek nie ma i trzeba je doinstalować. Reguła brzmi: nie zakładaj, że narzędzia są zainstalowane.
Zła wersja: „użyj biblioteki PDF do przetworzenia pliku”. Dobra wersja, do wstawienia w każdym skillu: „zainstaluj wymagany pakiet” plus nazwa pakietu — bo jeśli pakiet już jest, Claude po prostu pominie ten krok; jest na tyle rozsądny, że to zauważy. Przy każdym skrypcie w skillu umieść linię instalacyjną tuż obok niego. Jeśli dzielisz się skillami z zespołem albo je sprzedajesz, to jest właśnie przepaść między skillem, który u odbiorcy działa od pierwszej minuty, a takim, przy którym będziesz musiał ciągle pomagać w konfiguracji i utrzymaniu.
Zamiast puenty: układ plików bije styl pisania
Zbierzmy to w całość. Mamy spisy treści w plikach powyżej stu linii. Możliwość mieszania poziomów swobody w obrębie jednego skilla. Testowanie na modelu docelowym i odnotowanie tego w nagłówku pliku. Referencje maksymalnie jeden poziom głęboko. Checklisty. Pętle samopoprawy. Wreszcie jawnie wypisane zależności.
Zauważ, że prawie żadna z tych napraw nie dotyczyła słów wewnątrz skilla. Dlatego uważam, że jakość skilla coraz bardziej bierze się z tego, jak poukładane są jego pliki i jakie kontrole uruchamia — a coraz mniej z tego, jak pięknie napisane są instrukcje. Zwłaszcza że modele coraz lepiej radzą sobie z rozumieniem celów i dopisywaniem sobie instrukcji same.
W opisie filmu zostawiłem darmowy prompt do audytu: przepuszcza skilla przez wszystkie dziewięć omawianych punktów i pokazuje, co by zmienił, zanim cokolwiek faktycznie zmieni. A w następnym odcinku opowiem o zmianach w zaleceniach Anthropica dotyczących promptów — w ostatnich sześciu miesiącach zmieniły się drastycznie i przyjdzie ci zaktualizować wszystkie prompty w swoich skillach. Do usłyszenia.