Jak testujeme Claude skily: protokol SkillProof

Celý web začal se skillem, který nedělal vůbec nic. Koncem roku 2025 se na X šířil produktivní skill s několika tisíci hvězdičkami. Nainstalovali jsme ho, restartovali Claude Code, napsali přesně ten use case, který byl v README, a sledovali, jak Claude odpovídá, jako by skill vůbec neexistoval. Zkontrolovali jsme adresář: soubory tam byly, frontmatter platný. Zkusili jsme jinou formulaci. Nic. Skill se za čtyřicet minut nespustil ani jednou a nic na stránce repozitáře by to nenaznačovalo. Hvězdičky měří, jestli je README poutavé. O tom, jestli funguje složka pod ním, neříkají nic.

Ten večer v nás zanechal otázku, které jsme se nezbavili: pokud může být skill s takovou pozorností mrtvý hned na startu, jak vypadá zbytek ekosystému? Tak jsme začali instalovat skilly na čistý počítač a zapisovat si, co se stane. Odpověď, zdokumentovaná v našich datech o selháních, je taková, že zhruba polovina komunitních skillů selže dřív, než komukoliv pomůže. Tento článek je druhá strana toho zjištění: přesný protokol za každým verdiktem na SkillProof, v takové podrobnosti, že si ho můžete spustit na vlastním skillu ještě předtím, než ho vydáte.

Protokol krok za krokem

Kompletní test trvá od 45 minut po několik dní, podle kategorie. Skill na dokumenty se osvědčí za jedno sezení; skill na týdenní review musí přežít skutečný týden. Ať tak či onak, kroky jsou stejné a záleží na pořadí, protože každý krok podmiňuje ten další. Nemá smysl hodnotit výstup skillu, který se vůbec nespustí.

Krok 0: čisté prostředí

Každý test začíná na profilu počítače s prázdným adresářem skillů a výchozím nastavením Claude Code. Zní to jako formalita, dokud vás to poprvé nezachrání. Skilly se navzájem ovlivňují: jeden může vypadat, že funguje, protože za něj potichu odvádí těžkou práci jiný skill v systému. Poznali jsme to při testování skillu na návrhy (proposal) na počítači, kde už byl nainstalovaný docx skill. Výstup vypadal skvěle. Na čistém profilu polovina hodnoty zmizela, protože ten skvělý .docx výstup celou dobu produkoval skill na dokumenty.

Krok 1: instalace podle vlastních instrukcí autora

Otevřeme README repozitáře a řídíme se jím doslova. Ne „zjistíme si, jak to nainstalovat." Uděláme přesně to, co autor napsal, včetně překlepů, protože přesně to udělá každý skutečný uživatel. Pokud příkazy ve skutečnosti vytvoří ~/.claude/skills/name/name/SKILL.md, tedy o jeden adresář hlouběji, je to neúspěšná instalace, i kdyby to kdokoliv znalý formátu opravil za deset vteřin. Opravit bychom to dokázali i my. Jde o to, že nováček, který to zkouší ve jedenáct večer, to nedokáže, a dojde k závěru, že Claude skilly jsou rozbité, místo aby si uvědomil, že jedna cesta byla špatně.

Cokoliv, co README nezmiňuje, se počítá v jeho neprospěch: nedeklarované závislosti, instrukce psané pro verzi Claude Code, která je o dvě vydání zpátky. Zaznamenáváme čas od naklonování po funkční skill a to, jestli jsme museli opustit README, abychom se tam dostali.

Krok 2: sada triggerů

Nainstalovaný skill, který se nikdy nespustí, je jen dekorace. Proto ještě před jakýmkoliv skutečným úkolem spouštíme sadu pěti promptů: tři formulace, které by měly skill spustit, a dvě, které by neměly.

Tři pozitivní prompty jsou záměrně různorodé. Pro skill na Word dokumenty: „proměň tyhle poznámky ve zprávu, kterou pošlu jako .docx," pak „napiš tuhle smlouvu jako Word soubor," a pak něco nepřímějšího jako „potřebuju tohle naformátovat pořádně pro právní revizi." První je vlastní příklad z README. Druhý používá jinou slovní zásobu pro stejný záměr. Třetí vůbec nejmenuje formát souboru, což testuje, jestli popis (description) pokrývá skutečný úkol, a ne jen klíčová slova.

Dva negativní prompty prověřují přehnané spouštění (overtriggering), selhání, o kterém nikdo nemluví. Skill na dokumenty, který se spustí na „shrň mi tenhle dokument" (vložený text, žádný soubor), vsune instrukce do konverzací, kam nepatří, a vy za to platíte kontextem i podivnými výstupy. Skill, který se spustí na všechno, je horší než skill, který se nespustí na nic; ten mrtvý se aspoň snadno diagnostikuje.

