Bag om hypen: Vi kørte 1416 Claude-skills for at finde det reelle antal, der virker

Du har sandsynligvis set tallene: overskrifter og kataloger, der annoncerer med over 23.000 Claude-skills tilgængelige for installation. Dette tal antyder et enormt, modent økosystem af værktøjer, der er klar til at udvide basismodellens kapabiliteter. Det er et imponerende tal, men det rejser et kritisk teknisk spørgsmål: hvad betyder "tilgængelig" egentlig? I de fleste tilfælde betyder det, at et SKILL.md-manifest er blevet fundet i et offentligt koderepository. Det er en optælling baseret på filfund, ikke funktionel verifikation.

Denne tilgang er simpel, skalerbar og i sidste ende misvisende. Den fortæller dig intet om, hvorvidt et skill kan installeres, køre uden fejl eller udføre sin annoncerede funktion effektivt. Den fortæller dig ikke, om det er et forladt projekt, et defekt proof-of-concept, eller om det endda præsterer dårligere end slet ikke at bruge et skill.

Hos SkillProof har vi en anden tilgang. Vi tæller ikke repositories; vi installerer og eksekverer skills mod et standardiseret sæt af virkelighedsnære opgaver. Denne artikel præsenterer vores resultater fra test af 1416 skills. Det er et direkte, databaseret svar på spørgsmålet om, hvor mange Claude code-skills der rent faktisk virker, og en undersøgelse af, om markedspladser for Claude-skills er pålidelige kilder til produktionsklare værktøjer.

Fejlen ved at tælle filer

Det grundlæggende problem med en optælling på 23.000+ skills er, at den behandler fund som validering. At scrape platforme som GitHub for SKILL.md-filer er en triviel opgave. Det resulterende tal er godt marketingsmateriale, men det er en forfængelighedsmetrik, der ignorerer virkeligheden inden for softwareudvikling.

Et repository, der indeholder et skill-manifest, er kun et udgangspunkt. Det er en påstand, ikke en garanti. Da vi påbegyndte vores proces med systematisk at teste skills, identificerede vi hurtigt almindelige fejltyper, som simpel filoptælling fuldstændig overser:

• Ufuldstændige eller malformede manifester: SKILL.md-filen eksisterer, men den mangler påkrævede sektioner, peger på ikke-eksisterende værktøjsdefinitioner eller er syntaktisk ukorrekt. Det er umuligt at installere et skill uden manuel korrektion.
• Defekte afhængigheder: Et skills kode er afhængig af eksterne biblioteker, der er forældede, har breaking changes eller ikke længere er tilgængelige. Installationen kan lykkes, men et skill vil fejle under kørsel (runtime).
• Udokuumenterede miljøkrav: Et skill kan kræve specifikke miljøvariabler, en kørende lokal service eller autentificeringstokens, som ikke er nævnt i dokumentationen. Et skill, vi testede, krævede en specifik version af en database kørende på localhost:5433, en detalje vi kun opdagede ved at læse dets Python-kildekode. Uden dette var det ikke-funktionelt.
• Forladte projekter: Repositoryet er ikke blevet opdateret i årevis. Koden blev skrevet til en tidligere version af Claude API'en og er ikke længere kompatibel.
• "Prompt-som-et-Skill": Nogle skills indeholder ingen reelle værktøjer. De er blot detaljerede prompts pakket i et skill-format. Selvom de potentielt kan være nyttige, repræsenterer de ikke en funktionel udvidelse af modellens kapabiliteter og præsterer ofte ikke bedre end en velskrevet prompt.

At blot tælle disse repositories puster den opfattede størrelse og sundhed af økosystemet op. Det skaber et landskab, hvor det at finde et fungerende, pålideligt værktøj er et spørgsmål om trial and error. Vores testmetodologi blev designet specifikt til at skære igennem denne støj ved at gøre eksekvering til det primære mål for et skills validitet.

Vores resultater: Et nøgternt kig på det reelle antal

