Forbi hypen: Vi kjørte 1416 Claude-ferdigheter for å finne ut hvor mange som faktisk virker

Du har sannsynligvis sett tallene: overskrifter og kataloger som annonserer over 23 000 Claude-ferdigheter klare for installasjon. Dette tallet antyder et enormt, modent økosystem av verktøy klare til å utvide basismodellens kapabiliteter. Det er et imponerende tall, men det reiser et kritisk teknisk spørsmål: hva betyr «tilgjengelig» egentlig? I de fleste tilfeller betyr det at et SKILL.md-manifest ble funnet i et offentlig koderepositorium. Det er en opptelling basert på filoppdagelse, ikke funksjonell verifisering.

Denne tilnærmingen er enkel, skalerbar og til syvende og sist villedende. Den forteller deg ingenting om en ferdighet vil installeres, kjøre uten feil, eller utføre sin annonserte funksjon effektivt. Den forteller deg ikke om det er et forlatt prosjekt, et ødelagt proof-of-concept, eller til og med om den presterer dårligere enn å ikke bruke noen ferdighet i det hele tatt.

Hos SkillProof har vi en annen tilnærming. Vi teller ikke repositorier; vi installerer og kjører ferdigheter mot et standardisert sett med reelle oppgaver. Denne artikkelen presenterer funnene våre fra testing av 1416 ferdigheter. Det er et direkte, datastøttet svar på spørsmålet om hvor mange Claude-kodeferdigheter som faktisk virker, og en undersøkelse av om markedsplasser for Claude-ferdigheter er pålitelige kilder for produksjonsklare verktøy.

Feilen ved å telle filer

Det fundamentale problemet med en opptelling av 23 000+ ferdigheter er at den behandler oppdagelse som validering. Å skrape plattformer som GitHub for SKILL.md-filer er en triviell oppgave. Det resulterende tallet gir god markedsføringstekst, men det er en forfengelighetsmetrikk som ignorerer realiteten i programvareutvikling.

Et repositorium som inneholder et ferdighetsmanifest er bare et utgangspunkt. Det er en påstand, ikke en garanti. Da vi startet vår prosess med å systematisk teste ferdigheter, identifiserte vi raskt vanlige feilmønstre som enkel filtelling overser fullstendig:

• Ufullstendige eller feilformaterte manifester: SKILL.md-filen eksisterer, men mangler påkrevde seksjoner, peker til ikke-eksisterende verktøydefinisjoner, eller er syntaktisk ukorrekt. Ferdigheten er umulig å installere uten manuell retting.
• Ødelagte avhengigheter: Ferdighetens kode er avhengig av eksterne biblioteker som er utdaterte, har brytende endringer, eller ikke lenger er tilgjengelige. Installasjonen kan lykkes, men ferdigheten vil feile under kjøring.
• Udokumenterte miljøkrav: En ferdighet kan kreve spesifikke miljøvariabler, en kjørende lokal tjeneste, eller autentiseringstokener som ikke er nevnt i dokumentasjonen. En ferdighet vi testet krevde en spesifikk versjon av en database som kjørte på localhost:5433, en detalj som bare ble oppdaget ved å lese Python-kildekoden. Uten dette var den ikke-funksjonell.
• Forlatte prosjekter: Repositoriet har ikke blitt oppdatert på flere år. Koden ble skrevet for en tidligere versjon av Claude API-et og er ikke lenger kompatibel.
• «Prompt-som-ferdighet»: Noen ferdigheter inneholder ingen faktiske verktøy. De er simpelthen forseggjorte «prompts» pakket i et ferdighetsformat. Selv om de kan være nyttige, representerer de ikke en funksjonell utvidelse av modellens kapabiliteter og presterer ofte ikke bedre enn en velskrevet «prompt».

Å bare telle disse repositoriene blåser opp den oppfattede størrelsen og helsen til økosystemet. Det skaper et landskap der det å finne et fungerende, pålitelig verktøy er et spørsmål om prøving og feiling. Vår testmetodikk ble designet spesifikt for å skjære gjennom denne støyen ved å gjøre kjøring til det primære målet på en ferdighets gyldighet.

Våre funn: Et nøkternt blikk på det reelle antallet

