GitHub-stjerner vs. testet ydeevne: En dårlig korrelation for Claude-skills

Som udviklere bruger vi heuristikker til at navigere i den overvældende mængde af open source-værktøjer. En af de mest almindelige er et repositorys popularitet. Når man står over for flere muligheder, føles sortering efter antal GitHub-stjerner som et rationelt første skridt. Antagelsen er, at stjerner er en proxy for kvalitet – et 'wisdom-of-the-crowds'-signal, der indikerer, at et projekt er nyttigt, stabilt og vedligeholdt. For modne økosystemer som web-frameworks eller databaser holder denne heuristik ofte stik. For Claude-skills viser vores data, at den ofte fejler.

Hos SkillProof har vi ikke adgang til private data om antal installationer for skills. Helt ærligt er der ingen uden for platformudbyderne, der har det, hvilket gør enhver diskussion om claude skill install numbers meaning rent spekulativ. Hvad vi har, er det offentlige antal stjerner for hver skill, vi tester, og vores egen testede bedømmelse. Efter at have installeret og kørt 1416 skills på standardiserede opgaver, kan vi med sikkerhed konstatere, at der er en svag og ofte vildledende korrelation mellem en skills antal stjerner og dens faktiske, testede ydeevne.

Denne artikel undersøger denne uoverensstemmelse. Vi vil se på, hvorfor populære skills ofte ikke leverer, og hvorfor nogle af de bedst ydende skills findes i den lange hale af ukendthed. Det centrale spørgsmål er ikke kun, om populære Claude-skills er gode, men om popularitet i sig selv er en nyttig metrik for kvalitet i dette økosystem. Vores resultater tyder på, at det ikke er tilfældet.

Tiltrækningen ved socialt bevis

Det er let at forstå, hvorfor stjerner er standardmetrikken for opdagelse. Et højt antal stjerner antyder, at et projekt har fanget mange andre udvikleres opmærksomhed. Dette sociale bevis indebærer et par ting: konceptet er værdifuldt, koden er blevet gennemgået af mange øjne, og der findes et community til at støtte det. I teorien fører flere brugere til flere fejlrapporter, flere pull requests og et mere robust værktøj over tid.

Denne logik understøtter de fleste softwareøkosystemer. Økosystemet for Claude-skills har dog unikke karakteristika, der underminerer denne model. Adgangsbarrieren er lav, hvilket fører til en spredning af skills, der er eksperimentelle, ufuldstændige eller blot wrappers om en enkelt prompt. Ændringstempoet i de underliggende modeller er højt, hvilket betyder, at en skill, der virkede for seks måneder siden, kan være i stykker eller, endnu værre, suboptimal i dag på grund af 'dependency rot' eller ændringer i basismodellens adfærd.

Desuden kan stjerner være en forsinket indikator for kvalitet, eller en indikator for hype snarere end nytteværdi. En smart README.md eller et viralt opslag på sociale medier kan generere tusindvis af stjerner for et projekt, der er lidt mere end et koncept. Stjernerne bliver hængende længe efter, at den indledende begejstring er forsvundet, og repositoryet ligger inaktivt. Dette er den virkelighed, vi møder dagligt.

Hvad 1416 testede skills afslører

Vores proces er ligetil: vi finder en skill, installerer den og kører den mod en reel opgave defineret i vores testmetodologi. En skill enten består, kræver manuel opsætning ud over de dokumenterede instruktioner, eller den fejler. En fejl kan betyde, at den producerer en fejl, timer ud eller – mest kritisk – leverer et resultat, der er målbart dårligere end at bruge ren Claude til den samme opgave.

Her er den overordnede opdeling af vores resultater fra 1416 testede skills til dato:

• 889 Bestået (63%): Skill'en installeres og udfører sin annoncerede funktion korrekt i vores testcase.
• 467 Kræver opsætning (33%): Skill'en fejler 'out of the box', men kan bringes til at virke med en ikke-triviel indsats, såsom manuel installation af afhængigheder, kodeændringer eller udokumenteret konfiguration.
• 60 Fejlet (4%): Skill'en er i stykker, eller dens output er ringere end basismodellens. Vi klassificerer disse som et netto-negativt; du er bedre stillet ved ikke at installere dem.

Den vigtigste konklusion er, at over en tredjedel af de skills i vores katalog ikke virker som annonceret ved installation. Dette inkluderer et betydeligt antal repositories med høje antal stjerner. Den simple handling at sortere efter popularitet på en platform som GitHub vil uundgåeligt fremhæve skills, der er 'abandonware', kræver opsætning på ekspertniveau eller simpelthen er i stykker.

Anatomien af en fejl med mange stjerner

Selvom vi ikke navngiver specifikke skills i denne sammenhæng, er mønstrene for fejl blandt populære repositories konsistente. Dette er ikke 'edge cases'; de er tilbagevendende arketyper på uoverensstemmelsen mellem popularitet og ydeevne.

En almindelig arketype er det over-markedsførte koncept. Vi har testet adskillige skills med tusindvis af stjerner, der lover at revolutionere en arbejdsgang, såsom frontend-design. Når vi kører vores test, producerer skill'en syntaktisk ugyldig kode, bruger forældede mønstre eller genererer et design, der er mindre sammenhængende end det, en simpel, velformuleret prompt til basismodellen producerer. Det høje antal stjerner afspejler begejstring for idéen bag skill'en, ikke kvaliteten af dens udførelse. Dette er en nøglefaktor, når man overvejer frontend-design skill install count quality – den opfattede popularitet garanterer ikke et fungerende produkt.

En anden er den sovende kæmpe. Dette var en velbygget, reelt nyttig skill på tidspunktet for dens oprettelse. Den fik en stor følgeskare og mange stjerner. Så gik maintaineren videre. To år senere er dens afhængigheder forældede, den kalder API'er, der ikke længere eksisterer, og den fejler på den nuværende version af Claude-platformen. Stjernerne forbliver og fungerer som en fælde for nye brugere, der antager, at projektet stadig er aktivt og pålideligt.

Den måske mest bekymrende kategori er den skill, der aktivt hæmmer ydeevnen. Vi har testet 60 skills, der scorede under basis-ydeevnen for ren Claude. For eksempel kan en skill, der er beregnet til at hjælpe med koderefactoring, anvende stive, forældede linting-regler, der gør koden mindre læsbar, eller en dataanalyse-skill kan hallucinere API-kald til biblioteker, den ikke har adgang til. Disse skills undlader ikke kun at hjælpe; de gør aktivt outputtet værre. Mange af disse underpræsterende skills har hundreder eller endda tusinder af stjerner.

I den lange hale: At finde lavprofil-vindere

Omvendt har nogle af de mest effektive og pålidelige skills i vores katalog færre end 50 stjerner. Disse er ofte målrettede værktøjer bygget af udviklere til at løse et specifikt, personligt problem. De gør én ting og gør det exceptionelt godt.

Disse skjulte perler har ikke det samme marketing-push som deres mere populære modstykker. Deres README.md kan være sparsom, og de har måske ikke et smart logo. Hvad de har, er ren, funktionel kode, der er blevet forfinet gennem praktisk brug. Vi fandt en skill med kun en håndfuld stjerner, der perfekt automatiserer processen med at konvertere komplekse JSON-objekter til klare Markdown-tabeller, og som scorede 9/10 i vores tests. En anden, et nicheværktøj til at generere database-migrationsscripts, bestod vores tests fejlfrit, mens større, mere populære værktøjer kæmpede med forskellige SQL-dialekter.

Disse succeser fremhæver kerneproblemet ved at bruge popularitet som et filter: det optimerer for synlighed, ikke for nytteværdi. De mest synlige projekter er ikke altid de mest værdifulde. Den reelle værdi ligger ofte i den lange hale af specialiserede værktøjer, men at opdage dem kræver en systematisk, evidensbaseret tilgang – ikke en simpel sortering efter stjerner.

