Jak testujemy skille Claude: protokół SkillProof

Cała ta strona zaczęła się od skilla, który nic nie robił. Pod koniec 2025 roku skill produktywnościowy krążył po X z kilkoma tysiącami gwiazdek za sobą. Zainstalowaliśmy go, zrestartowaliśmy Claude Code, wpisaliśmy dokładny przypadek użycia z README, i patrzyliśmy, jak Claude odpowiada tak, jakby skill nie istniał. Sprawdziliśmy katalog: pliki obecne, frontmatter poprawny. Wpisaliśmy inne sformułowanie. Nic. Skill nie odpalił się ani razu przez czterdzieści minut, i nic na stronie repo tego nie zapowiadało. Gwiazdki mierzą, czy README jest ekscytujące. Nic nie mówią o tym, czy folder pod spodem działa.

Tamten wieczór zostawił pytanie, którego nie mogliśmy odpuścić: jeśli skill z taką uwagą może być martwy na starcie, jak wygląda reszta ekosystemu? Więc zaczęliśmy instalować skille na czystej maszynie i zapisywać, co się dzieje. Odpowiedź, udokumentowana w naszych danych o awariach, jest taka, że mniej więcej połowa skilli społecznościowych zawodzi, zanim komukolwiek pomoże. Ten wpis to druga strona tego odkrycia: dokładny protokół stojący za każdym werdyktem na SkillProof, na tyle szczegółowy, żebyś mógł uruchomić go na własnym skillu przed wysłaniem.

Protokół, krok po kroku

Pełny test zajmuje od 45 minut do kilku dni, zależnie od kategorii. Skill do dokumentów udowadnia się w jednym posiedzeniu; skill do cotygodniowego przeglądu musi przetrwać prawdziwy tydzień. Tak czy inaczej kroki są te same, a kolejność ma znaczenie, bo każdy warunkuje następny. Nie ma sensu oceniać wyniku skilla, który nigdy się nie wyzwala.

Krok 0: świeże środowisko

Każdy test zaczyna się na profilu maszyny z pustym katalogiem skilli i domyślnymi ustawieniami Claude Code. To brzmi jak ceremoniał, dopóki nie oszczędzi ci za pierwszym razem. Skille wchodzą w interakcje: jeden może wyglądać, jakby działał, bo inny skill na maszynie po cichu wykonuje ciężką robotę. Nauczyliśmy się tego, testując skill do propozycji na maszynie, która miała już zainstalowany skill docx. Wynik wyglądał świetnie. Na czystym profilu połowa wartości zniknęła, bo to skill do dokumentów produkował dopracowany plik .docx przez cały czas.

Krok 1: instalacja według instrukcji autora

Otwieramy README repo i wykonujemy je dosłownie. Nie „ustalamy, jak to zainstalować". Robimy dokładnie to, co napisał autor, wraz z literówkami, bo to jest to, co zrobi każdy prawdziwy użytkownik. Jeśli komendy faktycznie tworzą ~/.claude/skills/name/name/SKILL.md, jeden katalog za głęboko, to jest nieudana instalacja, nawet jeśli każdy znający format naprawiłby to w dziesięć sekund. My też moglibyśmy to naprawić. Chodzi o to, że nowicjusz podążający za instrukcjami o 23:00 nie może, i dojdzie do wniosku, że skille Claude są zepsute, zamiast że jedna ścieżka była zła.

Wszystko, o czym README nie wspomina, liczy się na jego niekorzyść: niezadeklarowane zależności, instrukcje napisane dla wersji Claude Code sprzed dwóch wydań. Notujemy czas od klonowania do działającego skilla, i czy musieliśmy opuścić README, żeby tam dotrzeć.

Krok 2: bateria wyzwalaczy

Zainstalowany skill, który nigdy się nie aktywuje, to dekoracja. Więc przed jakimkolwiek prawdziwym zadaniem uruchamiamy baterię pięciu promptów: trzy sformułowania, które powinny odpalić skill, i dwa, które nie powinny.

