Hvor mange Claude-ferdigheter er egentlig bedre enn ren Claude? Vi har målt det.

Løftet om Claude-ferdigheter er overbevisende: et bibliotek med verktøy som kan installeres for å gi modellen nye kapabiliteter, fra å interagere med API-er til å generere kompleks kode. Den offisielle katalogen og tredjeparts-repoer lister tusenvis av dem. Men dette reiser et kritisk spørsmål for enhver utvikler med verdifull tid: forbedrer Claude-ferdigheter faktisk resultatet på en målbar måte?

Det er lett å finne ferdigheter som hevder å være revolusjonerende. Det er mye vanskeligere å finne objektive bevis. De fleste ferdighetskataloger er nettopp det – kataloger. De lister ferdigheter basert på forfatterens beskrivelse, men de validerer ikke påstandene. En ferdighet kan være ødelagt, utdatert, eller i mange tilfeller ikke bedre enn hva grunnmodellen kan gjøre på egen hånd. Dette skaper et betydelig signal-til-støy-problem.

Hos SkillProof lister vi ikke ferdigheter; vi tester dem. Fordi vi har kjørt hver katalog-ferdighet mot en grunnlinje, kan vi fastslå den faktiske andelen som slår en Claude uten ferdigheter, med bevisene som underbygger det. Denne artikkelen presenterer disse bevisene. Vi måler ytelsen til hver ferdighet mot den samme modellen uten noen ferdighet installert for å avgjøre om den gir en reell, kvantifiserbar fordel.

Signal-til-støy-problemet ved oppdagelse av ferdigheter

Hvis du har prøvd å integrere ferdigheter i arbeidsflyten din, har du sannsynligvis støtt på oppdagelsesproblemet. Du har en oppgave i tankene, kanskje å generere Terraform-konfigurasjoner eller interagere med et spesifikt SaaS-API. Du søker i en katalog, finner en ferdighet med et lovende navn, og leser dens SKILL.md-fil, som beskriver funksjonen og gir brukseksempler.

Du installerer den og prøver eksempel-prompten. Noen ganger fungerer det. Oftere innebærer prosessen friksjon. Ferdigheten kan kaste en feil, kreve udokumenterte miljøvariabler, eller produsere et resultat som ikke ligner på eksempelet. Du kan bruke en time på å feilsøke andres verktøy bare for å oppdage at det var dårlig skrevet eller forlatt for måneder siden.

Denne prøving-og-feiling-syklusen er ineffektiv. Kjerneproblemet er at de fleste ferdighetskataloger fungerer som pakkebehandlere uten en CI/CD-pipeline. De indekserer det som finnes, men gir ingen kvalitetsgaranti. Det finnes ingen uavhengig verifisering for å bekrefte at en ferdighet fungerer som annonsert, for ikke å snakke om at den tilbyr en forbedring over en godt utformet prompt til grunnmodellen. Testbyrden faller i sin helhet på sluttbrukeren.

Dette er problemet vi satte oss for å løse. For å avgjøre om Claude-kodeferdigheter er verdt å installere, trenger du en konsistent, repeterbar testmetodikk og en klar grunnlinje for sammenligning.

Hvordan vi måler «bedre»: Grunnlinjen uten ferdigheter

For å svare på spørsmålet «Er denne ferdigheten bedre enn ingenting?», trenger du en streng definisjon av «ingenting». For oss er «ingenting» selve grunnmodellen til Claude – det vi kaller grunnlinjen uten ferdigheter. Hele vår metodikk er bygget på å sammenligne en ferdighets ytelse mot denne kontrollen.

Prosessen er rett frem og designet for å speile et reelt bruksområde. For hver ferdighet utfører vi følgende trinn:

1. Definere testcaser: Vi analyserer ferdighetens tiltenkte funksjon og lager et sett med representative oppgaver. For en Kubernetes manifest-generator kan dette innebære prompter for å lage Deployment-, Service- og Ingress-objekter med varierende kompleksitet.

2. Kjøre grunnlinjen: Vi kjører disse test-promptene mot den rene Claude-modellen uten noen ferdighet installert. Vi lagrer resultatet som vår kontroll-case. Dette viser hva en kompetent bruker kan oppnå kun med prompting.

3. Kjøre ferdigheten: Vi installerer ferdigheten og kjører nøyaktig det samme settet med test-prompter. Dette er vår eksperimentelle case.

