Bortom hypen: Vi körde 1416 Claude-skills för att se hur många som fungerar

Du har sannolikt sett siffrorna: rubriker och kataloger som annonserar över 23 000 Claude-skills tillgängliga för installation. Siffran antyder ett stort, moget ekosystem av verktyg redo att utöka basmodellens förmågor. Det är ett imponerande antal, men det väcker en kritisk teknisk fråga: vad betyder "tillgänglig" egentligen? I de flesta fall betyder det att ett SKILL.md-manifest har hittats i ett publikt kod-repository. Det är ett antal baserat på filupptäckt, inte funktionell verifiering.

Detta tillvägagångssätt är enkelt, skalbart och i slutändan vilseledande. Det säger ingenting om en skill kommer att installeras, köras utan fel, eller utföra sin utlovade funktion effektivt. Det avslöjar inte om det är ett övergivet projekt, ett trasigt proof-of-concept, eller om det till och med presterar sämre än att inte använda någon skill alls.

På SkillProof har vi ett annat tillvägagångssätt. Vi räknar inte repositories; vi installerar och exekverar skills mot en standardiserad uppsättning av verkliga uppgifter. Denna artikel presenterar våra resultat från testningen av 1416 skills. Det är ett direkt, datadrivet svar på frågan om hur många Claude code-skills det finns som faktiskt fungerar, och en granskning av om marknadsplatser för Claude-skills är pålitliga källor för produktionsklara verktyg.

Problemet med att bara räkna filer

Det grundläggande problemet med ett antal på över 23 000 skills är att det behandlar upptäckt som validering. Att skrapa plattformar som GitHub efter SKILL.md-filer är en trivial uppgift. Det resulterande antalet är bra för marknadsföring, men det är ett 'vanity metric' som ignorerar verkligheten inom mjukvaruutveckling.

Ett repository som innehåller ett skill-manifest är bara en startpunkt. Det är ett påstående, inte en garanti. När vi påbörjade vår process med att systematiskt testa skills, identifierade vi snabbt vanliga felmönster som enkel filräkning helt missar:

• Ofullständiga eller felaktiga manifest: SKILL.md-filen existerar, men saknar obligatoriska sektioner, pekar på obefintliga verktygsdefinitioner eller är syntaktiskt felaktig. En skill är omöjlig att installera utan manuell korrigering.
• Trasiga beroenden: En skills kod är beroende av externa bibliotek som är föråldrade, har 'breaking changes', eller inte längre är tillgängliga. Installationen kan lyckas, men skillen kommer att fallera vid körning.
• Odokumenterade miljökrav: En skill kan kräva specifika miljövariabler, en lokal tjänst som körs, eller autentiseringstokens som inte nämns i dokumentationen. En skill vi testade krävde en specifik version av en databas som kördes på localhost:5433, en detalj som vi upptäckte först efter att ha läst dess Python-källkod. Utan detta var den icke-funktionell.
• Övergivna projekt: Repositoryt har inte uppdaterats på flera år. Koden skrevs för en tidigare version av Claude API och är inte längre kompatibel.
• "Prompt-as-a-Skill": Vissa skills innehåller inga faktiska verktyg. De är helt enkelt avancerade prompts paketerade i ett skill-format. Även om de kan vara användbara, representerar de inte en funktionell utökning av modellens förmågor och presterar ofta inte bättre än en välskriven prompt.

Att bara räkna dessa repositories blåser upp den upplevda storleken och hälsan hos ekosystemet. Det skapar ett landskap där att hitta ett fungerande, pålitligt verktyg blir en fråga om 'trial and error'. Vår testmetodik utformades specifikt för att skära igenom detta brus genom att göra exekvering till det primära måttet på en skills validitet.

Våra resultat: En nykter blick på det verkliga antalet