Trzy pozytywne prompty są celowo zróżnicowane. Dla skilla do dokumentów Word: „zamień te notatki w raport, który mogę wysłać jako .docx", potem „napisz szkic tej umowy jako plik Word", potem coś bardziej pośredniego jak „potrzebuję tego sformatowanego właściwie do przeglądu prawnego". Pierwszy to własny przykład z README. Drugi używa innego słownictwa dla tej samej intencji. Trzeci nigdy nie nazywa formatu pliku, co testuje, czy opis pokrywa zadanie, a nie tylko słowa kluczowe.

Dwa negatywne prompty sprawdzają nadmierne wyzwalanie, tę awarię, o której nikt nie mówi. Skill do dokumentów, który odpala się przy „podsumuj ten dokument" (wklejony tekst, żaden plik nie jest zaangażowany), wstrzykuje instrukcje do rozmów, gdzie nie mają czego szukać, i płacisz za to kontekstem i dziwnymi wynikami. Skill, który odpala się na wszystko, jest gorszy od takiego, który nie odpala się na nic; przynajmniej ten martwy łatwo zdiagnozować.

Pięć na pięć to czysty wynik. Poniżej tego zapisujemy, które sformułowania zawiodły; wzorzec zwykle jest diagnostyczny. Skill, który odpala się tylko na dokładnym sformułowaniu z README, ma opis napisany jako slogan zamiast jako specyfikacja wyzwalacza.

Krok 3: przebieg bazowy

To jest serce testu i powód, dla którego protokół istnieje. Bierzemy prawdziwe zadanie z domeny skilla i uruchamiamy je dwa razy: raz z zainstalowanym skillem, raz na nagim modelu z identycznym promptem. Potem porównujemy.

Porównanie to jedyne pytanie, które ma znaczenie: czy wynik ze skillem jest wyraźnie lepszy niż to, co Claude produkuje i tak? Claude już jest dobry w wielu rzeczach. Skill „poprawy pisania" konkurujący z modelem, który dobrze pisze, musi wykazać różnicę, a większość nie potrafi. Kiedy testowaliśmy frontend-design, uruchomiliśmy ten sam brief landing page'a oboma sposobami. Wersja ze skillem miała prawdziwą skalę typograficzną i celową paletę; baza miała neonowo-gradientowy wygląd, który każdy rozpoznaje. Ta różnica zarobiła 10. Kiedy dwa wyniki trudno odróżnić, skill nie ma powodu istnieć, jakkolwiek przyjemne byłoby jego README.

Prawdziwe dane wejściowe mają tak samo duże znaczenie jak porównanie. Arkusz kalkulacyjny ze zniekształconymi nagłówkami, folder faktur, gdzie jedna trzecia plików to skany. Wydajność na danych demo to marketing; testujemy wtorkowo-popołudniową wersję zadania, bo to jest wersja, którą mu przekażesz.

Krok 4: weryfikacja krzyżowa dokumentacji

Na koniec czytamy cały SKILL.md i wszystko, do czego się odwołuje, potem porównujemy twierdzenia z tym, co zaobserwowaliśmy. Czy README obiecuje możliwości, których skill nie ma? Czy ujawnia swoje zależności? Czy jest coś ukrytego w środku pliku, co wygląda mniej jak wskazówka do zadania, a bardziej jak prompt injection, albo wywołanie sieciowe, o którym dokumentacja nigdy nie wspomina?

Ten krok flaguje może jeden skill na dziesięć, ale te, które łapie, mają największe znaczenie. Skill to tekst wstrzykiwany do kontekstu twojego modelu. Przeczytanie każdej linii przed zaufaniem to minimum, i traktujemy tę lekturę jako część produktu.

Cztery oceny, i dlaczego wynik liczy się podwójnie

Każdy przetestowany skill dostaje cztery liczby, opisane na naszej stronie metodologii. Krótka wersja, z tym, co odróżnia 5 od 2:

Instaluje się czysto (na 5). 5 oznacza, że nowicjusz podążający za README dostaje działający skill na świeżej konfiguracji bez żadnych objazdów. 2 oznacza, że w końcu doprowadziliśmy to do działania dzięki wiedzy, której README nie zawiera: naprawianiu ścieżek, czytaniu źródła. Skill może być doskonały; drzwi do niego są zepsute.

