GitHub-stjerner vs. testet ytelse: En svak korrelasjon for Claude-ferdigheter

Som utviklere bruker vi heuristikk for å navigere i det overveldende volumet av åpen kildekode-verktøy. En av de vanligste er populariteten til et repository. Når man står overfor flere alternativer, føles det som et rasjonelt første steg å sortere etter antall GitHub-stjerner. Antakelsen er at stjerner er en proxy for kvalitet, et «wisdom-of-the-crowds»-signal som indikerer at et prosjekt er nyttig, stabilt og vedlikeholdt. For modne økosystemer som webrammeverk eller databaser, holder denne heuristikken ofte. For Claude-ferdigheter viser våre data at den ofte svikter.

Hos SkillProof har vi ikke tilgang til private data om antall installasjoner for ferdigheter. Ærlig talt er det ingen utenfor plattformleverandørene som har det, noe som gjør enhver diskusjon om claude skill install numbers meaning rent spekulativ. Det vi har, er det offentlige antallet stjerner for hver ferdighet vi tester, og vår egen testede dom. Etter å ha installert og kjørt 1416 ferdigheter på standardiserte oppgaver, kan vi med sikkerhet si at det er en svak og ofte villedende korrelasjon mellom en ferdighets stjernetall og dens faktiske, testede ytelse.

Denne artikkelen undersøker dette bruddet. Vi vil se på hvorfor populære ferdigheter ofte ikke leverer, og hvorfor noen av de best presterende ferdighetene finnes i den lange halen av obskuritet. Det sentrale spørsmålet er ikke bare om populære Claude-ferdigheter er gode, men om popularitet i seg selv er en nyttig målestokk for kvalitet i dette økosystemet. Våre funn tyder på at det ikke er det.

Fristelsen av sosiale bevis

Det er lett å forstå hvorfor stjerner er standardmålestokken for oppdagelse. Et høyt antall stjerner antyder at et prosjekt har fanget oppmerksomheten til mange andre utviklere. Dette sosiale beviset antyder et par ting: konseptet er verdifullt, koden har blitt gransket av mange øyne, og det finnes et fellesskap som kan gi støtte. I teorien fører flere brukere til flere feilrapporter, flere pull requests, og et mer robust verktøy over tid.

Denne logikken ligger til grunn for de fleste programvareøkosystemer. Økosystemet for Claude-ferdigheter har imidlertid unike egenskaper som undergraver denne modellen. Inngangsbarrieren er lav, noe som fører til en spredning av ferdigheter som er eksperimentelle, ufullstendige, eller omslag (wrappers) rundt en enkelt prompt. Endringstakten i de underliggende modellene er rask, noe som betyr at en ferdighet som fungerte for seks måneder siden, kan være ødelagt eller, verre, suboptimal i dag på grunn av «dependency rot» eller endringer i basismodellens oppførsel.

Videre kan stjerner være en etterslepende indikator på kvalitet, eller en indikator på «hype» snarere enn nytteverdi. En smart README.md eller et viralt innlegg i sosiale medier kan generere tusenvis av stjerner for et prosjekt som er lite mer enn et konsept. Stjernene blir værende lenge etter at den første begeistringen har lagt seg og repositoryet ligger brakk. Dette er virkeligheten vi møter daglig.

Hva 1416 testede ferdigheter avslører

Vår prosess er enkel: vi finner en ferdighet, installerer den, og kjører den mot en reell oppgave definert i vår testmetodikk. Ferdigheten enten består, krever manuelt oppsett utover de dokumenterte instruksjonene, eller den feiler. En feil kan bety at den produserer en feilmelding, tidsavbrudd, eller – mest kritisk – leverer et resultat som er målbart dårligere enn å bruke ren Claude for samme oppgave.

Her er en overordnet oversikt over våre funn fra 1416 ferdigheter testet til dags dato:

• 889 Bestått (63%): Ferdigheten installeres og utfører sin annonserte funksjon korrekt i vårt testtilfelle.
• 467 Krever oppsett (33%): Ferdigheten feiler rett etter installasjon, men kan fås til å fungere med betydelig innsats, som manuell installasjon av avhengigheter, kodeendringer, eller udokumentert konfigurasjon.
• 60 Feilet (4%): Ferdigheten er ødelagt, eller resultatet er dårligere enn basismodellen. Vi klassifiserer disse som en netto negativ; du er bedre tjent med å ikke installere dem.

Den viktigste lærdommen er at over en tredjedel av ferdighetene i vår katalog ikke fungerer som annonsert ved installasjon. Dette inkluderer et betydelig antall repositories med høyt stjernetall. Den enkle handlingen å sortere etter popularitet på en plattform som GitHub vil uunngåelig løfte frem ferdigheter som er «abandonware», krever ekspert-nivå oppsett, eller rett og slett er ødelagte.

Anatomien til en fiasko med mange stjerner

Selv om vi ikke navngir spesifikke ferdigheter i denne sammenhengen, er feilmønstrene blant populære repositories konsistente. Dette er ikke unntakstilfeller; de er gjentakende arketyper på bruddet mellom popularitet og ytelse.

En vanlig arketype er det Over-markedsførte konseptet. Vi har testet flere ferdigheter med tusenvis av stjerner som lover å revolusjonere en arbeidsflyt, for eksempel frontend-design. Når vi kjører testen vår, produserer ferdigheten syntaktisk ugyldig kode, bruker utdaterte mønstre, eller genererer et design som er mindre sammenhengende enn det en enkel, velformulert prompt til basismodellen produserer. Det høye antallet stjerner reflekterer begeistring for ideen bak ferdigheten, ikke kvaliteten på utførelsen. Dette er en nøkkelfaktor når man vurderer frontend-design skill install count quality—den oppfattede populariteten garanterer ikke et fungerende produkt.

En annen er den Sovende kjempen. Dette var en velbygd, genuint nyttig ferdighet da den ble skapt. Den fikk en stor følgerskare og mange stjerner. Så gikk vedlikeholderen videre. To år senere er avhengighetene utdaterte, den kaller API-er som ikke lenger eksisterer, og den krasjer på den nåværende versjonen av Claude-plattformen. Stjernene blir værende, og fungerer som en felle for nye brukere som antar at prosjektet fortsatt er aktivt og pålitelig.

Den kanskje mest bekymringsfulle kategorien er ferdigheten som Aktivt hemmer ytelsen. Vi har testet 60 ferdigheter som scoret under grunnlinjeytelsen til ren Claude. For eksempel kan en ferdighet ment for å hjelpe med koderefaktorering anvende rigide, utdaterte linting-regler som gjør koden mindre lesbar, eller en ferdighet for dataanalyse kan hallusinere API-kall for biblioteker den ikke har tilgang til. Disse ferdighetene unnlater ikke bare å hjelpe; de gjør aktivt resultatet dårligere. Mange av disse underpresterende ferdighetene har hundrevis eller til og med tusenvis av stjerner.

I den lange halen: Finne lavprofil-vinnere

Motsatt har noen av de mest effektive og pålitelige ferdighetene i vår katalog færre enn 50 stjerner. Dette er ofte målrettede verktøy bygget av utviklere for å løse et spesifikt, personlig problem. De gjør én ting, og de gjør den eksepsjonelt bra.

Disse skjulte perlene har ikke markedsføringstrykket til sine mer populære motstykker. Deres README.md kan være sparsom, og de har kanskje ikke en glatt logo. Det de har, er ren, funksjonell kode som har blitt raffinert gjennom praktisk bruk. Vi fant en ferdighet med bare en håndfull stjerner som perfekt automatiserer prosessen med å konvertere komplekse JSON-objekter til oversiktlige Markdown-tabeller, og scoret 9/10 i våre tester. En annen, et nisjeverktøy for å generere databasemigrerings-skript, besto testene våre feilfritt mens større, mer populære verktøy slet med forskjellige SQL-dialekter.

Disse suksessene fremhever kjerneproblemet med å bruke popularitet som et filter: den optimaliserer for synlighet, ikke nytteverdi. De mest synlige prosjektene er ikke alltid de mest verdifulle. Den virkelige verdien ligger ofte i den lange halen av spesialiserte verktøy, men å oppdage dem krever en systematisk, evidensbasert tilnærming—ikke en enkel sortering etter stjerner.

