Hoe we Claude skills testen: het SkillProof-protocol

De hele site begon met een skill die niets deed. Eind 2025 deed een productiviteitsskill de ronde op X met een paar duizend sterren erachter. We installeerden hem, herstartten Claude Code, typten precies de use case uit de README, en zagen Claude antwoorden alsof de skill niet bestond. Controleerden de map: bestanden aanwezig, frontmatter geldig. Typten een andere formulering. Niets. De skill vuurde geen enkele keer in veertig minuten, en niets op de repo-pagina had dat voorspeld. Sterren meten of een README opwindend is. Ze zeggen niets over of de map eronder werkt.

Die avond bleef een vraag hangen die we niet konden loslaten: als een skill met zoveel aandacht dood kan aankomen, hoe ziet de rest van het ecosysteem er dan uit? Dus begonnen we skills te installeren op een schone machine en op te schrijven wat er gebeurde. Het antwoord, gedocumenteerd in onze faaldata, is dat ruwweg de helft van de community-skills faalt voordat ze iemand helpen. Deze post is de andere kant van die bevinding: het exacte protocol achter elk verdict op SkillProof, in genoeg detail dat je het op je eigen skill kunt draaien voordat je hem uitbrengt.

Het protocol, stap voor stap

Een volledige test duurt tussen 45 minuten en meerdere dagen, afhankelijk van de categorie. Een documentskill bewijst zichzelf in één zitting; een wekelijkse-review-skill moet een echte week overleven. Hoe dan ook zijn de stappen hetzelfde, en de volgorde doet ertoe, want elke stap poort de volgende. Er is geen zin in het scoren van output voor een skill die nooit triggert.

Stap 0: een verse omgeving

Elke test begint op een machineprofiel met een lege skills-map en standaard Claude Code-instellingen. Dit klinkt als ceremonie tot de eerste keer dat het je redt. Skills interacteren: één kan lijken te werken omdat een andere skill op de machine stilletjes het zware werk doet. We leerden dit door een voorstel-skill te testen op een machine die al de docx-skill had geïnstalleerd. De output zag er geweldig uit. Op een schoon profiel verdween de helft van de waarde, want de documentskill had de gepolijste .docx al die tijd geproduceerd.

Stap 1: installeer volgens de eigen instructies van de auteur

We openen de README van de repo en volgen hem letterlijk. Niet "we bedenken hoe we het installeren." We doen exact wat de auteur schreef, typefouten en al, want dat is wat elke echte gebruiker zal doen. Als de commando's daadwerkelijk ~/.claude/skills/naam/naam/SKILL.md produceren, één map te diep, is dat een mislukte installatie, ook al zou iedereen die het formaat kent het in tien seconden kunnen repareren. Wij zouden het ook kunnen repareren. Het punt is dat de nieuwkomer die om 23:00 meevolgt dat niet kan, en zal concluderen dat Claude skills kapot zijn in plaats van dat één pad verkeerd was.

Alles wat de README niet vermeldt telt tegen hem: onaangekondigde dependencies, instructies geschreven voor een Claude Code-versie twee releases geleden. We noteren de tijd van clone tot werkende skill, en of we de README moesten verlaten om er te komen.

Stap 2: de trigger-batterij

Een geïnstalleerde skill die nooit activeert is decoratie. Dus voor elke echte taak draaien we een batterij van vijf prompts: drie formuleringen die zouden moeten vuren, twee die dat niet zouden moeten.

De drie positieve prompts zijn bewust gevarieerd. Voor een Word-documentskill: "zet deze notities om in een rapport dat ik als .docx kan versturen," dan "stel dit contract op als een Word-bestand," dan iets schuins zoals "ik heb dit netjes geformatteerd nodig voor juridische review." De eerste is het eigen voorbeeld van de README. De tweede gebruikt andere woordenschat voor dezelfde intentie. De derde noemt nooit het bestandsformaat, wat test of de beschrijving de taak dekt in plaats van de trefwoorden.

De twee negatieve prompts onderzoeken overtriggering, de faalmodus waar niemand over praat. Een documentskill die vuurt wanneer je vraagt "vat dit document samen" (geplakte tekst, geen bestand betrokken) injecteert instructies in gesprekken waar ze niet horen, en je betaalt daarvoor in context en in vreemde outputs. Een skill die op alles vuurt is erger dan een die op niets vuurt; de dode is tenminste makkelijk te diagnosticeren.