Wyzwala się niezawodnie (na 5). 5 to pięć na pięć w baterii: wszystkie trzy pozytywne sformułowania odpalają, oba negatywne milczą. 2 odpala się tylko na sformułowaniu wyjętym z własnego README, albo odpala się na niepowiązanej pracy, albo jedno i drugie. Częsta przyczyna w obu kierunkach: pole opisu napisane, żeby zaimponować ludziom, zamiast żeby poinformować model.

Wynik vs. baza (na 10). 9 albo 10 oznacza, że wynik ze skillem jest niewątpliwie lepszy na prawdziwym zadaniu, ten rodzaj różnicy, który zauważysz bez tabeli wyników. 4 oznacza, że musieliśmy mrużyć oczy. 2 oznacza, że przebieg bazowy był tak samo dobry albo lepszy, co zdarza się częściej, niż autorzy chcieliby wierzyć.

Dokumentacja i uczciwość (na 5). 5 oznacza, że README pasuje do rzeczywistości: dokładne twierdzenia, zadeklarowane zależności, nic nieujawnionego. 2 oznacza obietnice, których skill nie może dotrzymać, albo zachowanie, o którym dokumentacja nigdy nie wspomina.

Wynik jest oceniany na 10, podczas gdy wszystko inne na 5, i ta waga jest celowa: jakość wyniku jest warta tyle, co wszystkie inne kryteria razem wzięte. Problemy z instalacją mają obejścia. Problemy z wyzwalaniem można załatać, edytując jedno pole opisu. Ale skill, którego wynik nie bije bazy, jest niemożliwy do naprawienia w jakikolwiek sposób, który ma znaczenie. Inne oceny mierzą, czy możesz dotrzeć do wartości. Ocena wyniku mierzy, czy w ogóle jakaś istnieje.

Dwa testy z dziennika: 24 i 17

Liczby znaczą więcej z dołączonymi testami. Oto po jednym z każdego końca opublikowanego zakresu.

Systematic-debugging, z kolekcji Superpowers Jesse'go Vincenta, zdobył 24 na 25: instalacja 5, wyzwalanie 5, wynik 9, dokumentacja 5. Instalacja to dwie komendy plugin, które zadziałały dokładnie tak, jak napisano, a bateria wyzwalaczy poszła pięć na pięć. Przebieg bazowy to część, którą wciąż wspominamy w rozmowach: daliśmy mu warunek wyścigu, który bazowy Claude już „naprawił" trzy razy, każda naprawa to zgadywanie przesuwające objaw. Z załadowanym skillem Claude przestał zgadywać. Sformułował hipotezę, napisał test, żeby ją sprawdzić, obejrzał, jak test zawodzi, i przeszedł tę pętlę, aż znalazł prawdziwą przyczynę źródłową. Dokumentacja obiecuje zdyscyplinowany proces debugowania, i dokładnie to obserwowaliśmy. Jest stałym punktem naszej strony programistycznej od tego czasu.

Proposal-builder, skill społecznościowy, zdobył 17: instalacja 3, wyzwalanie 4, wynik 7, dokumentacja 3. Pierwszy przebieg był awarią w zwykłym sensie. Od razu, na czystym profilu, nie dostarczył tego, co obiecuje jego README: dopracowany wynik .docx po cichu zależy od posiadania zainstalowanego skilla docx, a markowe formatowanie zależy od szablonu propozycji, o którym README ledwo wspomina. Postępuj według instrukcji dosłownie, jak zrobiłby nowy użytkownik, a dostaniesz ścianę markdownu tam, gdzie powinna być propozycja. Kiedy zainstalowaliśmy towarzyszący skill i skonfigurowaliśmy szablon, złożył naprawdę użyteczną, markową propozycję z notatek z rozmowy i cennika. Możliwość jest prawdziwa. Ścieżka do niej nie jest w README, a oceny mówią dokładnie to, aż do brakujących kroków wypisanych w notatkach testu.

