Voorbij de Hype: We draaiden 1416 Claude Skills om het werkende aantal te vinden

U heeft de getallen waarschijnlijk gezien: koppen en directories die adverteren met meer dan 23.000 Claude skills die beschikbaar zijn voor installatie. Dit cijfer suggereert een groot, volwassen ecosysteem van tools die de capaciteiten van het basismodel kunnen uitbreiden. Het is een indrukwekkend aantal, maar het roept een kritische technische vraag op: wat betekent 'beschikbaar' eigenlijk? In de meeste gevallen betekent het dat er een SKILL.md manifest is gevonden in een publieke code repository. Het is een telling gebaseerd op het vinden van bestanden, niet op functionele verificatie.

Deze aanpak is eenvoudig, schaalbaar en uiteindelijk misleidend. Het zegt niets over of een skill zal installeren, foutloos zal draaien, of zijn geadverteerde functie effectief zal uitvoeren. Het vertelt niet of het een verlaten project is, een gebroken proof-of-concept, of dat het zelfs slechter presteert dan wanneer men geen skill gebruikt.

Bij SkillProof hanteren we een andere aanpak. We tellen geen repositories; we installeren en voeren skills uit tegen een gestandaardiseerde set van real-world taken. Dit artikel presenteert onze bevindingen van het testen van 1416 skills. Het is een direct, door data ondersteund antwoord op de vraag hoeveel Claude code skills er daadwerkelijk werken, en een onderzoek of Claude skill-marktplaatsen betrouwbare bronnen zijn voor productieklare tools.

De Fout in het Tellen van Bestanden

Het fundamentele probleem met een telling van 23.000+ skills is dat het ontdekking als validatie beschouwt. Het scrapen van platforms zoals GitHub voor SKILL.md-bestanden is een triviale taak. Het resulterende getal is goed voor marketingteksten, maar het is een 'vanity metric' die de realiteit van softwareontwikkeling negeert.

Aan een repository met een skill-manifest is slechts een startpunt. Het is een claim, geen garantie. Toen we begonnen met het systematisch testen van skills, identificeerden we al snel veelvoorkomende faalpatronen die een simpele bestandstelling volledig mist:

• Onvolledige of Foutieve Manifesten: Het SKILL.md-bestand bestaat, maar mist verplichte secties, verwijst naar niet-bestaande tooldefinities, of is syntactisch incorrect. De skill is onmogelijk te installeren zonder handmatige correctie.
• Gebroken Dependencies: De code van de skill is afhankelijk van externe libraries die verouderd zijn, 'breaking changes' bevatten, of niet langer beschikbaar zijn. De installatie kan slagen, maar de skill faalt tijdens runtime.
• Ongedocumenteerde Omgevingsvereisten: Een skill kan specifieke omgevingsvariabelen, een draaiende lokale service, of authenticatietokens vereisen die niet in de documentatie worden vermeld. Eén skill die we testten, vereiste een specifieke versie van een database die draaide op localhost:5433, een detail dat we pas ontdekten door de Python-broncode te lezen. Zonder dit was de skill niet-functioneel.
• Verlaten Projecten: De repository is al jaren niet bijgewerkt. De code is geschreven voor een eerdere versie van de Claude API en is niet langer compatibel.
• "Prompt-als-Skill": Sommige skills bevatten geen daadwerkelijke tools. Het zijn simpelweg uitgebreide prompts verpakt in een skill-formaat. Hoewel potentieel nuttig, vertegenwoordigen ze geen functionele uitbreiding van de capaciteiten van het model en presteren ze vaak niet beter dan een goed geschreven prompt.

Het simpelweg tellen van deze repositories blaast de waargenomen omvang en gezondheid van het ecosysteem op. Het creëert een landschap waarin het vinden van een werkende, betrouwbare tool een kwestie is van 'trial and error'. Onze testmethodologie is specifiek ontworpen om door deze ruis heen te snijden door uitvoering als de primaire maatstaf voor de validiteit van een skill te nemen.

Onze Bevindingen: Een Nuchtere Blik op het Echte Aantal

We hebben 1416 skills, afkomstig van diverse publieke directories en repositories, geïnstalleerd en geprobeerd uit te voeren. Elke skill werd onderworpen aan een reeks geautomatiseerde tests die ontworpen zijn om de kernfunctionaliteit aan te roepen. De resultaten geven een veel duidelijker beeld van de staat van het ecosysteem.