Fra socialt bevis til 'ground truth': En bedre metrik

Hvis stjerner er en upålidelig proxy, hvad er så alternativet? Den eneste sande måling af en skills kvalitet er dens ydeevne på en reel opgave. Dette er 'ground truth'. Udfordringen er, at det at etablere denne sandhed for bare en enkelt skill kræver tid og kræfter: at klone repo'et, oprette et testmiljø, udforme en testcase og køre skill'en.

Dette er det arbejde, vi udfører hos SkillProof. Vores /10-score er ikke et udtryk for vores mening. Det er en registrering af et testet resultat. En høj score betyder, at skill'en bestod en gentagelig, objektiv test. En lav score betyder, at den fejlede.

Her er, hvordan de to metrikker sammenlignes i praksis:

Metrik	Hvad den antyder	Hvad den ofte betyder i virkeligheden
Højt antal stjerner	"Dette er en højkvalitets, betroet skill."	"Denne var populær på et tidspunkt; virker måske/måske ikke nu."
SkillProof Score > 7/10	"Denne skill vil sandsynligvis virke for dig."	"Vi installerede og kørte denne på en reel opgave, og den bestod."
SkillProof Bedømmelse: Fejlet	"Denne skill har en bug."	"Denne skill ydede dårligere end ren Claude i vores test."

Når du beslutter, om du vil installere en skill, er spørgsmålet, du bør stille, ikke "Er denne populær?", men "Virker den?". De 60 skills, der scorede under basismodellen, er en skarp påmindelse om, at popularitet kan være aktivt vildledende.

En praktisk ramme for evaluering af skills

Givet upålideligheden af popularitetsmetrikker har udviklere brug for en mere robust ramme til at evaluere Claude-skills. At stole på et katalog, der allerede har udført testningen, er den mest effektive vej, men hvis du evaluerer en skill på egen hånd, er en sund dosis skepsis dit bedste værktøj.

For det første, betragt antallet af stjerner som en historisk artefakt, ikke en aktuel godkendelse. Det indikerer tidligere interesse, ikke nuværende kvalitet. Grav dybere.

For det andet, tjek repositoryets aktivitet. Se på datoen for den seneste commit. Er der nylige, meningsfulde ændringer, eller var den seneste opdatering for to år siden? Læs de åbne 'issues'. Rapporterer brugere kritiske fejl? Svarer maintaineren? En levende 'issue tracker' med aktiv diskussion er et meget bedre tegn på sundhed end et højt antal stjerner på et tavst repository.

For det tredje, læs kildekoden, hvis du kan. Mange skills er ret små. Du kan ofte få en fornemmelse af kodekvaliteten og den valgte tilgang på få minutter. Kig på SKILL.md-filen. Virker prompt-engineeringen sofistikeret, eller er det en simpel skabelon, som du nemt selv kunne replikere?

I sidste ende er den eneste måde at være sikker på at teste skill'en selv på en ikke-kritisk opgave. Denne proces – klon, installer, konfigurer, test, evaluer – er grundlaget for pålidelig evaluering. Det er også en betydelig investering af tid, især når det gentages på tværs af dusinvis af potentielle skills.

Relateret læsning: hvor mange indekserede skills rent faktisk kører · de skills der opnåede en topbedømmelse.

Vi byggede SkillProof, fordi vi mener, at dette verifikationstrin er essentielt, og vi ved, at de fleste udviklere ikke har tid til at gøre det selv for hvert værktøj, de overvejer. Vi har kørt testene på 1416 skills, så du ikke behøver at gøre det. Du kan gennemse alle 889 beståede skills i vores katalog for at finde værktøjer, der er verificeret til at virke, eller købe vores kuraterede pakke med de 10 bedste testede, generelle skills for en engangspris på $10.