Så testar vi Claude-skills: SkillProof-protokollet

Hela sajten började med en skill som inte gjorde någonting. Sent 2025 gick en produktivitetsskill runt på X med några tusen stjärnor bakom sig. Vi installerade den, startade om Claude Code, skrev exakt användningsfallet från README:n, och såg Claude svara som om skillen inte fanns. Kollade mappen: filer fanns, frontmatter var giltig. Skrev en annan formulering. Inget. Skillen triggades aldrig en enda gång på fyrtio minuter, och inget på repo-sidan skulle ha förutspått det. Stjärnor mäter om en README är spännande. De säger inget om huruvida mappen under den fungerar.

Den kvällen lämnade en fråga vi inte kunde skaka av oss: om en skill med den uppmärksamheten kan vara död vid ankomst, hur ser resten av ekosystemet ut? Så vi började installera skills på en ren maskin och skriva ner vad som hände. Svaret, dokumenterat i vår misslyckande-data, är att ungefär hälften av community-skills misslyckas innan de hjälper någon. Det här inlägget är den andra sidan av det fyndet: det exakta protokollet bakom varje dom på SkillProof, i tillräcklig detalj för att du ska kunna köra det på din egen skill innan du skeppar den.

Protokollet, steg för steg

Ett fullständigt test tar mellan 45 minuter och flera dagar, beroende på kategori. En dokumentskill bevisar sig själv på en sittning; en veckovis-genomgång-skill måste överleva en faktisk vecka. Oavsett är stegen desamma, och ordningen spelar roll, för varje steg grindar nästa. Det finns ingen poäng i att betygsätta resultat på en skill som aldrig triggas.

Steg 0: en ren miljö

Varje test börjar på en maskinprofil med en tom skills-mapp och standardinställningar för Claude Code. Det här låter som ceremoni tills första gången det räddar dig. Skills interagerar: en kan verka fungera för att en annan skill på maskinen tyst gör det tunga jobbet. Vi lärde oss det här genom att testa en förslagsskill på en maskin som redan hade docx-skillen installerad. Resultatet såg fantastiskt ut. På en ren profil försvann halva värdet, för dokumentskillen hade producerat den polerade .docx-filen hela tiden.

Steg 1: installera från författarens egna instruktioner

Vi öppnar repots README och följer den bokstavligt. Inte "vi listar ut hur man installerar den." Vi gör exakt vad författaren skrev, stavfel och allt, för det är vad varje verklig användare kommer göra. Om kommandona faktiskt producerar ~/.claude/skills/name/name/SKILL.md, en mapp för djupt, är det en misslyckad installation, även om vem som helst som känner till formatet kunde fixa det på tio sekunder. Vi kunde också fixa det. Poängen är att nykomlingen som följer med klockan 23 inte kan, och de kommer dra slutsatsen att Claude-skills är trasiga snarare än att en sökväg var fel.

Allt README:n inte nämner räknas mot den: odeklarerade beroenden, instruktioner skrivna för en Claude Code-version två släpp tillbaka. Vi noterar tiden från klon till fungerande skill, och om vi behövde lämna README:n för att komma dit.

Steg 2: triggerbatteriet

En installerad skill som aldrig aktiveras är dekoration. Så innan någon verklig uppgift kör vi ett batteri på fem prompter: tre formuleringar som borde trigga skillen, två som inte borde.

De tre positiva prompterna är avsiktligt varierade. För en Word-dokumentskill: "gör de här anteckningarna till en rapport jag kan skicka som en .docx," sedan "utkasta det här avtalet som en Word-fil," sedan något oblikt som "jag behöver det här formaterat ordentligt för juridisk granskning." Den första är README:ns eget exempel. Den andra använder annat ordval för samma avsikt. Den tredje nämner aldrig filformatet, vilket testar om beskrivningen täcker jobbet snarare än nyckelorden.

De två negativa prompterna undersöker övertriggering, felläget ingen pratar om. En dokumentskill som triggas när du frågar "sammanfatta det här dokumentet" (inklistrad text, ingen fil inblandad) injicerar instruktioner i konversationer där de inte hör hemma, och du betalar för det i kontext och i konstiga resultat. En skill som triggas på allt är värre än en som triggas på inget; åtminstone är den döda lätt att diagnostisera.