Van de 1416 skills die we testten, slaagden er slechts 889 (63%) voor onze initiële uitvoeringstests zonder enige handmatige interventie.

Hier is een volledig overzicht van onze bevindingen:

Status	Aantal	Percentage van Totaal
Slaagt (Werkt out-of-the-box)	889	63%
Vereist Setup (Handmatige configuratie nodig)	467	33%
Faalt (Presteert slechter dan basismodel)	60	4%
Totaal Getest	1416	100%

Laten we analyseren wat elk van deze categorieën betekent voor een ontwikkelaar die deze tools probeert te gebruiken.

Slaagt (63%): Deze skills werden correct geïnstalleerd en draaiden zonder fouten op ons testplatform. Dit is het echte aantal Claude skills uit onze steekproef—de subset van skills die onmiddellijk bruikbaar zijn. Dit is de basislijn van wat een gebruiker zou moeten verwachten van elke skill in een directory. Echter, zoals we zullen bespreken, betekent "draaien" niet automatisch "hoge kwaliteit."

Vereist Setup (33%): Dit is een significante en vaak over het hoofd geziene categorie. Deze 467 skills waren niet kapot, maar ze waren niet 'plug-and-play'. Veelvoorkomende redenen waren:

• Vereisen dat API-sleutels handmatig als omgevingsvariabelen worden ingesteld.
• Moeten verbinden met een door de gebruiker aangeleverde database of een service van derden.
• Afhankelijk zijn van lokale bestanden of systeemconfiguraties die niet waren gespecificeerd in de SKILL.md.

Bijvoorbeeld, een skill voor interactie met een projectmanagement-API is nutteloos zonder een API-sleutel en een endpoint-URL. Deze skills zijn geen mislukkingen, maar ze vermelden zonder duidelijke, voorafgaande setup-instructies is een slechte dienst aan de gebruiker. Een directory die geen onderscheid maakt tussen een "Slaagt"-skill en een "Vereist Setup"-skill geeft een onbetrouwbaar beeld.

Faalt (4%): Dit is de meest zorgwekkende categorie. Deze 60 skills faalden niet alleen in het uitvoeren van hun functie, maar produceerden resultaten die actief slechter waren dan wanneer het basismodel zonder skill werd gebruikt. Dit gebeurt wanneer de logica van een skill gebrekkig is, waardoor het model:

• Vast komt te zitten in een lus, waarbij het herhaaldelijk een kapotte tool probeert aan te roepen.
• Het gebruik van tools hallucineert die niet in zijn eigen definitie bestaan.
• De intentie van de gebruiker verkeerd interpreteert en een tool incorrect toepast, wat leidt tot fouten of onzinnige output.

Eén skill die we testten was ontworpen om codefragmenten te formatteren. Toen we een simpele Python-functie gaven, probeerde het een format_javascript-tool aan te roepen, faalde en gaf een foutmelding terug. Hetzelfde verzoek aan de kale Claude zou een correct geformatteerd Python-fragment hebben opgeleverd. Deze 60 skills zijn niet alleen nutteloos; ze zijn schadelijk. Geen enkele gerenommeerde directory zou ze moeten vermelden zonder een duidelijke waarschuwing. We publiceren deze mislukkingen omdat ze een cruciaal onderdeel van de data zijn.

Voorbij Uitvoering: Wat Definieert de Kwaliteit van een Skill?

De data toont aan dat ongeveer twee van de drie skills die je vindt, zullen draaien. Maar dit beantwoordt slechts het eerste deel van de vraag. Het tweede, belangrijkere deel gaat over kwaliteit. De kwaliteit van de 23.000 Claude skills is geen kwestie van kwantiteit, maar van prestatie.

Een skill die draait maar zijn taak slecht uitvoert, is nauwelijks beter dan een die helemaal niet draait. Daarom, nadat een skill onze initiële uitvoeringstest doorstaat, geven we het een score op een schaal van 1 tot 10, gebaseerd op zijn prestaties op een reeks real-world taken. Onze volledige scoringsrubriek wordt gedetailleerd in onze methodologie, maar is gecentreerd rond een paar kernprincipes:

• Betrouwbaarheid: Slaagt de skill er consequent in zijn aangegeven taak uit te voeren? Gebruikt het de juiste tools voor de klus?
• Nauwkeurigheid: Is de output correct en foutloos? Als het met een API interacteert, verwerkt het de data dan correct?
• Efficiëntie: Lost het het probleem op zonder onnodige stappen of tool-aanroepen?
• Graceful Failure: Wanneer het een 'edge case' of ongeldige input tegenkomt, geeft het dan een nuttige foutmelding terug of crasht het?

Het verschil tussen een hoog scorende skill en een laag scorende is groot.

Een hoog scorende skill, zoals een goed gebouwde cloud-infrastructuurtool, zal een verzoek als "list all EC2 instances in us-east-1" correct interpreteren, zijn list_instances-tool gebruiken met de juiste region-parameter, de gepagineerde respons van de API afhandelen en de gebruiker een schone, nauwkeurige lijst presenteren.

Een laag scorende skill heeft misschien hetzelfde doel, maar faalt in de uitvoering. Een andere cloud-tool die we testten, negeerde bijvoorbeeld de opgegeven regio en toonde instances uit zijn standaardregio. Het "werkte" in de zin dat het niet crashte, maar het produceerde het verkeerde antwoord, wat het onbetrouwbaar maakte.

De 60 skills die onder het basismodel scoorden, vertegenwoordigen de ondergrens. Ze zijn een tastbaar bewijs dat een slecht ontworpen skill erger is dan helemaal geen skill. Dit is een cruciaal datapunt dat verloren gaat wanneer directories de catalogusgrootte verkiezen boven geverifieerde prestaties.

Het Signaal Vinden in de Ruis

De discrepantie tussen de geadverteerde 23.000+ skills en ons geteste slagingspercentage van 63% benadrukt het kernprobleem: het ecosysteem zit vol met ruis. Het werkelijke aantal functionele, hoogwaardige skills is een kleine fractie van het geadverteerde totaal.

Elke skill die je vindt handmatig testen is geen praktische oplossing voor een ontwikkelaar. Het proces is tijdrovend en resource-intensief. Onze test van 1416 skills vereiste aanzienlijke engineering-inspanning om het 'test harness' te bouwen en substantiële 'compute resources' om de evaluaties uit te voeren. Dit is precies waarom de meeste directories het niet doen. Het is veel eenvoudiger om een scraper te draaien en een groot, ongeverifieerd aantal te publiceren.

Het doel van een skill-directory zou moeten zijn om het signaal van de ruis te filteren. Het zou het validatiewerk namens de gebruiker moeten doen. Dit betekent:

1. Elke skill uitvoeren: Een skill is niet "geverifieerd" totdat deze is uitgevoerd.
2. Testen op correctheid: De skill moet worden geëvalueerd aan de hand van echte taken om te zien of hij presteert zoals geadverteerd.
3. Mislukkingen publiceren: Een directory die niet laat zien wat er misging, verbergt de helft van het verhaal. De faaldata is net zo belangrijk als de succesdata.

Door skills te testen in tientallen categorieën, van data-analyse tot webontwikkeling, bouwen we een kaart van wat werkt, wat aanpassingen nodig heeft en wat volledig te vermijden is.

Deze datagedreven aanpak is de enige betrouwbare manier om de vraag "zijn claude skill-marktplaatsen betrouwbaar?" te beantwoorden. Het antwoord is: ze zijn slechts zo betrouwbaar als hun verificatieproces. Een marktplaats die slechts een lijst van repositories is, is geen betrouwbare bron voor professionele tools. Een directory die elke afzonderlijke vermelding draait, test en scoort, biedt een basis van vertrouwen.

Gerelateerd: hoeveel presteren beter dan de baseline · onze testmethodologie.

We hebben dit werk uitgevoerd voor onze gehele catalogus. De 889 skills die onze tests hebben doorstaan, zijn beschikbaar om te doorzoeken, compleet met hun scores en een oordeel over hun prestaties. Voor ontwikkelaars die een kernset van bewezen tools nodig hebben, bieden we een samengesteld pakket van onze best beoordeelde skills aan voor $10, allemaal gegarandeerd werkend en presterend zoals verwacht. Dit is onze oplossing voor het signaal-ruisprobleem: een kleine, geverifieerde, hoogwaardige subset van het massale, ongeverifieerde publieke ecosysteem.