Fra sosialt bevis til 'ground truth': En bedre målestokk

Hvis stjerner er en upålitelig proxy, hva er alternativet? Den eneste sanne målingen på en ferdighets kvalitet er dens ytelse på en reell oppgave. Dette er «ground truth». Utfordringen er at å etablere denne sannheten for selv en enkelt ferdighet krever tid og innsats: å klone repoet, opprette et testmiljø, lage et testtilfelle, og kjøre ferdigheten.

Dette er arbeidet vi gjør hos SkillProof. Vår /10-score er ikke et mål på vår mening. Det er en registrering av et testet resultat. En høy score betyr at ferdigheten besto en repeterbar, objektiv test. En lav score betyr at den feilet.

Her er hvordan de to målestokkene kan sammenlignes i praksis:

Målestokk	Hva den antyder	Hva den ofte betyr i praksis
Høyt antall stjerner	"Dette er en pålitelig ferdighet av høy kvalitet."	"Denne var populær på et tidspunkt; fungerer kanskje, kanskje ikke nå."
SkillProof-score > 7/10	"Denne ferdigheten vil sannsynligvis fungere for deg."	"Vi installerte og kjørte denne på en reell oppgave, og den besto."
SkillProof-dom: Feilet	"Denne ferdigheten har en bug."	"Denne ferdigheten presterte dårligere enn ren Claude på vår test."

Når du bestemmer deg for om du skal installere en ferdighet, er spørsmålet du bør stille ikke «Er denne populær?» men «Fungerer denne?». De 60 ferdighetene som scoret under basismodellen er en sterk påminnelse om at popularitet kan være aktivt villedende.

Et praktisk rammeverk for evaluering av ferdigheter

Gitt upåliteligheten til popularitetsmålinger, trenger utviklere et mer robust rammeverk for å evaluere Claude-ferdigheter. Å stole på en katalog som allerede har gjort testingen er den mest effektive veien, men hvis du evaluerer en ferdighet på egen hånd, er en sunn dose skepsis ditt beste verktøy.

For det første, behandle antall stjerner som en historisk artefakt, ikke en nåværende anbefaling. Det indikerer tidligere interesse, ikke nåværende kvalitet. Grav dypere.

For det andre, sjekk aktiviteten i repositoryet. Se på datoen for siste commit. Er det nylige, meningsfulle endringer, eller var siste oppdatering for to år siden? Les de åpne issues. Rapporterer brukere kritiske feil? Svarer vedlikeholderen? En levende «issue tracker» med aktiv diskusjon er et mye bedre tegn på sunnhet enn et høyt stjernetall på et stille repository.

For det tredje, les kildekoden hvis du kan. Mange ferdigheter er ganske små. Du kan ofte få en følelse av kodekvaliteten og tilnærmingen som er tatt på noen få minutter. Se på SKILL.md-filen. Virker prompt-utformingen («prompt engineering») sofistikert, eller er det en enkel mal du lett kunne replikert selv?

Til syvende og sist er den eneste måten å være sikker på å teste ferdigheten selv på en ikke-kritisk oppgave. Denne prosessen—klone, installere, konfigurere, teste, evaluere—er grunnlaget for pålitelig evaluering. Det er også en betydelig investering av tid, spesielt når den gjentas over dusinvis av potensielle ferdigheter.

Relatert lesing: hvor mange indekserte ferdigheter som faktisk kjører · ferdighetene som fikk en toppvurdering.

Vi bygget SkillProof fordi vi mener dette verifiseringssteget er essensielt, og vi vet at de fleste utviklere ikke har tid til å gjøre det selv for hvert verktøy de vurderer. Vi har kjørt testene på 1416 ferdigheter så du slipper. Du kan bla gjennom alle 889 godkjente ferdigheter i vår katalog for å finne verktøy som er verifisert til å fungere, eller kjøpe vår kuraterte pakke med de 10 beste testede, generelle ferdighetene for en engangspris på $10.