Pět z pěti je čistý výsledek. Pod tím si zaznamenáváme, které formulace selhaly; ten vzorec bývá diagnostický. Skill, který se spustí jen na přesné znění z README, má popis napsaný jako slogan, ne jako specifikace triggeru.

Krok 3: baseline běh

Tohle je jádro testu a důvod, proč protokol vůbec existuje. Vezmeme skutečný úkol z domény skillu a spustíme ho dvakrát: jednou s nainstalovaným skillem, jednou na holém modelu s identickým promptem. Pak porovnáme.

Srovnání je jediná otázka, na které záleží: je výstup se skillem jednoznačně lepší než to, co Claude vyprodukuje sám o sobě? Claude už je v mnoha věcech dobrý. Skill na „vylepšení psaní," který soupeří s modelem, jenž píše dobře, musí prokázat rozdíl, a většina to nedokáže. Když jsme testovali frontend-design, spustili jsme stejné zadání na landing page oběma způsoby. Verze se skillem měla skutečnou typografickou škálu a promyšlenou paletu; baseline měl ten neonově-gradientový vzhled, který každý zná. Ten rozdíl si vysloužil 10. Když jsou dva výstupy k nerozeznání, skill nemá důvod existovat, ať je jeho README sebepříjemnější.

Skutečné vstupy jsou stejně důležité jako srovnání. Tabulka s pokaženými hlavičkami, složka faktur, kde je třetina souborů naskenovaná. Výkon na demo datech je marketing; my testujeme úterní odpolední verzi té práce, protože to je verze, kterou skillu skutečně předáte.

Krok 4: kontrola dokumentace

Nakonec přečteme celý SKILL.md a všechno, na co odkazuje, a porovnáme tvrzení s tím, co jsme pozorovali. Slibuje README schopnosti, které skill nemá? Přiznává své závislosti? Je někde uprostřed souboru něco, co vypadá spíš jako prompt injection nebo síťové volání, které dokumentace vůbec nezmiňuje, než jako pokyny k úkolu?

Tenhle krok odhalí problém tak u jednoho skillu z deseti, ale ty, které odhalí, jsou nejdůležitější. Skill je text vsunutý do kontextu vašeho modelu. Přečíst každý řádek, než mu důvěřujete, je minimum, a tohle čtení považujeme za součást produktu.

Čtyři skóre a proč výstup počítá dvojnásobně

Každý testovaný skill dostane čtyři čísla, popsaná na naší stránce o metodologii. Stručně, s tím, co odlišuje 5 od 2:

Čistá instalace (z 5). 5 znamená, že nováček podle README dostane funkční skill na čistém nastavení bez oklik. 2 znamená, že jsme to nakonec zprovoznili díky znalostem, které README neobsahuje: opravou cest, čtením zdrojového kódu. Skill může být výborný; dveře k němu jsou rozbité.

Spolehlivé spouštění (z 5). 5 je pět z pěti v testovací sadě: všechny tři pozitivní formulace skill spustí, obě negativní zůstanou tiché. 2 znamená, že se spustí jen na znění opsané z vlastního README, nebo se spustí na nesouvisející práci, nebo obojí. Společná příčina v obou směrech: popisové pole napsané tak, aby zaujalo lidi, místo aby informovalo model.

Výstup vs. baseline (z 10). 9 nebo 10 znamená, že výsledek se skillem je na reálném úkolu jednoznačně lepší, takový rozdíl, který si všimnete i bez scorecard. 4 znamená, že jsme museli mhouřit oči. 2 znamená, že baseline běh byl stejně dobrý nebo lepší, což se děje častěji, než by autoři chtěli věřit.

Dokumentace a poctivost (z 5). 5 znamená, že README odpovídá realitě: přesná tvrzení, deklarované závislosti, nic zamlčeného. 2 znamená sliby, které skill nedokáže splnit, nebo chování, které dokumentace vůbec nezmiňuje.

Výstup se hodnotí z 10, zatímco všechno ostatní z 5, a tohle vážení je záměrné: kvalita výstupu má stejnou váhu jako všechna ostatní kritéria dohromady. Problémy s instalací mají řešení. Problémy se spouštěním lze opravit úpravou jednoho popisového pole. Ale skill, jehož výstup neporazí baseline, se nedá opravit žádným způsobem, na kterém by záleželo. Ostatní skóre měří, jestli se k té hodnotě dokážete dostat. Skóre výstupu měří, jestli tam vůbec nějaká hodnota je.

Dva testy z logu: 24 a 17 bodů

Čísla mají větší váhu, když k nim přidáte konkrétní testy. Tady je jeden z každého konce publikovaného rozsahu.

