GitHub-stjärnor vs. testad prestanda: En svag korrelation för Claude-skills

Som utvecklare använder vi heuristik för att navigera i den överväldigande mängden open source-verktyg. En av de vanligaste är ett repositorys popularitet. När man står inför flera alternativ känns det som ett rationellt första steg att sortera efter antal GitHub-stjärnor. Antagandet är att stjärnor är en proxy för kvalitet, en signal från kollektivets visdom som indikerar att ett projekt är användbart, stabilt och underhållet. För mogna ekosystem som webbramverk eller databaser stämmer denna heuristik ofta. För Claude-skills visar vår data att den ofta inte stämmer.

På SkillProof har vi inte tillgång till privat data om antalet installationer för skills. Ärligt talat har ingen utanför plattformsleverantörerna det, vilket gör all diskussion om claude skill install numbers meaning rent spekulativ. Det vi har är det publika antalet stjärnor för varje skill vi testar, och vårt eget testade utlåtande. Efter att ha installerat och kört 1416 skills på standardiserade uppgifter kan vi med säkerhet konstatera att det finns en svag och ofta vilseledande korrelation mellan en skills stjärnantal och dess faktiska, testade prestanda.

Den här artikeln undersöker den diskrepansen. Vi kommer att titta på varför populära skills ofta inte levererar och varför några av de bäst presterande hittas i 'the long tail' av obskyra projekt. Den centrala frågan är inte bara om populära Claude-skills är bra, utan om popularitet i sig är ett användbart mått på kvalitet i detta ekosystem. Våra resultat tyder på att så inte är fallet.

Lockelsen med sociala bevis

Det är lätt att förstå varför stjärnor är standardmåttet för att upptäcka nya projekt. Ett högt antal stjärnor tyder på att ett projekt har fångat många andra utvecklares uppmärksamhet. Detta sociala bevis antyder några saker: konceptet är värdefullt, koden har granskats av många, och det finns en community som stöder det. I teorin leder fler användare till fler buggrapporter, fler pull requests och ett mer robust verktyg över tid.

Denna logik ligger till grund för de flesta mjukvaruekosystem. Ekosystemet för Claude-skills har dock unika egenskaper som underminerar denna modell. Ingångsbarriären är låg, vilket leder till en spridning av skills som är experimentella, ofullständiga eller bara 'wrappers' runt en enda prompt. Förändringstakten i de underliggande modellerna är snabb, vilket innebär att en skill som fungerade för sex månader sedan kan vara trasig eller, ännu värre, suboptimal idag på grund av föråldrade beroenden ('dependency rot') eller ändringar i basmodellens beteende.

Dessutom kan stjärnor vara en eftersläpande indikator på kvalitet, eller en indikator på 'hype' snarare än nytta. En smart README.md eller ett viralt inlägg på sociala medier kan generera tusentals stjärnor för ett projekt som är lite mer än ett koncept. Stjärnorna finns kvar långt efter att den initiala entusiasmen har svalnat och repositoryt ligger vilande. Detta är den verklighet vi möter dagligen.

Vad 1416 testade skills avslöjar

Vår process är enkel: vi hittar en skill, installerar den och kör den mot en verklig uppgift definierad i vår testmetodik. En skill blir antingen godkänd, kräver manuell konfiguration utöver de dokumenterade instruktionerna, eller så misslyckas den. Ett misslyckande kan innebära att den producerar ett fel, får en 'timeout', eller – mest kritiskt – levererar ett resultat som är mätbart sämre än att använda Claude direkt för samma uppgift.

Här är den övergripande sammanfattningen av våra resultat från 1416 testade skills hittills:

• 889 Godkända (63 %): Skillen installeras och utför sin utlovade funktion korrekt på vårt testfall.
• 467 Kräver konfiguration (33 %): Skillen fungerar inte direkt efter installation men kan fås att fungera med en icke-trivial ansträngning, såsom manuell installation av beroenden, kodändringar eller odokumenterad konfiguration.
• 60 Misslyckade (4 %): Skillen är trasig, eller dess output är sämre än basmodellen. Vi klassificerar dessa som en nettoförlust; det är bättre att inte installera dem.