Vijf van de vijf is een schoon resultaat. Onder dat noteren we welke formuleringen faalden; het patroon is meestal diagnostisch. Een skill die alleen vuurt op de exacte bewoording van de README heeft een beschrijving geschreven als een tagline in plaats van een triggerspecificatie.

Stap 3: de baseline-run

Dit is het hart van de test en de reden dat het protocol bestaat. We nemen een echte taak uit het domein van de skill en draaien hem twee keer: één keer met de skill geïnstalleerd, één keer op het naakte model met dezelfde prompt. Dan vergelijken we.

De vergelijking is de enige vraag die telt: is de output met skill duidelijk beter dan wat Claude toch al produceert? Claude is al goed in veel dingen. Een "schrijfverbetering"-skill die concurreert tegen een model dat goed schrijft moet een delta aantonen, en de meeste kunnen dat niet. Toen we frontend-design testten, draaiden we dezelfde landingspagina-brief beide manieren. De versie met skill had een echte typeschaal en een intentioneel palet; de baseline had de neon-gradient-look die iedereen herkent. Die delta verdiende een 10. Wanneer de twee outputs moeilijk uit elkaar te houden zijn, heeft de skill geen reden om te bestaan, hoe aangenaam zijn README ook is.

Echte inputs doen er evenveel toe als de vergelijking. Een spreadsheet met misvormde headers, een facturenmap waar een derde van de bestanden scans zijn. Demo-data-prestatie is marketing; wij testen de dinsdagmiddag-versie van de klus, want dat is de versie die je hem geeft.

Stap 4: de documentatiecontrole

Als laatste lezen we de hele SKILL.md en alles waar hij naar verwijst, en vergelijken de claims met wat we observeerden. Belooft de README capaciteiten die de skill niet heeft? Onthult hij zijn dependencies? Is er iets diep in het bestand dat minder op taakbegeleiding lijkt en meer op prompt-injectie, of een netwerkaanroep die de docs nooit vermelden?

Deze stap markeert misschien één skill op tien, maar degene die het vangt tellen het meest. Een skill is tekst geïnjecteerd in de context van je model. Elke regel lezen voordat je hem vertrouwt is het minimum, en we behandelen die leesbeurt als deel van het product.

De vier scores, en waarom output dubbel telt

Elke geteste skill krijgt vier cijfers, beschreven op onze methodologiepagina. De korte versie, met wat een 5 van een 2 scheidt:

Installeert schoon (op 5). Een 5 betekent dat een nieuwkomer die de README volgt een werkende skill krijgt op een verse setup zonder omwegen. Een 2 betekent dat we hem uiteindelijk werkend kregen via kennis die de README niet bevat: paden repareren, de broncode lezen. De skill kan uitstekend zijn; de deur ernaartoe is kapot.

Triggert betrouwbaar (op 5). Een 5 is vijf van de vijf op de batterij: alle drie positieve formuleringen vuren, beide negatieven blijven stil. Een 2 vuurt alleen op bewoording overgenomen van zijn eigen README, of vuurt op ongerelateerd werk, of beide. Vaak oorzaak in beide richtingen: een beschrijvingsveld geschreven om mensen te imponeren in plaats van het model te informeren.

Output vs. baseline (op 10). Een 9 of 10 betekent dat het resultaat met skill onmiskenbaar beter is op een echte taak, het soort verschil dat je zonder scorekaart zou opmerken. Een 4 betekent dat we moesten turen. Een 2 betekent dat de baseline-run net zo goed of beter was, wat vaker gebeurt dan auteurs zouden willen geloven.

Docs en eerlijkheid (op 5). Een 5 betekent dat de README overeenkomt met de realiteit: accurate claims, aangekondigde dependencies, niets onthuld. Een 2 betekent beloftes die de skill niet kan waarmaken of gedrag dat de docs nooit vermelden.

Output wordt gescoord op 10 terwijl al het andere op 5 is, en die weging is opzettelijk: outputkwaliteit weegt evenveel als de andere criteria samen. Installatieproblemen hebben workarounds. Triggerproblemen kunnen gepatcht worden door één beschrijvingsveld te bewerken. Maar een skill wiens output de baseline niet verslaat is onrepareerbaar op elke manier die telt. De andere scores meten of je de waarde kunt bereiken. De outputscore meet of er waarde is.

Twee tests uit het logboek: een 24 en een 17

Cijfers betekenen meer met de tests eraan vast. Hier is er een van elk uiterste van het gepubliceerde bereik.