Ta luka to coś, czego liczba gwiazdek nie widzi. Oba repo wyglądają kompetentnie z zewnątrz. Jedno działa w momencie, gdy podążasz za jego własnymi instrukcjami. Drugie działa tylko, jeśli już wiesz, o czym zapomniało ci powiedzieć.

Co oznacza werdykt

Oceny sumują się do jednego z trzech werdyktów. Środkowy myli ludzi, więc bądźmy precyzyjni.

Zaliczony oznacza, że skill zainstalował się według instrukcji autora, wyzwolił się poprawnie, i pobił bazę bez skilla na prawdziwym zadaniu. Z 73 skilli w katalogu 35 nosi ten werdykt.

Działa po konfiguracji oznacza, że skill dostarcza prawdziwą wartość, ale nie od razu. Potrzebuje towarzyszącego skilla albo kroku konfiguracyjnego najpierw, a wpis mówi, jakiego. Dziesięć skilli siedzi tutaj, i werdykt nie jest eufemizmem porażki. Niektóre skille wymagają konfiguracji z założenia: skill wytycznych marki ma być bezużyteczny, dopóki nie wypełnisz swojej palety i głosu, a skill przeglądu pipeline'u nie może przejrzeć pipeline'u, którego nie widzi. Werdykt istnieje, żebyś wiedział, co kupuje uczciwe pół godziny konfiguracji, zanim je wydasz.

W kolejce testów oznacza, że wpisaliśmy skill na listę, bo wygląda obiecująco, i nie skończyliśmy go testować. Żaden werdykt nie jest sugerowany w żadną stronę; 28 skilli czeka. Skille, które zawodzą testy całkowicie, też nie dostają cichego usunięcia: notatki testu mówią, co uruchomiliśmy i co się zepsuło, bo udokumentowana porażka jest bardziej użyteczna niż luka w katalogu.

Ponowne testowanie, bo Claude wciąż się zmienia

Werdykt to migawka, a grunt pod nim się porusza. Skille siedzą na wierzchu modelu, a modele są aktualizowane. Opis, który niezawodnie się wyzwalał w jednym wydaniu Claude Code, może zacząć zawodzić w następnym, bo wyzwalanie zależy od tego, jak model czyta opisy, a to czytanie się zmienia. Dryf nie jest hipotetyczny; widzieliśmy, jak niezawodny skill zaczął ignorować jedno ze swoich trzech pozytywnych sformułowań po wydaniu, bez zmiany ani jednego znaku w skillu.

Więc każdy wpis nosi datę testu i wersję Claude Code, a większe wydania wracają całą listę zaliczonych do kolejki retestów, najpierw najczęściej instalowane skille. Kiedy werdykt się zmienia, wpis się zmienia. Starzejąca się data testu to twoja wskazówka, żeby ważyć werdykt odpowiednio; to uczciwy koszt testowania na ruchomej platformie.

Czego nie testujemy, i gdzie metoda jest słaba

Protokół, którego nie można skrytykować, to protokół, którego nikt nie opisał uczciwie. Znane ograniczenia:

Przykładowe zadania nie mogą pokryć każdego zastosowania. Uruchamiamy jedno albo dwa prawdziwe zadania na skill, wybrane jako reprezentatywne, a skill, który błyszczy na naszym arkuszu z 40 000 wierszy, może wciąż potknąć się na twoim z 400 000.

Ocena dokumentacji opiera się na osądzie jednego testera. Czytanie SKILL.md pod kątem uczciwości jest bliższe redakcji niż pomiarowi, i dwóch starannych czytelników może ważyć to samo niejasne zdanie inaczej. Publikujemy notatki testowe częściowo po to, żebyś mógł nas zaudytować.

Nie testujemy na skalę ani w długim horyzoncie czasowym. Jedna czysta maszyna, dni, nie miesiące. Powolna degradacja i workflow angażujące kilka skilli naraz są poza zasięgiem metody na razie.