Fem av fem är ett rent resultat. Under det noterar vi vilka formuleringar som misslyckades; mönstret är oftast diagnostiskt. En skill som bara triggas på README:ns exakta ordval har en beskrivning skriven som en slogan istället för en triggerspecifikation.

Steg 3: baslinjekörningen

Det här är testets hjärta och anledningen till att protokollet existerar. Vi tar en verklig uppgift från skillens domän och kör den två gånger: en gång med skillen installerad, en gång på den nakna modellen med identisk prompt. Sedan jämför vi.

Jämförelsen är den enda frågan som spelar roll: är resultatet med skillen tydligt bättre än vad Claude producerar ändå? Claude är redan bra på mycket. En "skrivförbättrings"-skill som tävlar mot en modell som redan skriver bra måste visa en skillnad, och de flesta kan inte. När vi testade frontend-design körde vi samma landningssidesbrief båda sätten. Med-skill-versionen hade en verklig typskala och en avsiktlig palett; baslinjen hade neon-gradient-looken alla känner igen. Den skillnaden gav en 10:a. När de två resultaten är svåra att skilja åt har skillen ingen anledning att existera, hur trevlig dess README än är.

Verkliga indata spelar lika stor roll som jämförelsen. Ett kalkylblad med felaktiga rubriker, en fakturamapp där en tredjedel av filerna är skanningar. Prestanda på demodata är marknadsföring; vi testar tisdagseftermiddags-versionen av jobbet, för det är versionen du kommer ge den.

Steg 4: dokumentationskontrollen

Sist läser vi hela SKILL.md och allt den refererar, sedan jämför vi påståendena mot vad vi observerat. Lovar README:n förmågor skillen inte har? Avslöjar den sina beroenden? Finns det något begravt mitt i filen som ser mindre ut som uppgiftsvägledning och mer ut som prompt-injektion, eller ett nätverksanrop dokumentationen aldrig nämner?

Det här steget flaggar kanske en skill av tio, men de det fångar spelar störst roll. En skill är text injicerad i din modells kontext. Att läsa varje rad innan du litar på den är minimum, och vi behandlar den läsningen som en del av produkten.

De fyra poängen, och varför output räknas dubbelt

Varje testad skill får fyra siffror, beskrivna på vår metodiksida. Kortversionen, med vad som skiljer en 5:a från en 2:a:

Installerar rent (av 5). En 5:a betyder att en nykomling som följer README:n får en fungerande skill på en ren installation utan omvägar. En 2:a betyder att vi till slut fick den att fungera genom kunskap README:n inte innehåller: fixa sökvägar, läsa källkoden. Skillen kan vara utmärkt; dörren till den är trasig.

Triggar pålitligt (av 5). En 5:a är fem av fem på batteriet: alla tre positiva formuleringar triggar, båda negativa förblir tysta. En 2:a triggar bara på ordval hämtat från sin egen README, eller triggar på orelaterat arbete, eller båda. Vanlig orsak i endera riktningen: ett beskrivningsfält skrivet för att imponera på människor istället för att informera modellen.

Resultat mot baslinje (av 10). En 9:a eller 10:a betyder att resultatet med skillen är omisskännligt bättre på en verklig uppgift, den sortens skillnad du skulle märka utan ett poängkort. En 4:a betyder att vi fick anstränga oss för att se skillnaden. En 2:a betyder att baslinjekörningen var lika bra eller bättre, vilket händer oftare än författare skulle vilja tro.

Dokumentation och ärlighet (av 5). En 5:a betyder att README:n matchar verkligheten: korrekta påståenden, deklarerade beroenden, inget odolt. En 2:a betyder löften skillen inte kan hålla eller beteende dokumentationen aldrig nämner.

Resultat betygsätts av 10 medan allt annat är av 5, och den viktningen är avsiktlig: outputkvalitet är värd lika mycket som de andra kriterierna tillsammans. Installationsproblem har lösningar. Triggerproblem kan lagas genom att redigera ett beskrivningsfält. Men en skill vars output inte slår baslinjen är olagbar på något sätt som spelar roll. De andra poängen mäter om du kan nå värdet. Outputpoängen mäter om det finns något värde alls.

Två tester från loggen: en 24:a och en 17:a

Siffror betyder mer med testerna bifogade. Här är en från varje ände av det publicerade spannet.