Systematic-debugging, uit Jesse Vincents Superpowers-collectie, scoorde 24 van 25: installatie 5, trigger 5, output 9, docs 5. De installatie is twee plugin-commando's die precies werkten zoals geschreven, en de trigger-batterij ging vijf van de vijf. De baseline-run is het deel dat we nog steeds in gesprekken aanhalen: we gaven hem een race condition die baseline Claude al drie keer had "opgelost," elke fix een gok die het symptoom verplaatste. Met de skill geladen stopte Claude met gokken. Hij formuleerde een hypothese, schreef een test om hem te controleren, zag de test falen, en liep die lus af tot hij de echte hoofdoorzaak vond. De docs beloven een gedisciplineerd debugproces en dat is precies wat we zagen gebeuren. Het is sinds die tijd een vaste waarde op onze coding-pagina.

Proposal-builder, een community-skill, scoorde 17: installatie 3, trigger 4, output 7, docs 3. De eerste run was een mislukking in de gewone zin. Uit de doos, op een schoon profiel, kon hij niet leveren wat zijn README belooft: de gepolijste .docx-output hangt stilletjes af van het geïnstalleerd hebben van de docx-skill, en de gebrandmerkte opmaak hangt af van een voorsteltemplate die de README nauwelijks vermeldt. Volg de instructies letterlijk, zoals een nieuwe gebruiker zou doen, en je krijgt een muur markdown waar een voorstel zou moeten staan. Zodra we de begeleidende skill installeerden en een template opzetten, stelde hij een echt bruikbaar gebrandmerkt voorstel samen uit gespreksnotities en prijsstelling. De capaciteit is echt. Het pad ernaartoe staat niet in de README, en de scores zeggen precies dat, tot en met de ontbrekende stappen uitgeschreven in de testnotities.

Dat gat is wat het aantal sterren niet kan zien. Beide repo's zien er van buiten competent uit. De ene werkt zodra je zijn eigen instructies volgt. De andere werkt alleen als je al weet wat hij vergat te vertellen.

Wat een verdict betekent

De scores rollen op tot een van drie verdicten. Het middelste verwart mensen, dus laten we precies zijn.

Pass betekent dat de skill installeerde volgens de eigen instructies van de auteur, correct triggerde, en de baseline zonder skill versloeg op een echte taak. Van de 73 skills in de catalogus dragen 35 dit verdict.

Werkt met setup betekent dat de skill echte waarde levert, maar niet uit de doos. Hij heeft een begeleidende skill of een configuratiestap nodig eerst, en de vermelding zegt welke. Tien skills zitten hier, en het verdict is geen eufemisme voor falen. Sommige skills vereisen setup naar ontwerp: een merkrichtlijnen-skill hoort nutteloos te zijn tot je je palet en stem invult, en een pipeline-review-skill kan geen pipeline reviewen die hij niet kan zien. Het verdict bestaat zodat je weet wat een eerlijk half uur configuratie oplevert voordat je het besteedt.

In testwachtrij betekent dat we de skill vermeldden omdat hij veelbelovend lijkt en we het testen nog niet hebben afgerond. Geen verdict is geïmpliceerd in beide richtingen; 28 skills wachten. Skills die het testen ronduit niet doorstaan krijgen ook geen stille verwijdering: de testnotities zeggen wat we draaiden en wat er brak, want een gedocumenteerd falen is nuttiger voor jou dan een gat in de catalogus.

Hertesten, want Claude blijft veranderen

Een verdict is een momentopname, en de grond eronder beweegt. Skills zitten bovenop een model, en modellen worden bijgewerkt. Een beschrijving die betrouwbaar triggerde in de ene Claude Code-release kan in de volgende beginnen te missen, want triggering hangt af van hoe het model beschrijvingen leest, en die lezing verschuift. Drift is niet hypothetisch; we hebben een betrouwbare skill een van zijn drie positieve formuleringen zien negeren na een release, zonder dat er één teken van de skill veranderde.

Dus elke vermelding draagt een testdatum en de Claude Code-versie, en grote releases zetten de hele pass-lijst terug in de hertest-wachtrij, meest-geïnstalleerde skills eerst. Wanneer een verdict verandert, verandert de vermelding. Een verouderende testdatum is je signaal om het verdict dienovereenkomstig te wegen; het is de eerlijke prijs van testen tegen een bewegend platform.

Wat we niet testen, en waar de methode zwak is

Een protocol dat je niet kunt bekritiseren is een protocol dat niemand eerlijk beschreven heeft. De bekende grenzen:

Voorbeeldtaken kunnen niet elk gebruik dekken. We draaien één of twee echte taken per skill, gekozen om representatief te zijn, en een skill die schittert op onze spreadsheet van 40.000 rijen kan nog steeds struikelen op jouw versie van 400.000 rijen. Het verdict is bewijs, nooit een garantie.

De documentatiescore leunt op het oordeel van één tester. Een SKILL.md lezen voor eerlijkheid ligt dichter bij redigeren dan bij meten, en twee zorgvuldige lezers kunnen dezelfde vage zin verschillend wegen. We publiceren testnotities deels zodat je ons kunt controleren.

We testen niet op schaal of over lange horizonten. Eén schone machine, dagen in plaats van maanden. Langzame degradatie en workstromen met meerdere skills tegelijk vallen momenteel buiten het bereik van de methode.

Beveiligingsreview is een leesbeurt, geen audit. We controleren op onaangekondigde netwerkaanroepen en injectie-vormige instructies, maar een vastberaden kwaadwillende zou iets langs een handmatige leesbeurt kunnen krijgen. Behandel onze docs-score als een filter, en blijf op je hoede voor alles dat credentials aanraakt.

En de baseline zelf beweegt. "Verslaat naakte Claude" betekent naakte Claude op de testdatum; naarmate het basismodel verbetert, zullen sommige geslaagde skills hun delta naar nul zien krimpen. Nog een reden waarom hertesten niet optioneel is.

Het protocol draaien op je eigen skill

Als je op het punt staat een skill te publiceren, kost een verkorte versie hiervan ongeveer een uur en zet je voor op de helft van het ecosysteem.

1. Vers profiel. Lege skills-map, standaardinstellingen. Je dagelijkse machine verbergt je bugs.
2. Installeer alleen vanuit je README. Beter: geef de README aan iemand die de repo nog nooit heeft gezien en kijk toe. Elke vraag die ze stellen is een ontbrekende zin.
3. Draai de vijf-prompt-batterij. Drie formuleringen die zouden moeten vuren, inclusief één die nooit je trefwoorden gebruikt, plus twee aangrenzende prompts die dat niet zouden moeten. Repareer missers door het beschrijvingsveld te herschrijven, niet door README-voorbehouden toe te voegen.
4. Doe de baseline-vergelijking. Dezelfde taak, met en zonder je skill. Als je de outputs niet uit elkaar kunt houden, herbedenk waarvoor de skill dient voordat je publiceert.
5. Herlees je SKILL.md als scepticus. Elke claim die je niet kunt aantonen, schrap. Elke dependency, meld.
6. Lint het formaat. Frontmatter-fouten zijn de meest voorkombare faalklasse die wij zien, en een validator vangt ze in seconden.

FAQ

Hoe lang duurt het om een Claude skill te testen?

De verkorte zelftest duurt ongeveer een uur. Ons volledige protocol duurt 45 minuten voor een eenvoudige documentskill en tot een week voor skills waarvan de waarde zich alleen over tijd toont, zoals wekelijkse-review-skills. De trigger-batterij duurt minuten; de baseline-vergelijking is waar de uren naartoe gaan.

Kan ik een skill testen zonder een tweede machine?

Ja. Je hebt een schoon profiel nodig, geen schone hardware. Richt Claude Code op een lege skills-map (of verplaats je eigen map opzij) en je krijgt de isolatie die telt: geen andere skills die om triggers concurreren, geen die stilletjes de skill onder test afdekken.

Wat is de meest voorkomende reden dat skills de test niet doorstaan?

Output die de baseline niet verslaat, bij ruwweg 35% van de mislukkingen, met gebroken installaties dicht erachter op 30%. De installatiefouten steken het meest omdat ze het goedkoopst te voorkomen zijn: de auteur volgde zijn eigen README nooit op een machine die niet van hem was.

Hoe krijg ik mijn skill getest en vermeld op SkillProof?

Dien hem hier in met de repo-link. Hij komt in de ontdekkingswachtrij, wordt getrieerd op traction en categoriefit, en doorloopt dan het protocol op deze pagina. Draai eerst de zelftest en je kansen op een pass-verdict gaan omhoog, want je vangt dezelfde defecten die wij zouden vangen.

Het protocol is niet slim. Het is een schone machine, een README op zijn woord genomen, vijf prompts, één eerlijke vergelijking. Wat het laat werken is dat niemand anders in de pijplijn zelfs dat veel doet: auteurs testen op hun eigen machines, en sterren meten opwinding. Het gat tussen die twee is waar die dode productiviteitsskill uit eind 2025 leefde. We blijven het dichten, één installatie tegelijk.