Przegląd bezpieczeństwa to lektura, nie audyt. Sprawdzamy niezadeklarowane wywołania sieciowe i instrukcje przypominające prompt injection, ale zdeterminowany zły aktor mógłby przemycić coś obok ręcznej lektury. Traktuj naszą ocenę dokumentacji jako filtr, i miej się na baczności przy wszystkim, co dotyka danych uwierzytelniających.

A sama baza się porusza. „Bije nagiego Claude" oznacza nagiego Claude w dniu testu; wraz z poprawą modelu bazowego niektóre zaliczone skille zobaczą swoją różnicę kurczącą się w stronę zera. Kolejny powód, dla którego retestowanie nie jest opcjonalne.

Uruchamianie protokołu na własnym skillu

Jeśli zamierzasz opublikować skill, skondensowana wersja tego zajmuje około godziny i stawia cię przed połową ekosystemu.

1. Świeży profil. Pusty katalog skilli, domyślne ustawienia. Twoja codzienna maszyna ukrywa twoje błędy.
2. Instaluj tylko z własnego README. Lepiej: daj README komuś, kto nigdy nie widział repo, i patrz. Każde pytanie, które zada, to brakujące zdanie.
3. Uruchom baterię pięciu promptów. Trzy sformułowania, które powinny odpalić, w tym jedno, które nigdy nie używa twoich słów kluczowych, plus dwa sąsiednie prompty, które nie powinny. Napraw pudła, przepisując pole opisu, nie dodając zastrzeżeń do README.
4. Zrób porównanie bazowe. To samo zadanie, ze skillem i bez. Jeśli nie umiesz odróżnić wyników, przemyśl, do czego skill służy, zanim go opublikujesz.
5. Przeczytaj ponownie swój SKILL.md jako sceptyk. Każde twierdzenie, którego nie możesz wykazać, wytnij. Każdą zależność, zadeklaruj.
6. Zlintuj format. Błędy frontmatteru to najbardziej możliwa do uniknięcia klasa awarii, jaką widzimy, a walidator łapie je w kilka sekund.

FAQ

Jak długo trwa przetestowanie skilla Claude?

Skondensowany autotest zajmuje około godziny. Nasz pełny protokół trwa 45 minut dla prostego skilla do dokumentów i do tygodnia dla skilli, których wartość widać dopiero z czasem, jak skille do cotygodniowego przeglądu. Bateria wyzwalaczy zajmuje minuty; porównanie bazowe to miejsce, gdzie idą godziny.

Czy mogę przetestować skill bez drugiej maszyny?

Tak. Potrzebujesz czystego profilu, nie czystego sprzętu. Skieruj Claude Code na pusty katalog skilli (albo odsuń swój na bok), a dostaniesz izolację, która ma znaczenie: żaden inny skill nie konkuruje o wyzwalacze, żaden po cichu nie kryje testowanego.

Jaki jest najczęstszy powód, dla którego skille nie przechodzą testów?

Wynik, który nie bije bazy, przy mniej więcej 35% awarii, z zepsutymi instalacjami tuż za nim przy 30%. Awarie instalacji bolą najbardziej, bo są najtańsze do uniknięcia: autor nigdy nie podążył za własnym README na maszynie, która nie była jego.

Jak mogę zgłosić mój skill do przetestowania i wpisania na SkillProof?

Zgłoś go tutaj z linkiem do repo. Wchodzi do kolejki odkrywania, jest triażowany pod kątem trakcji i dopasowania do kategorii, potem przechodzi przez protokół z tej strony. Uruchom najpierw autotest, a twoje szanse na zaliczenie rosną, bo złapiesz te same wady, które my byśmy złapali.

Protokół nie jest sprytny. To czysta maszyna, README wzięte za słowo, pięć promptów, jedno uczciwe porównanie. To, co sprawia, że działa, to że nikt inny w tym łańcuchu nie robi nawet tyle: autorzy testują na własnych maszynach, a gwiazdki mierzą ekscytację. Luka między tymi dwoma to miejsce, gdzie żył ten martwy skill produktywnościowy z końca 2025 roku. Wciąż ją zamykamy, jedna instalacja na raz.