Systematic-debugging, från Jesse Vincents Superpowers-samling, fick 24 av 25: installation 5, trigger 5, output 9, dokumentation 5. Installationen är två plugin-kommandon som fungerade exakt som skrivet, och triggerbatteriet gick fem av fem. Baslinjekörningen är delen vi fortfarande tar upp i samtal: vi gav den en race condition som baslinje-Claude redan "fixat" tre gånger, varje fix en gissning som flyttade symptomet runt. Med skillen laddad slutade Claude gissa. Den formade en hypotes, skrev ett test för att kontrollera den, såg testet misslyckas, och gick den slingan tills den hittade den verkliga grundorsaken. Dokumentationen lovar en disciplinerad felsökningsprocess och det är precis vad vi såg hända. Den har varit ett fast inslag på vår kodningssida sedan dess.

Proposal-builder, en community-skill, fick 17: installation 3, trigger 4, output 7, dokumentation 3. Den första körningen var ett misslyckande i ordets rätta bemärkelse. Direkt ur lådan, på en ren profil, kunde den inte leverera vad dess README lovar: den polerade .docx-outputen beror tyst på att docx-skillen finns installerad, och den varumärkta formateringen beror på en förslagsmall README:n knappt nämner. Följ instruktionerna bokstavligt, som en ny användare skulle, och du får en vägg av markdown där ett förslag borde vara. När vi väl installerat kompanjonskillen och satt upp en mall satte den ihop ett genuint användbart varumärkt förslag från samtalsanteckningar och prissättning. Förmågan är verklig. Vägen till den finns inte i README:n, och poängen säger precis det, ner till de saknade stegen som beskrivs i testanteckningarna.

Det gapet är det stjärnantalet inte kan se. Båda reporna ser kompetenta ut utifrån. En fungerar i det ögonblick du följer dess egna instruktioner. Den andra fungerar bara om du redan vet vad den glömde berätta.

Vad en dom betyder

Poängen rullas upp till en av tre domar. Den mellersta förvirrar folk, så låt oss vara precisa.

Godkänd betyder att skillen installerades från författarens egna instruktioner, triggade korrekt, och slog baslinjen utan skill på en verklig uppgift. Av de 73 skills i katalogen bär 35 den här domen.

Fungerar med setup betyder att skillen levererar verkligt värde, men inte direkt ur lådan. Den behöver en kompanjonskill eller ett konfigurationssteg först, och listningen säger vilket. Tio skills sitter här, och domen är inte en eufemism för misslyckande. Vissa skills kräver setup av design: en varumärkesriktlinjeskill är tänkt att vara oanvändbar tills du fyller i din palett och röst, och en pipeline-granskningsskill kan inte granska en pipeline den inte kan se. Domen finns så du vet vad en ärlig halvtimme av konfiguration köper innan du spenderar den.

I testkö betyder att vi listade skillen för att den ser lovande ut och vi inte hunnit klart testa den. Ingen dom antyds i någondera riktningen; 28 skills väntar. Skills som misslyckas testningen helt får inte heller en tyst radering: testanteckningarna säger vad vi körde och vad som gick sönder, för ett dokumenterat misslyckande är mer användbart för dig än ett hål i katalogen.

Omtestning, för Claude fortsätter förändras

En dom är en ögonblicksbild, och marken under den rör sig. Skills sitter ovanpå en modell, och modeller uppdateras. En beskrivning som triggade pålitligt i en Claude Code-release kan börja misslyckas i nästa, för triggering beror på hur modellen läser beskrivningar, och den läsningen skiftar. Glidning är inte hypotetisk; vi har sett en pålitlig skill börja ignorera en av sina tre positiva formuleringar efter en release, utan att en enda bokstav i skillen ändrats.

Så varje listning bär ett testdatum och Claude Code-versionen, och stora releaser sätter hela godkänd-listan tillbaka i omtestningskön, mest installerade skills först. När en dom ändras, ändras listningen. Ett åldrande testdatum är din signal att väga domen därefter; det är den ärliga kostnaden av att testa mot en plattform i rörelse.

Vad vi inte testar, och var metoden är svag

Ett protokoll du inte kan kritisera är ett protokoll ingen beskrivit ärligt. De kända gränserna:

Exempeluppgifter kan inte täcka varje användning. Vi kör en eller två verkliga uppgifter per skill, valda för att vara representativa, och en skill som lyser på vårt kalkylblad med 40 000 rader kan ändå snubbla på ditt med 400 000 rader. Domen är bevis, aldrig en garanti.

Dokumentationspoängen lutar sig mot en testares omdöme. Att läsa en SKILL.md för ärlighet ligger närmare redigering än mätning, och två noggranna läsare kan väga samma vaga mening olika. Vi publicerar testanteckningar delvis så du kan granska oss.

Vi testar inte i skala eller över långa tidshorisonter. En ren maskin, dagar snarare än månader. Långsam degradering och arbetsflöden som involverar flera skills samtidigt ligger utanför metodens räckvidd för nu.

Säkerhetsgranskning är en läsning, inte en revision. Vi kontrollerar odeklarerade nätverksanrop och injektionsformade instruktioner, men en beslutsam illvillig aktör skulle kunna komma förbi en manuell läsning. Behandla vår dokumentationspoäng som ett filter, och håll garden uppe för allt som rör inloggningsuppgifter.

Och själva baslinjen rör sig. "Slår naken Claude" betyder naken Claude på testdatumet; när basmodellen förbättras kommer vissa godkända skills se sin skillnad krympa mot noll. En anledning till att omtestning inte är valfritt.

Att köra protokollet på din egen skill

Om du är på väg att publicera en skill tar en förkortad version av det här ungefär en timme och sätter dig före hälften av ekosystemet.

1. Ren profil. Tom skills-mapp, standardinställningar. Din dagliga maskin döljer dina buggar.
2. Installera bara från din README. Bättre: ge README:n till någon som aldrig sett repot och titta. Varje fråga de ställer är en saknad mening.
3. Kör femprompt-batteriet. Tre formuleringar som borde trigga, inklusive en som aldrig använder dina nyckelord, plus två närliggande prompter som inte borde. Fixa missar genom att skriva om beskrivningsfältet, inte genom att lägga till README-förbehåll.
4. Gör baslinjejämförelsen. Samma uppgift, med och utan din skill. Om du inte kan skilja resultaten åt, tänk om vad skillen är till för innan du publicerar.
5. Läs om din SKILL.md som en skeptiker. Varje påstående du inte kan demonstrera, skär bort. Varje beroende, deklarera.
6. Linta formatet. Frontmatter-misstag är den mest förebyggbara felklassen vi ser, och en validator fångar dem på sekunder.

Vanliga frågor

Hur lång tid tar det att testa en Claude-skill?

Det förkortade självtestet tar ungefär en timme. Vårt fullständiga protokoll kör 45 minuter för en enkel dokumentskill och upp till en vecka för skills vars värde bara visar sig över tid, som veckovis-genomgång-skills. Triggerbatteriet tar minuter; baslinjejämförelsen är där timmarna går åt.

Kan jag testa en skill utan en andra maskin?

Ja. Du behöver en ren profil, inte ren hårdvara. Peka Claude Code mot en tom skills-mapp (eller flytta din åt sidan) och du får isoleringen som spelar roll: inga andra skills som tävlar om triggers, ingen som tyst täcker upp för den som testas.

Vad är den vanligaste anledningen till att skills misslyckas testningen?

Output som inte slår baslinjen, i ungefär 35 % av misslyckandena, med trasiga installationer tätt efter på 30 %. Installationsmisslyckandena svider mest för de är billigast att förebygga: författaren följde aldrig sin egen README på en maskin som inte var deras.

Hur får jag min skill testad och listad på SkillProof?

Skicka in den här med repo-länken. Den kommer in i upptäcktskön, triageras efter genomslag och kategoripassform, och går sedan genom protokollet på den här sidan. Kör självtestet först så går dina odds för en godkänd dom upp, för du fångar samma defekter vi skulle göra.

Protokollet är inte smart. Det är en ren maskin, en README tagen på orden, fem prompter, en ärlig jämförelse. Det som får det att fungera är att ingen annan i pipelinen gör ens det: författare testar på sina egna maskiner, och stjärnor mäter entusiasm. Gapet mellan de två är där den där döda produktivitetsskillen från sent 2025 levde. Vi fortsätter stänga det, en installation i taget.