Den viktigaste slutsatsen är att över en tredjedel av alla skills i vår katalog inte fungerar som utlovat vid installation. Detta inkluderar ett betydande antal repositories med höga stjärnantal. Att bara sortera efter popularitet på en plattform som GitHub kommer oundvikligen att lyfta fram skills som är 'abandonware', kräver konfiguration på expertnivå eller helt enkelt är trasiga.

Anatomin hos ett misslyckande med många stjärnor

Vi nämner inga specifika skills i det här sammanhanget, men felmönstren bland populära repositories är konsekventa. Det här är inte några enstaka fall; de är återkommande arketyper för diskrepansen mellan popularitet och prestanda.

En vanlig arketyp är det övermarknadsförda konceptet. Vi har testat flera skills med tusentals stjärnor som lovar att revolutionera ett arbetsflöde, till exempel frontend-design. När vi kör vårt test producerar skillen syntaktiskt ogiltig kod, använder föråldrade ('deprecated') mönster, eller genererar en design som är mindre sammanhängande än vad en enkel, välformulerad prompt till basmodellen ger. Det höga antalet stjärnor återspeglar entusiasm för idén bakom skillen, inte kvaliteten på dess utförande. Detta är en nyckelfaktor att beakta gällande frontend-design skill install count quality – den upplevda populariteten garanterar inte en fungerande produkt.

En annan är den vilande jätten. Detta var en välbyggd och genuint användbar skill när den skapades. Den fick ett stort följe och många stjärnor. Sedan gick underhållaren vidare. Två år senare är dess beroenden föråldrade, den anropar API:er som inte längre finns, och den fungerar inte på den nuvarande versionen av Claude-plattformen. Stjärnorna finns kvar och fungerar som en fälla för nya användare som antar att projektet fortfarande är aktivt och tillförlitligt.

Den kanske mest oroande kategorin är den skill som aktivt försämrar prestandan. Vi har testat 60 skills som presterade sämre än baslinjen för Claude utan skills. Till exempel kan en skill avsedd för kodrefaktorering tillämpa stela, föråldrade linting-regler som gör koden mindre läsbar, eller en skill för dataanalys kan hallucinera API-anrop för bibliotek den inte har tillgång till. Dessa skills misslyckas inte bara med att hjälpa; de gör aktivt resultatet sämre. Många av dessa underpresterande skills har hundratals eller till och med tusentals stjärnor.

I 'the long tail': Att hitta vinnare med låg profil

Omvänt har några av de mest effektiva och tillförlitliga skillsen i vår katalog färre än 50 stjärnor. Dessa är ofta riktade verktyg byggda av utvecklare för att lösa ett specifikt, personligt problem. De gör en sak och gör den exceptionellt bra.

Dessa dolda pärlor har inte samma marknadsföringskraft som sina mer populära motsvarigheter. Deras README.md kan vara sparsam, och de kanske inte har en flashig logotyp. Vad de däremot har är ren, funktionell kod som har förfinats genom praktisk användning. Vi hittade en skill med bara en handfull stjärnor som perfekt automatiserar processen att konvertera komplexa JSON-objekt till tydliga Markdown-tabeller, och som fick 9/10 i våra tester. En annan, ett nischat verktyg för att generera databasmigreringsskript, klarade våra tester felfritt medan större, mer populära verktyg hade problem med olika SQL-dialekter.

Dessa framgångar belyser kärnproblemet med att använda popularitet som filter: det optimerar för synlighet, inte för nytta. De mest synliga projekten är inte alltid de mest värdefulla. Det verkliga värdet ligger ofta i 'the long tail' av specialiserade verktyg, men att upptäcka dem kräver ett systematiskt, evidensbaserat tillvägagångssätt – inte en enkel sortering efter stjärnor.