Vi installerede og forsøgte at køre 1416 skills fra forskellige offentlige kataloger og repositories. Hvert skill blev udsat for en række automatiserede tests designet til at kalde dets kernefunktionalitet. Resultaterne giver et meget klarere billede af økosystemets tilstand.

Ud af de 1416 skills, vi testede, bestod kun 889 (63%) vores indledende eksekveringstests uden nogen manuel indgriben.

Her er en komplet oversigt over vores resultater:

Status	Antal	Procentdel af total
Består (Kører out-of-the-box)	889	63%
Kræver opsætning (Kræver manuel konfig.)	467	33%
Fejler (Præsterer dårligere end basismodel)	60	4%
Total testet	1416	100%

Lad os analysere, hvad hver af disse kategorier betyder for en udvikler, der forsøger at bruge disse værktøjer.

Består (63%): Disse skills blev installeret korrekt og kørte på vores testmiljø uden fejl. Dette er det "reelle antal Claude-skills i kataloger" fra vores stikprøve – den delmængde af skills, der er umiddelbart anvendelige. Dette er basislinjen for, hvad en bruger bør forvente af ethvert skill i et katalog. Men som vi vil diskutere, betyder "kører" ikke automatisk "høj kvalitet".

Kræver opsætning (33%): Dette er en betydelig og ofte overset kategori. Disse 467 skills var ikke defekte, men de var ikke plug-and-play. Almindelige årsager inkluderede:

• Kræver, at API-nøgler sættes manuelt som miljøvariabler.
• Skal forbinde til en brugerleveret database eller tredjepartsservice.
• Afhænger af lokale filer eller systemkonfigurationer, der ikke var specificeret i SKILL.md.

For eksempel er et skill til interaktion med et projektstyrings-API ubrugeligt uden en API-nøgle og en endpoint-URL. Disse skills er ikke fejl, men at liste dem uden klare, forudgående opsætningsinstruktioner er en dårlig service for brugeren. Et katalog, der ikke skelner mellem et "Består"-skill og et "Kræver opsætning"-skill, giver et upålideligt billede.

Fejler (4%): Dette er den mest bekymrende kategori. Disse 60 skills undlod ikke kun at udføre deres funktion, men producerede resultater, der var aktivt dårligere end at bruge basismodellen uden et skill installeret. Dette sker, når et skills logik er fejlbehæftet, hvilket får modellen til at:

• Gå i et loop og gentagne gange forsøge at kalde et defekt værktøj.
• Hallucinere brugen af værktøjer, der ikke findes i dens egen definition.
• Fejltolke brugerens hensigt og anvende et værktøj forkert, hvilket fører til fejl eller meningsløst output.

Et skill, vi testede, var designet til at formatere kodestykker. Da det fik en simpel Python-funktion, forsøgte det at kalde et format_javascript-værktøj, fejlede og returnerede en fejlmeddelelse. Den samme anmodning til en ren Claude ville have resulteret i et korrekt formateret Python-kodestykke. Disse 60 skills er ikke bare ubrugelige; de er skadelige. Intet velrenommeret katalog bør liste dem uden en klar advarsel. Vi offentliggør disse fejl, fordi de er en kritisk del af dataene.

Ud over eksekvering: Hvad definerer kvaliteten af et skill?

Dataene viser, at cirka to ud af tre skills, du måtte finde, vil køre. Men dette besvarer kun den første del af spørgsmålet. Den anden, vigtigere del handler om kvalitet. "Kvaliteten af 23.000 Claude-skills" er ikke et spørgsmål om kvantitet, men om ydeevne.

Et skill, der kører, men udfører sin opgave dårligt, er kun lidt bedre end et, der slet ikke kører. Derfor, efter et skill består vores indledende eksekveringstest, scorer vi det på en skala fra 1 til 10 baseret på dets ydeevne i en række virkelighedsnære opgaver. Vores fulde scoringsrubrik er detaljeret i vores metodologi, men den er centreret om et par nøgleprincipper:

• Pålidelighed: Lykkes et skill konsekvent med sin erklærede opgave? Bruger det de korrekte værktøjer til opgaven?
• Nøjagtighed: Er outputtet korrekt og fejlfrit? Hvis det interagerer med et API, håndterer det så data korrekt?
• Effektivitet: Løser det problemet uden unødvendige trin eller værktøjskald?
• Graceful Failure: Når det støder på et edge case eller ugyldigt input, returnerer det så en hjælpsom fejlmeddelelse, eller crasher det?

Forskellen mellem et højtscorende og et lavtscorende skill er markant.

Et højtscorende skill, som et velbygget cloud-infrastrukturværktøj, vil korrekt fortolke en anmodning som "list all EC2 instances in us-east-1," bruge sit list_instances-værktøj med den korrekte region-parameter, håndtere det paginerede svar fra API'et og præsentere brugeren for en ren, nøjagtig liste.

Et lavtscorende skill kan have det samme mål, men fejle i udførelsen. For eksempel ignorerede et andet cloud-værktøj, vi testede, den specificerede region og listede instanser fra sin standardregion. Det "virkede" i den forstand, at det ikke crashede, men det producerede det forkerte svar, hvilket gjorde det upålideligt.

De 60 skills, der scorede lavere end basismodellen, repræsenterer bunden. De er en håndgribelig demonstration af, at et dårligt designet skill er værre end intet skill overhovedet. Dette er et kritisk datapunkt, der går tabt, når kataloger prioriterer katalogstørrelse over verificeret ydeevne.

At finde signalet i støjen

Uoverensstemmelsen mellem de annoncerede 23.000+ skills og vores testede beståelsesrate på 63% fremhæver kerneproblemet: økosystemet er fuld af støj. Det sande antal funktionelle skills af høj kvalitet er en lille brøkdel af det annoncerede total.

At teste hvert skill, man finder, manuelt er ikke en praktisk løsning for nogen udvikler. Processen er tidskrævende og ressourceintensiv. Vores test af 1416 skills krævede en betydelig ingeniørindsats for at bygge test-harnisket og substantielle computeressourcer til at køre evalueringerne. Det er netop derfor, de fleste kataloger ikke gør det. Det er langt lettere at køre en scraper og publicere et stort, uverificeret tal.

Målet med et skill-katalog bør være at filtrere signalet fra støjen. Det bør udføre valideringsarbejdet på vegne af brugeren. Det betyder:

1. Eksekvering af hvert skill: Et skill er ikke "verificeret", før det er blevet kørt.
2. Test for korrekthed: Et skill skal evalueres mod reelle opgaver for at se, om det præsterer som annonceret.
3. Offentliggørelse af fejl: Et katalog, der ikke viser dig, hvad der fejlede, skjuler halvdelen af historien. Fejldata er lige så vigtige som succesdata.

Ved at teste skills på tværs af dusinvis af kategorier, fra dataanalyse til webudvikling, bygger vi et kort over, hvad der virker, hvad der kræver justering, og hvad man helt skal undgå.

Denne datadrevne tilgang er den eneste pålidelige måde at besvare spørgsmålet: "er markedspladser for Claude-skills pålidelige?" Svaret er: de er kun så pålidelige som deres verifikationsproces. En markedsplads, der blot er en liste over repositories, er ikke en pålidelig kilde til professionelle værktøjer. Et katalog, der kører, tester og scorer hver eneste post, skaber et fundament af tillid.

Relateret læsning: hvor mange slår rent faktisk basislinjen · vores testmetodologi.

Vi har udført dette arbejde på tværs af hele vores katalog. De 889 skills, der bestod vores tests, kan gennemses, komplet med deres scores og en bedømmelse af deres ydeevne. For udviklere, der har brug for et kernesæt af gennemprøvede værktøjer, tilbyder vi en kurateret pakke med vores højest ratede skills for $10, alle garanteret at køre og præstere som forventet. Dette er vores løsning på signal-støj-problemet: en lille, verificeret delmængde af høj kvalitet fra det massive, uverificerede offentlige økosystem.