Vi installerte og forsøkte å kjøre 1416 ferdigheter hentet fra ulike offentlige kataloger og repositorier. Hver ferdighet ble utsatt for en serie automatiserte tester designet for å påkalle kjernefunksjonaliteten. Resultatene gir et mye klarere bilde av økosystemets tilstand.

Av de 1416 ferdighetene vi testet, var det kun 889 (63 %) som besto våre innledende kjøringstester uten manuell inngripen.

Her er en fullstendig oversikt over funnene våre:

Status	Antall	Prosent av totalen
Bestått (Kjører rett ut av boksen)	889	63 %
Krever oppsett (Krever manuell konfigurasjon)	467	33 %
Feiler (Presterer dårligere enn basismodellen)	60	4 %
Totalt testet	1416	100 %

La oss analysere hva hver av disse kategoriene betyr for en utvikler som prøver å bruke disse verktøyene.

Bestått (63 %): Disse ferdighetene ble installert korrekt og kjørte på vår testplattform uten feil. Dette er det «reelle antallet i Claude-ferdighetskatalogen» fra vårt utvalg – undergruppen av ferdigheter som er umiddelbart brukbare. Dette er grunnlinjen for hva en bruker bør forvente av enhver ferdighet som er listet i en katalog. Men, som vi skal diskutere, betyr ikke «kjører» automatisk «høy kvalitet».

Krever oppsett (33 %): Dette er en betydelig og ofte oversett kategori. Disse 467 ferdighetene var ikke ødelagte, men de var ikke «plug-and-play». Vanlige årsaker inkluderte:

• Krevde at API-nøkler ble satt manuelt som miljøvariabler.
• Måtte koble til en brukerlevert database eller tredjepartstjeneste.
• Var avhengig av lokale filer eller systemkonfigurasjoner som ikke var spesifisert i SKILL.md.

For eksempel er en ferdighet for å samhandle med et prosjektstyrings-API ubrukelig uten en API-nøkkel og en endepunkt-URL. Disse ferdighetene er ikke feil, men å liste dem uten klare, forhåndsoppgitte oppsettsinstruksjoner er en bjørnetjeneste for brukeren. En katalog som ikke skiller mellom en «Bestått»-ferdighet og en «Krever oppsett»-ferdighet, gir et upålitelig bilde.

Feiler (4 %): Dette er den mest bekymringsfulle kategorien. Disse 60 ferdighetene klarte ikke bare ikke å utføre sin funksjon, men produserte resultater som var aktivt dårligere enn å bruke basismodellen uten noen ferdighet installert. Dette skjer når en ferdighets logikk er feil, noe som får modellen til å:

• Sette seg fast i en løkke, og gjentatte ganger prøve å kalle et ødelagt verktøy.
• Hallusinere bruken av verktøy som ikke eksisterer i dens egen definisjon.
• Feiltolke brukerens intensjon og bruke et verktøy feil, noe som fører til feil eller meningsløs output.

En ferdighet vi testet var designet for å formatere kodebiter. Da den fikk en enkel Python-funksjon, forsøkte den å kalle et format_javascript-verktøy, feilet, og returnerte en feilmelding. Den samme forespørselen til en ren Claude ville ha resultert i en korrekt formatert Python-kodebit. Disse 60 ferdighetene er ikke bare ubrukelige; de er skadelige. Ingen anerkjent katalog bør liste dem uten en tydelig advarsel. Vi publiserer disse feilene fordi de er en kritisk del av dataene.

Utover kjøring: Hva definerer ferdighetskvalitet?

Dataene viser at omtrent to av tre ferdigheter du finner, vil kjøre. Men dette svarer bare på den første delen av spørsmålet. Den andre, viktigere delen handler om kvalitet. «Kvaliteten på 23 000 Claude-ferdigheter» er ikke et spørsmål om kvantitet, men om ytelse.

En ferdighet som kjører, men utfører oppgaven sin dårlig, er lite bedre enn en som ikke kjører i det hele tatt. Dette er grunnen til at vi, etter at en ferdighet har bestått vår innledende kjøringstest, gir den en poengsum fra 1 til 10 basert på ytelsen på en rekke reelle oppgaver. Hele vår poengmatrise er detaljert i vår metodikk, men den sentrerer seg om noen få nøkkelprinsipper:

• Pålitelighet: Lykkes ferdigheten konsekvent med sin oppgitte oppgave? Bruker den de riktige verktøyene for jobben?
• Nøyaktighet: Er outputen korrekt og feilfri? Hvis den samhandler med et API, håndterer den data korrekt?
• Effektivitet: Løser den problemet uten unødvendige trinn eller verktøykall?
• Elegant feilhåndtering: Når den støter på et «edge case» eller ugyldig input, returnerer den en nyttig feilmelding, eller krasjer den?

Forskjellen mellom en ferdighet med høy poengsum og en med lav poengsum er slående.

En ferdighet med høy poengsum, som et velbygd verktøy for skyinfrastruktur, vil korrekt tolke en forespørsel som «list all EC2 instances in us-east-1», bruke sitt list_instances-verktøy med korrekt region-parameter, håndtere det paginerte svaret fra API-et, og presentere brukeren med en ren, nøyaktig liste.

En ferdighet med lav poengsum kan ha samme mål, men feile i utførelsen. For eksempel ignorerte et annet skyverktøy vi testet den angitte regionen og listet instanser fra sin standardregion. Det «fungerte» i den forstand at det ikke krasjet, men det produserte feil svar, noe som gjorde det upålitelig.

De 60 ferdighetene som scoret lavere enn basismodellen representerer bunnivået. De er en konkret demonstrasjon på at en dårlig designet ferdighet er verre enn ingen ferdighet i det hele tatt. Dette er et kritisk datapunkt som går tapt når kataloger prioriterer katalogstørrelse over verifisert ytelse.

Å finne signalet i støyen

Forskjellen mellom de annonserte 23 000+ ferdighetene og vår testede bestått-rate på 63 % fremhever kjerneproblemet: økosystemet er fullt av støy. Det sanne antallet funksjonelle ferdigheter av høy kvalitet er en liten brøkdel av det annonserte totalantallet.

Å manuelt teste hver ferdighet du finner er ikke en praktisk løsning for noen utvikler. Prosessen er tidkrevende og ressurskrevende. Vår test av 1416 ferdigheter krevde betydelig ingeniørinnsats for å bygge test-rammeverket og betydelige databehandlingsressurser for å kjøre evalueringene. Dette er nøyaktig hvorfor de fleste kataloger ikke gjør det. Det er langt enklere å kjøre en «scraper» og publisere et stort, uverifisert tall.

Målet med en ferdighetskatalog bør være å filtrere signalet fra støyen. Den bør gjøre valideringsarbeidet på vegne av brukeren. Dette betyr:

1. Kjøre hver ferdighet: En ferdighet er ikke «verifisert» før den har blitt kjørt.
2. Teste for korrekthet: Ferdigheten må evalueres mot reelle oppgaver for å se om den presterer som annonsert.
3. Publisere feil: En katalog som ikke viser deg hva som feilet, skjuler halve historien. Feildataene er like viktige som suksessdataene.

Ved å teste ferdigheter på tvers av dusinvis av kategorier, fra dataanalyse til webutvikling, bygger vi et kart over hva som fungerer, hva som trenger justering, og hva man bør unngå helt.

Denne datadrevne tilnærmingen er den eneste pålitelige måten å besvare spørsmålet «er markedsplasser for Claude-ferdigheter pålitelige?» Svaret er: de er bare så pålitelige som deres verifiseringsprosess. En markedsplass som bare er en liste over repositorier er ikke en pålitelig kilde for profesjonelle verktøy. En katalog som kjører, tester og gir poeng til hver eneste oppføring, gir et fundament av tillit.

Relatert lesing: hvor mange som faktisk slår grunnlinjen · vår testmetodikk.

Vi har gjort dette arbeidet på tvers av hele vår katalog. De 889 ferdighetene som besto testene våre er tilgjengelige for gjennomlesing, komplett med poengsummer og en dom over ytelsen. For utviklere som trenger et kjernesett med velprøvde verktøy, tilbyr vi en kuratert pakke med våre høyest rangerte ferdigheter for $10, alle garantert å kjøre og prestere som forventet. Dette er vår løsning på signal-støy-problemet: et lite, verifisert delsett av høy kvalitet fra det massive, uverifiserte offentlige økosystemet.