Från sociala bevis till 'ground truth': Ett bättre mått

Om stjärnor är en opålitlig proxy, vad är alternativet? Det enda sanna måttet på en skills kvalitet är dess prestanda på en verklig uppgift. Detta är 'ground truth'. Utmaningen är att det kräver tid och ansträngning att fastställa denna sanning för en enda skill: att klona repositoryt, skapa en testmiljö, utforma ett testfall och köra skillen.

Detta är arbetet vi gör på SkillProof. Vår /10-poäng är inte ett mått på vår åsikt. Det är ett protokoll över ett testat resultat. En hög poäng innebär att skillen klarade ett repeterbart, objektivt test. En låg poäng innebär att den misslyckades.

Här är hur de två måtten jämförs i praktiken:

Mått	Vad det antyder	Vad det ofta betyder i praktiken
Högt stjärnantal	"Detta är en högkvalitativ, betrodd skill."	"Denna var populär vid en tidpunkt; fungerar kanske, kanske inte, nu."
SkillProof-poäng > 7/10	"Denna skill kommer sannolikt att fungera för dig."	"Vi installerade och körde denna på en verklig uppgift, och den blev godkänd."
SkillProof-utlåtande: Misslyckad	"Denna skill har en bugg."	"Denna skill presterade sämre än Claude utan skills i vårt test."

När du bestämmer dig för om du ska installera en skill är frågan du bör ställa dig inte "Är den här populär?" utan "Fungerar den här?" De 60 skills som presterade sämre än basmodellen är en tydlig påminnelse om att popularitet kan vara aktivt vilseledande.

Ett praktiskt ramverk för utvärdering av skills

Med tanke på popularitetsmåttens opålitlighet behöver utvecklare ett mer robust ramverk för att utvärdera Claude-skills. Att förlita sig på en katalog som redan har gjort testerna är den mest effektiva vägen, men om du utvärderar en skill på egen hand är en hälsosam dos skepticism ditt bästa verktyg.

För det första, behandla stjärnantalet som en historisk artefakt, inte en aktuell rekommendation. Det indikerar tidigare intresse, inte nuvarande kvalitet. Gräv djupare.

För det andra, kontrollera repositoryts aktivitet. Titta på datumet för den senaste 'commit'. Finns det nyligen gjorda, meningsfulla ändringar, eller var den senaste uppdateringen för två år sedan? Läs de öppna 'issues'. Rapporterar användare kritiska fel? Svarar underhållaren? En livlig 'issue tracker' med aktiv diskussion är ett mycket bättre tecken på hälsa än ett högt stjärnantal på ett tyst repository.

För det tredje, läs källkoden om du kan. Många skills är ganska små. Du kan ofta få en känsla för kodkvaliteten och tillvägagångssättet på några minuter. Titta på filen SKILL.md. Verkar prompt-konstruktionen ('prompt engineering') sofistikerad, eller är det en enkel mall som du lätt skulle kunna återskapa själv?

I slutändan är det enda sättet att vara säker att testa skillen själv på en icke-kritisk uppgift. Denna process – klona, installera, konfigurera, testa, utvärdera – är grunden för en tillförlitlig utvärdering. Det är också en betydande tidsinvestering, särskilt när den upprepas för dussintals potentiella skills.

Relaterad läsning: how many indexed skills actually run · the skills that earned a top verdict.

Vi byggde SkillProof eftersom vi anser att detta verifieringssteg är avgörande, och vi vet att de flesta utvecklare inte har tid att göra det själva för varje verktyg de överväger. Vi har kört testerna på 1416 skills så att du inte behöver göra det. Du kan bläddra bland alla 889 godkända skills i vår katalog för att hitta verifierade verktyg som fungerar, eller köpa vårt utvalda paket med de 10 bästa testade, allmänna skillsen för ett engångspris på $10.