Systematic-debugging z kolekce Superpowers od Jesse Vincenta získal 24 z 25: instalace 5, spouštění 5, výstup 9, dokumentace 5. Instalace jsou dva plugin příkazy, které fungovaly přesně tak, jak byly napsané, a testovací sada triggerů prošla pět z pěti. Baseline běh je část, o které se ještě pořád bavíme: zadali jsme mu race condition, kterou baseline Claude už třikrát „opravil," pokaždé odhadem, který jen přesunul příznak jinam. Se zapnutým skillem Claude přestal hádat. Zformuloval hypotézu, napsal test, aby ji ověřil, sledoval, jak test selhal, a prošel tou smyčkou, dokud nenašel skutečnou hlavní příčinu. Dokumentace slibuje disciplinovaný proces ladění a přesně to jsme viděli. Od té doby je stálicí na naší stránce o programování.

Proposal-builder, komunitní skill, získal 17 bodů: instalace 3, spouštění 4, výstup 7, dokumentace 3. První běh byl selhání v tom nejobyčejnějším slova smyslu. Rovnou po instalaci, na čistém profilu, nedokázal splnit to, co slibuje jeho README: uhlazený .docx výstup potichu závisí na tom, že máte nainstalovaný docx skill, a brandovaný formát závisí na šabloně pro návrhy, kterou README sotva zmiňuje. Řiďte se instrukcemi doslova, jako nový uživatel, a dostanete stěnu markdownu tam, kde měl být návrh. Jakmile jsme nainstalovali doprovodný skill a nastavili šablonu, sestavil skutečně užitečný brandovaný návrh z poznámek z hovoru a ceníku. Ta schopnost je reálná. Cesta k ní ale není v README a skóre to přesně vystihuje, až po chybějící kroky vypsané v poznámkách z testu.

Tenhle rozdíl je to, co počet hvězdiček nevidí. Oba repozitáře vypadají zvenčí kompetentně. Jeden funguje, jakmile se řídíte jeho vlastními instrukcemi. Druhý funguje jen tehdy, když už víte, co zapomněl říct.

Co znamená verdikt

Skóre se sčítají do jednoho ze tří verdiktů. Ten prostřední lidi mate, tak si ho pojďme upřesnit.

Prošel znamená, že skill se nainstaloval podle vlastních instrukcí autora, spustil se správně a překonal baseline bez skillu na skutečném úkolu. Z 73 skillů v katalogu má tento verdikt 35.

Funguje s nastavením znamená, že skill přináší skutečnou hodnotu, ale ne hned po instalaci. Potřebuje nejdřív doprovodný skill nebo konfigurační krok a v záznamu je uvedeno který. Tady je deset skillů a tenhle verdikt není eufemismus pro selhání. Některé skilly nastavení vyžadují záměrně: skill na brand guidelines má být bezcenný, dokud nevyplníte svou paletu a tón komunikace, a skill na review pipeline nemůže zkontrolovat pipeline, kterou nevidí. Verdikt existuje proto, abyste věděli, co vám poctivá půlhodina konfigurace přinese, ještě než ji strávíte.

Ve frontě na test znamená, že jsme skill zařadili do katalogu, protože vypadá slibně, ale test jsme ještě nedokončili. Neznamená to žádný verdikt jedním ani druhým směrem; čeká 28 skillů. Skilly, které při testování vyloženě selžou, taky nemizí potichu ze seznamu: v poznámkách z testu je napsáno, co jsme spustili a co se pokazilo, protože zdokumentované selhání je pro vás užitečnější než díra v katalogu.

Opakované testování, protože Claude se pořád mění

Verdikt je snímek okamžiku a půda pod ním se hýbe. Skilly stojí na modelu a modely se aktualizují. Popis, který se spolehlivě spouštěl v jednom vydání Claude Code, se může v dalším začít chovat nespolehlivě, protože spouštění závisí na tom, jak model čte popisy, a to čtení se posouvá. Drift není hypotetický; viděli jsme, jak spolehlivý skill po vydání přestal reagovat na jednu ze svých tří pozitivních formulací, aniž by se ve skillu změnil jediný znak.

Proto každý záznam nese datum testování a verzi Claude Code, a velká vydání vrací celý seznam „prošel" zpátky do fronty na retest, nejdřív nejvíc instalované skilly. Když se verdikt změní, změní se i záznam. Stárnoucí datum testu je pro vás signál, abyste verdikt podle toho zvážili; je to poctivá cena za testování na platformě, která se neustále mění.

Co netestujeme a kde je metoda slabá

Protokol, který nejde kritizovat, je protokol, který nikdo nepopsal poctivě. Známé limity:

Vzorové úkoly nemůžou pokrýt každé použití. Spouštíme jeden nebo dva skutečné úkoly na skill, vybrané jako reprezentativní, a skill, který exceluje na naší tabulce se 40 000 řádky, může klopýtnout na vaší se 400 000 řádky. Verdikt je důkaz, nikdy záruka.

Skóre dokumentace se opírá o úsudek jednoho testera. Číst SKILL.md kvůli poctivosti je blíž editaci než měření a dva pečliví čtenáři mohou stejnou vágní větu ohodnotit jinak. Test notes publikujeme mimo jiné proto, abyste nás mohli zkontrolovat.

Netestujeme ve velkém měřítku ani na dlouhých časových horizontech. Jeden čistý počítač, dny místo měsíců. Pomalá degradace a workflow zapojující několik skillů najednou jsou zatím mimo dosah téhle metody.

Bezpečnostní kontrola je přečtení, ne audit. Kontrolujeme nedeklarovaná síťová volání a instrukce ve tvaru injection, ale odhodlaný útočník by mohl něco protlačit i přes manuální čtení. Berte naše skóre dokumentace jako filtr a u všeho, co se týká přihlašovacích údajů, mějte se pořád na pozoru.

A baseline sám se posouvá. „Poráží holého Clauda" znamená holého Clauda k datu testu; jak se základní model zlepšuje, u některých úspěšných skillů se rozdíl bude blížit k nule. Další důvod, proč retestování není volitelné.

Spuštění protokolu na vlastním skillu

Pokud se chystáte vydat skill, zjednodušená verze tohohle postupu zabere zhruba hodinu a dostane vás před polovinu ekosystému.

1. Čistý profil. Prázdný adresář skillů, výchozí nastavení. Váš každodenní počítač skrývá vaše chyby.
2. Instalace jen podle vašeho README. Ještě lépe: dejte README někomu, kdo repozitář nikdy neviděl, a sledujte ho. Každá otázka, kterou položí, je chybějící věta.
3. Spusťte sadu pěti promptů. Tři formulace, které by měly skill spustit, včetně jedné, která nikdy nepoužije vaše klíčová slova, plus dva sousední prompty, které by spustit neměly. Chyby opravujte přepsáním popisového pole, ne přidáváním výhrad do README.
4. Udělejte baseline srovnání. Stejný úkol, se skillem i bez něj. Pokud výstupy nedokážete rozeznat, promyslete si znovu, k čemu skill vlastně je, než ho vydáte.
5. Přečtěte si svůj SKILL.md znovu jako skeptik. Každé tvrzení, které nedokážete doložit, škrtněte. Každou závislost přiznejte.
6. Zkontrolujte formát linterem. Chyby ve frontmatteru jsou nejsnáz předvídatelná kategorie selhání, kterou vidíme, a validátor je odhalí za pár vteřin.

Časté dotazy

Jak dlouho trvá otestovat Claude skill?

Zjednodušený self-test zabere zhruba hodinu. Náš plný protokol trvá 45 minut u jednoduchého skillu na dokumenty a až týden u skillů, jejichž hodnota se projeví až v čase, jako jsou skilly na týdenní review. Sada triggerů zabere minuty; baseline srovnání je tam, kam jdou hodiny.

Můžu otestovat skill bez druhého počítače?

Ano. Potřebujete čistý profil, ne čistý hardware. Nasměrujte Claude Code na prázdný adresář skillů (nebo si ten svůj dočasně odložte stranou) a získáte izolaci, na které záleží: žádné jiné skilly nesoupeří o spouštění, žádný potichu nekryje ten testovaný.

Jaký je nejčastější důvod, proč skilly u testování propadnou?

Výstup, který neporazí baseline, přibližně u 35 % selhání, těsně za tím jsou rozbité instalace se 30 %. Selhání instalace bolí nejvíc, protože jim jde nejlevněji předejít: autor nikdy nevyzkoušel vlastní README na počítači, který nebyl jeho.

Jak dostanu svůj skill otestovaný a zařazený na SkillProof?

Přihlaste ho tady s odkazem na repozitář. Vstoupí do fronty na objevení, projde tříděním podle traction a shody kategorie a pak projde protokolem popsaným na téhle stránce. Spusťte si nejdřív self-test a vaše šance na verdikt „prošel" porostou, protože odhalíte stejné nedostatky, jaké bychom odhalili my.

Protokol není nic geniálního. Je to čistý počítač, README brané doslovně, pět promptů, jedno poctivé srovnání. Funguje to proto, že nikdo jiný v tom řetězci neudělá ani tohle: autoři testují na vlastních počítačích a hvězdičky měří nadšení. Mezera mezi těmi dvěma je místo, kde žil ten mrtvý produktivní skill z konce roku 2025. My ji dál zavíráme, jednu instalaci po druhé.