Vi installerade och försökte köra 1416 skills hämtade från olika publika kataloger och repositories. Varje skill utsattes för en serie automatiserade tester utformade för att anropa dess kärnfunktionalitet. Resultaten ger en mycket tydligare bild av ekosystemets tillstånd.

Av de 1416 skills vi testade, klarade endast 889 (63 %) våra initiala exekveringstester utan manuella ingrepp.

Här är en komplett sammanställning av våra resultat:

Status	Antal	Procent av totalen
Pass (Körs direkt)	889	63 %
Needs Setup (Kräver manuell konfiguration)	467	33 %
Fails (Presterar sämre än basmodellen)	60	4 %
Totalt testade	1416	100 %

Låt oss analysera vad var och en av dessa kategorier innebär för en utvecklare som försöker använda dessa verktyg.

Pass (63 %): Dessa skills installerades korrekt och kördes på vår testbädd utan fel. Detta är det "verkliga antalet skills i Claude-katalogen" från vårt urval – den delmängd av skills som är omedelbart användbara. Detta är baslinjen för vad en användare bör förvänta sig av en skill som listas i en katalog. Men, som vi kommer att diskutera, betyder "körbar" inte automatiskt "hög kvalitet."

Needs Setup (33 %): Detta är en betydande och ofta förbisedd kategori. Dessa 467 skills var inte trasiga, men de var inte 'plug-and-play'. Vanliga orsaker inkluderade:

• Krav på att API-nycklar ställs in manuellt som miljövariabler.
• Behov av att ansluta till en användartillhandahållen databas eller tredjepartstjänst.
• Beroende av lokala filer eller systemkonfigurationer som inte specificerats i SKILL.md.

Till exempel är en skill för att interagera med ett projekthanterings-API oanvändbar utan en API-nyckel och en endpoint-URL. Dessa skills är inte misslyckanden, men att lista dem utan tydliga, initiala installationsinstruktioner är en björntjänst för användaren. En katalog som inte skiljer mellan en "Pass"-skill och en "Needs Setup"-skill ger en opålitlig bild.

Fails (4 %): Detta är den mest oroande kategorin. Dessa 60 skills misslyckades inte bara med att utföra sin funktion, utan producerade resultat som var aktivt sämre än att använda basmodellen utan någon skill. Detta händer när en skills logik är felaktig, vilket får modellen att:

• Fastna i en loop och upprepade gånger försöka anropa ett trasigt verktyg.
• Hallucinera användningen av verktyg som inte finns i dess egen definition.
• Feltolka användarens avsikt och tillämpa ett verktyg felaktigt, vilket leder till fel eller meningslös output.

En skill vi testade var utformad för att formatera kodavsnitt. När den fick en enkel Python-funktion försökte den anropa ett format_javascript-verktyg, misslyckades och returnerade ett felmeddelande. Samma förfrågan till enbart Claude skulle ha resulterat i ett korrekt formaterat Python-avsnitt. Dessa 60 skills är inte bara värdelösa; de är skadliga. Ingen seriös katalog bör lista dem utan en tydlig varning. Vi publicerar dessa misslyckanden eftersom de är en kritisk del av datan.

Bortom exekvering: Vad definierar kvaliteten på en skill?

Datan visar att ungefär två av tre skills du hittar kommer att köras. Men detta besvarar bara den första delen av frågan. Den andra, viktigare delen handlar om kvalitet. Frågan om "kvaliteten på 23000 claude skills" handlar inte om kvantitet, utan om prestanda.

En skill som körs men utför sin uppgift dåligt är knappast bättre än en som inte körs alls. Det är därför vi, efter att en skill har klarat vårt initiala exekveringstest, poängsätter den på en skala från 1 till 10 baserat på dess prestanda i en serie verkliga uppgifter. Vår fullständiga poängsättningsmodell beskrivs i vår metodik, men den är centrerad kring några nyckelprinciper:

• Pålitlighet: Lyckas skillen konsekvent med sin angivna uppgift? Använder den rätt verktyg för jobbet?
• Noggrannhet: Är outputen korrekt och felfri? Om den interagerar med ett API, hanterar den data korrekt?
• Effektivitet: Löser den problemet utan onödiga steg eller verktygsanrop?
• Graceful Failure: När den stöter på ett 'edge case' eller ogiltig input, returnerar den ett hjälpsamt felmeddelande eller kraschar den?

Skillnaden mellan en högt poängsatt skill och en lågt poängsatt är markant.

En högt poängsatt skill, likt ett välbyggt verktyg för molninfrastruktur, kommer korrekt att tolka en förfrågan som "lista alla EC2-instanser i us-east-1", använda sitt list_instances-verktyg med korrekt region-parameter, hantera det paginerade svaret från API:et och presentera en ren, korrekt lista för användaren.

En lågt poängsatt skill kan ha samma mål men misslyckas i utförandet. Till exempel ignorerade ett annat molnverktyg vi testade den angivna regionen och listade instanser från sin standardregion. Det "fungerade" i den meningen att det inte kraschade, men det producerade fel svar, vilket gjorde det opålitligt.

De 60 skills som fick lägre poäng än basmodellen representerar bottennivån. De är en påtaglig demonstration av att en dåligt utformad skill är sämre än ingen skill alls. Detta är en kritisk datapunkt som går förlorad när kataloger prioriterar katalogstorlek framför verifierad prestanda.

Att hitta signalen i bruset

Skillnaden mellan de annonserade 23 000+ skills och vår testade 'pass rate' på 63 % belyser kärnproblemet: ekosystemet är fullt av brus. Det verkliga antalet funktionella, högkvalitativa skills är en liten bråkdel av den annonserade totalen.

Att manuellt testa varje skill man hittar är inte en praktisk lösning för någon utvecklare. Processen är tidskrävande och resursintensiv. Vårt test av 1416 skills krävde en betydande ingenjörsinsats för att bygga testramverket och avsevärda beräkningsresurser för att köra utvärderingarna. Det är precis därför de flesta kataloger inte gör det. Det är mycket enklare att köra en scraper och publicera ett stort, overifierat antal.

Målet med en skill-katalog bör vara att filtrera signalen från bruset. Den bör utföra valideringsarbetet åt användaren. Detta innebär:

1. Exekvering av varje skill: En skill är inte "verifierad" förrän den har körts.
2. Testning för korrekthet: En skill måste utvärderas mot verkliga uppgifter för att se om den presterar som utlovat.
3. Publicering av misslyckanden: En katalog som inte visar vad som misslyckades döljer halva sanningen. Misslyckandedata är lika viktig som framgångsdata.

Genom att testa skills över dussintals kategorier, från dataanalys till webbutveckling, bygger vi en karta över vad som fungerar, vad som behöver justeras och vad som helt bör undvikas.

Detta datadrivna tillvägagångssätt är det enda pålitliga sättet att besvara frågan, "är marknadsplatser för Claude-skills pålitliga?". Svaret är: de är bara så pålitliga som deras verifieringsprocess. En marknadsplats som bara är en lista över repositories är inte en pålitlig källa för professionella verktyg. En katalog som kör, testar och poängsätter varje enskild post skapar en grund av förtroende.

Relaterad läsning: hur många som faktiskt slår baslinjen · vår testmetodik.

Vi har gjort detta arbete över hela vår katalog. De 889 skills som klarade våra tester finns tillgängliga att bläddra bland, kompletta med poäng och ett utlåtande om deras prestanda. För utvecklare som behöver en kärnuppsättning av beprövade verktyg erbjuder vi ett kurerat paket med våra högst rankade skills för $10, alla garanterade att köra och prestera som förväntat. Detta är vår lösning på signal-brus-problemet: en liten, verifierad, högkvalitativ delmängd av det massiva, overifierade publika ekosystemet.