4. Poengsette resultatene: En menneskelig evaluator sammenligner grunnlinjens resultat og ferdighetens resultat side om side. Vi bruker en detaljert rubrikk for å poengsette dem på korrekthet, fullstendighet, etterlevelse av instruksjoner og effektivitet. Den endelige dommen er en enkelt poengsum av 10 som måler løftet ferdigheten gir over grunnlinjen.

En høy poengsum (8–10/10) indikerer en betydelig forbedring. En middels poengsum (6–7/10) indikerer en funksjonell ferdighet som gir en marginal fordel. En lav poengsum (1–5/10) indikerer en ferdighet som er buggy, vanskelig å bruke, eller yter dårligere enn grunnlinjen. Du kan lese alle detaljene om poengsystemet vårt på vår /methodology-side.

Denne claude skills vs no skill baseline-sammenligningen er den eneste måten å generere objektive data om en ferdighets sanne verdi. Markedsføringspåstander og forfatterbeskrivelser er irrelevante; det eneste som betyr noe er den målte ytelsen på en reell oppgave.

Dommen: Hvilken prosentandel av Claude-ferdigheter fungerer?

Så, hva sier dataene? Etter å ha anvendt vår metodikk på det offentlige økosystemet for ferdigheter, trer et tydelig bilde frem. I skrivende stund har vi installert og kjørt 1416 unike ferdigheter.

Resultatene viser at et flertall av ferdighetene gir en viss verdi, men en svært betydelig andel – over en tredjedel – er enten ødelagte, krever komplekst oppsett, eller er aktivt skadelige for modellens ytelse.

Her er hovedoversikten over funnene våre:

Dom	Antall	Andel av totalen	Beskrivelse
Godkjent & listet	889	63%	Ferdigheten installeres rent, fungerer som beskrevet, og scorer høyere enn grunnlinjen uten ferdigheter.
Krever manuelt oppsett	467	33%	Ferdigheten er funksjonell, men krever udokumentert oppsett (f.eks. miljøvariabler, API-nøkler) eller har store forbehold.
Scorer under grunnlinjen	60	4%	Ferdigheten er aktivt skadelig, og produserer resultater som er mindre nøyaktige, mindre komplette, eller mer feilutsatte enn ren Claude.

Disse tallene er nøkterne. Selv om det er bra at nesten to tredjedeler av ferdighetene består verifiseringen vår, betyr det at hvis du velger en tilfeldig ferdighet fra en offentlig katalog, har du 1 av 3 sjanse for at det er bortkastet tid.

Mer alarmerende er de 4 % som scorer under grunnlinjen. Dette er ferdigheter som ikke bare unnlater å hjelpe, men som aktivt gjør modellens resultat dårligere. Å installere en av disse er en nedgradering for systemet ditt. Disse dataene gir et klart svar på spørsmålet om hvilken prosentandel av Claude-ferdigheter som fungerer: det er langt fra 100 %.

Anatomien til en mislykket ferdighet

Å forstå hvorfor ferdigheter mislykkes er like viktig som å vite hvilke som lykkes. Feilene vi registrerer faller generelt i to kategorier: de som er aktivt skadelige og de som rett og slett er ufullstendige.

Kategori 1: Scorer under grunnlinjen

De 60 ferdighetene i denne kategorien representerer det verste scenarioet. De lover å legge til en kapabilitet, men introduserer i stedet feil, begrensninger eller regresjoner. For eksempel testet vi en SQL-spørringsgenerator som var ment å skrive komplekse spørringer fra naturlig språk. På våre test-prompter produserte den konsekvent syntaktisk ugyldig SQL. Den rene Claude-grunnlinjen, gitt de samme promptene, produserte korrekt SQL hver gang. Ferdighetens interne logikk var feilaktig, og styrte aktivt modellen mot et dårligere utfall.

En annen vanlig feilmodus er overbegrensning. En ferdighet designet for å håndheve et spesifikt JSON-skjema kan være så rigid at den får modellen til å nekte å svare på legitime prompter som faller litt utenfor dens snevre definisjon, mens grunnmodellen ville ha håndtert forespørselen elegant. Disse ferdighetene er verre enn ubrukelige; de er en belastning.

Kategori 2: Krever manuelt oppsett

Dette er en mye større kategori, som omfatter 467 av ferdighetene vi testet. Disse ferdighetene er ikke nødvendigvis dårlig designet, men de er dårlig dokumentert. De representerer en massiv skjult tidskostnad for utviklere.

Et typisk eksempel er en ferdighet som fungerer som en klient for et tredjeparts-API. Koden kan være perfekt funksjonell, men SKILL.md-filen unnlater å nevne at brukeren først må registrere en konto, generere en API-nøkkel, og sette den som en miljøvariabel med navnet THIRD_PARTY_API_KEY. Uten denne informasjonen feiler ferdigheten med en generisk AuthenticationError.

Teamet vårt gjør jobben med å avdekke disse skjulte kravene og dokumenterer dem i funnene våre. Men for en gjennomsnittlig bruker er dette en blindvei. Ferdigheten fremstår som ødelagt, og de avinstallerer den etter en frustrerende halvtime med feilsøking. Dette er ikke en feil ved modellen, men en svikt i utvikleropplevelsen. Gode ferdigheter må være brukbare rett ut av boksen, med alle avhengigheter og konfigurasjonstrinn tydelig dokumentert.

Kjennetegn på en høytscorende ferdighet

Hvis en tredjedel av ferdighetene er problematiske, hvordan ser de andre to tredjedelene – de vellykkede – ut? Er Claude-kodeferdigheter verdt å installere? Ja, hvis de tilhører gruppen som scorer høyt.

Høytscorende ferdigheter deler flere felles trekk:

1. De gir ekte verktøy: De beste ferdighetene omformulerer ikke bare en prompt. De gir modellen tilgang til nye kapabiliteter. En ferdighet som kan sjekke en URL for en 200 OK-status, et fil-patching-verktøy som kan anvende en diff på en lokal fil, eller en ferdighet som interagerer med en live skyleverandørs API, er alle eksempler på ekte verktøy. De lar modellen utføre handlinger i verden, ikke bare snakke om dem. Dette gir et klart, ubestridelig løft over grunnlinjen.

2. De er atomiske og pålitelige: Toppferdigheter fokuserer på å gjøre én ting bra. En ferdighet for å konvertere et tidsstempel til en ISO 8601-streng er mer sannsynlig å være robust og nyttig enn en monolittisk «DevOps-assistent»-ferdighet som prøver å gjøre tjue forskjellige ting.

3. De har utmerket dokumentasjon: SKILL.md-filen behandles som en kritisk del av verktøyet. Den inneholder klare instruksjoner, fungerende eksempler for vanlige bruksområder, og eksplisitt dokumentasjon av alt nødvendig oppsett, som miljøvariabler eller autentisering.

Når en ferdighet oppfyller disse kriteriene, er forbedringen ikke subtil. Den transformerer modellen fra en tekstgenerator til en interaktiv agent som kan utføre oppgaver, noe som sparer betydelig tid og krefter. Dette er ferdighetene som innfrir det opprinnelige løftet.

Finne ferdigheter som faktisk forbedrer arbeidsflyten din

Den sentrale lærdommen fra forskningen vår er at det rene antallet tilgjengelige ferdigheter er en forfengelighetsmetrikk. Økosystemets verdi ligger ikke i størrelsen, men i tettheten av verifiserte verktøy av høy kvalitet. Å blindt installere ferdigheter basert på beskrivelsene deres er en ineffektiv og frustrerende strategi.

Spørsmålet utviklere bør stille er ikke «forbedrer Claude-ferdigheter faktisk resultatet?», men heller «hvilke ferdigheter forbedrer resultatet, og med hvor mye?»

Å svare på det spørsmålet er grunnen til at vi bygget SkillProof. Vi kjører testene og publiserer resultatene – inkludert de mislykkede – slik at du kan ta i bruk ferdigheter med selvtillit. Vår katalog er ikke en uttømmende liste over alle eksisterende ferdigheter. Det er en kuratert katalog over ferdigheter som beviselig fungerer og gir en målbar fordel over grunnlinjen uten ferdigheter.

Relatert lesing: hvorfor så mange ferdigheter ikke holder mål · om GitHub-stjerner forutsier en god ferdighet.

Poenget med disse dataene er ikke å fraråde bruk av ferdigheter, men å oppmuntre til å bruke de riktige. Vi har gjort jobben med å teste 1416 ferdigheter, så du slipper. Du kan bla gjennom de 889 ferdighetene som besto våre grunnlinjetester i vår fulle katalog. Hvis du vil hoppe over blaingen, tilbyr vi også en kuratert pakke med de 50 mest effektfulle ferdighetene for $10.