Slik tester vi Claude skills: SkillProof-protokollen

Hele nettstedet startet med en skill som ikke gjorde noen ting. Sent i 2025 gikk en produktivitetsskill sin seiersgang på X med noen tusen stjerner i ryggen. Vi installerte den, restartet Claude Code, skrev inn akkurat bruksområdet fra README-en, og så Claude svare som om skillen ikke eksisterte. Sjekket mappen: filene var på plass, frontmatter var gyldig. Skrev inn en annen formulering. Ingenting. Skillen utløste seg ikke én eneste gang på førti minutter, og ingenting på repo-siden ville forutsagt det. Stjerner måler om en README er spennende. De sier ingenting om hvorvidt mappen under den faktisk fungerer.

Den kvelden etterlot et spørsmål vi ikke fikk ut av hodet: hvis en skill med så mye oppmerksomhet kunne være dødfødt, hvordan ser resten av økosystemet ut? Så vi begynte å installere skills på en ren maskin og skrive ned hva som skjedde. Svaret, dokumentert i feildataene våre, er at rundt halvparten av community-skillsene feiler før de hjelper noen som helst. Dette innlegget er den andre siden av det funnet: den eksakte protokollen bak hver eneste dom på SkillProof, detaljert nok til at du kan kjøre den på din egen skill før du slipper den løs.

Protokollen, steg for steg

En full test tar mellom 45 minutter og flere dager, avhengig av kategori. En dokumentskill beviser seg selv i én økt; en ukentlig-gjennomgang-skill må overleve en hel faktisk uke. Uansett er stegene de samme, og rekkefølgen betyr noe, fordi hvert steg låser opp det neste. Det er ingen vits i å poengsette output på en skill som aldri utløses.

Steg 0: et rent miljø

Hver test starter på en maskinprofil med en tom skills-mappe og standard Claude Code-innstillinger. Dette høres ut som ren formalitet helt til første gang det redder deg. Skills påvirker hverandre: én kan se ut til å fungere fordi en annen skill på maskinen stille gjør tungløftet. Vi lærte dette da vi testet en tilbudsskill på en maskin som allerede hadde docx-skillen installert. Outputen så flott ut. På en ren profil forsvant halvparten av verdien, fordi dokumentskillen hadde produsert den polerte .docx-filen hele tiden.

Steg 1: installer fra forfatterens egne instruksjoner

Vi åpner repoets README og følger den bokstavelig. Ikke "vi finner ut hvordan vi installerer den." Vi gjør akkurat det forfatteren skrev, skrivefeil og alt, fordi det er det enhver ekte bruker vil gjøre. Hvis kommandoene faktisk produserer ~/.claude/skills/name/name/SKILL.md, én mappe for dypt, er det en mislykket installasjon, selv om hvem som helst som kjenner formatet kunne fikset det på ti sekunder. Vi kunne fikset det også. Poenget er at nykommeren som følger med klokken 23 ikke kan det, og de vil konkludere med at Claude skills er ødelagt i stedet for at én sti var feil.

Alt README-en ikke nevner, teller mot den: udeklarerte avhengigheter, instruksjoner skrevet for en Claude Code-versjon to utgivelser tilbake. Vi noterer tiden fra klone til fungerende skill, og om vi måtte forlate README-en for å komme dit.

Steg 2: triggerbatteriet

En installert skill som aldri aktiveres, er dekorasjon. Så før noen ekte oppgave kjører vi et fem-prompt-batteri: tre formuleringer som burde utløse skillen, to som ikke burde det.

De tre positive promptene er bevisst varierte. For en Word-dokumentskill: "gjør disse notatene om til en rapport jeg kan sende som en .docx," deretter "utkast denne kontrakten som en Word-fil," og så noe mer indirekte som "jeg trenger dette formatert riktig for juridisk gjennomgang." Den første er README-ens eget eksempel. Den andre bruker annet vokabular for samme intensjon. Den tredje nevner aldri filformatet, noe som tester om beskrivelsen dekker jobben snarere enn nøkkelordene.

De to negative promptene tester overtriggering, feilen ingen snakker om. En dokumentskill som utløses når du spør "oppsummer dette dokumentet" (limt inn tekst, ingen fil involvert) injiserer instruksjoner i samtaler der de ikke hører hjemme, og du betaler for det i kontekst og i rare outputer. En skill som utløses på alt, er verre enn én som aldri utløses; i det minste er den døde lett å diagnostisere.

Fem av fem er et rent resultat. Under det noterer vi hvilke formuleringer som feilet; mønsteret er som regel diagnostisk. En skill som bare utløses på README-ens eksakte ordlyd, har en beskrivelse skrevet som en slagord i stedet for en triggerspesifikasjon.

Steg 3: baseline-kjøringen

Dette er kjernen i testen og grunnen til at protokollen eksisterer. Vi tar en ekte oppgave fra skillens domene og kjører den to ganger: én gang med skillen installert, én gang på den nakne modellen med identisk prompt. Så sammenligner vi.

Sammenligningen er det eneste spørsmålet som betyr noe: er output-med-skill klart bedre enn det Claude produserer likevel? Claude er allerede god på mye. En "skrive bedre"-skill som konkurrerer mot en modell som allerede skriver godt, må vise en reell forskjell, og de fleste klarer ikke det. Da vi testet frontend-design, kjørte vi samme landingsside-brief begge veier. Versjonen med skill hadde en ekte typeskala og en bevisst fargepalett; baseline hadde det neon-gradient-utseendet alle kjenner igjen. Den forskjellen fortjente en 10. Når de to outputene er vanskelige å skille fra hverandre, har skillen ingen grunn til å eksistere, uansett hvor hyggelig README-en er.

Ekte input betyr like mye som sammenligningen. Et regneark med feilformaterte overskrifter, en fakturamappe der en tredjedel av filene er skann. Demo-data-ytelse er markedsføring; vi tester tirsdag-ettermiddag-versjonen av jobben, fordi det er versjonen du faktisk kommer til å gi den.

Steg 4: dokumentasjonssjekken

Til slutt leser vi hele SKILL.md og alt den refererer til, og sammenligner påstandene med det vi observerte. Lover README-en funksjoner skillen ikke har? Oppgir den avhengighetene sine? Er det noe begravet midt i filen som ser mindre ut som oppgaveveiledning og mer ut som prompt-injeksjon, eller et nettverkskall dokumentasjonen aldri nevner?

Dette steget flagger kanskje én skill av ti, men de det fanger, betyr mest. En skill er tekst injisert i modellens kontekst. Å lese hver linje før du stoler på den, er minimum, og vi behandler den lesningen som en del av produktet.

De fire poengsummene, og hvorfor output teller dobbelt

Hver testede skill får fire tall, beskrevet på metodesiden vår. Kortversjonen, med det som skiller en 5 fra en 2:

Installerer rent (av 5). En 5 betyr at en nykommer som følger README-en, får en fungerende skill på et ferskt oppsett uten omveier. En 2 betyr at vi til slutt fikk den til å fungere gjennom kunnskap README-en ikke inneholder: fikse stier, lese kildekoden. Skillen kan være utmerket; døren inn til den er ødelagt.

Utløses pålitelig (av 5). En 5 er fem av fem på batteriet: alle tre positive formuleringer utløser, begge negative forblir stille. En 2 utløses bare på ordlyd hentet rett fra sin egen README, eller utløses på urelatert arbeid, eller begge deler. Vanlig årsak i begge retninger: et beskrivelsesfelt skrevet for å imponere mennesker i stedet for å informere modellen.

Output vs. baseline (av 10). En 9 eller 10 betyr at resultatet med skill er utvilsomt bedre på en ekte oppgave, den typen forskjell du ville lagt merke til uten en poengtavle. En 4 betyr at vi måtte anstrenge oss for å se forskjell. En 2 betyr at baseline-kjøringen var like god eller bedre, noe som skjer oftere enn forfattere skulle ønske.

Dokumentasjon og ærlighet (av 5). En 5 betyr at README-en stemmer med virkeligheten: nøyaktige påstander, deklarerte avhengigheter, ingenting udisclosed. En 2 betyr løfter skillen ikke kan holde, eller atferd dokumentasjonen aldri nevner.

Output poengsettes av 10 mens alt annet er av 5, og den vektingen er bevisst: outputkvalitet er verdt like mye som de andre kriteriene til sammen. Installasjonsproblemer har løsninger. Triggerproblemer kan fikses ved å redigere ett beskrivelsesfelt. Men en skill hvis output ikke slår baseline, er ikke reparerbar på noen måte som betyr noe. De andre poengsummene måler om du kan nå verdien. Outputpoengsummen måler om det finnes noen verdi i det hele tatt.

To tester fra loggen: en 24 og en 17

Tall betyr mer med testene vedlagt. Her er én fra hver ende av det publiserte spekteret.

Systematic-debugging, fra Jesse Vincents Superpowers-samling, scoret 24 av 25: installasjon 5, trigger 5, output 9, dokumentasjon 5. Installasjonen er to plugin-kommandoer som fungerte akkurat som skrevet, og triggerbatteriet gikk fem av fem. Baseline-kjøringen er delen vi fortsatt trekker fram i samtaler: vi ga den en race condition som baseline-Claude allerede hadde "fikset" tre ganger, hver fiks et gjetteforsøk som flyttet symptomet rundt. Med skillen lastet, sluttet Claude å gjette. Den formet en hypotese, skrev en test for å sjekke den, så testen feile, og gikk den løkken helt til den fant den faktiske rotårsaken. Dokumentasjonen lover en disiplinert feilsøkingsprosess, og det er nøyaktig det vi så skje. Den har vært en fast del av kode-siden vår siden.

Proposal-builder, en community-skill, scoret 17: installasjon 3, trigger 4, output 7, dokumentasjon 3. Den første kjøringen var en feil i ordets enkleste forstand. Rett ut av boksen, på en ren profil, klarte den ikke levere det README-en lover: den polerte .docx-outputen avhenger stilltiende av at docx-skillen er installert, og den merkevarebyggede formateringen avhenger av en tilbudsmal README-en knapt nevner. Følg instruksjonene bokstavelig, slik en ny bruker ville gjort, og du får en vegg av markdown der et tilbud burde vært. Etter at vi installerte tilleggsskillen og satte opp en mal, satte den sammen et genuint nyttig, merkevarebygget tilbud fra samtalenotater og prising. Kapasiteten er reell. Veien dit er ikke i README-en, og poengsummene sier akkurat det, ned til de manglende stegene som er spesifisert i testnotatene.

Det gapet er det stjernetallet ikke kan se. Begge repoene ser kompetente ut utenfra. Den ene fungerer i det øyeblikket du følger sine egne instruksjoner. Den andre fungerer bare hvis du allerede vet det den glemte å fortelle deg.

Hva en dom betyr

Poengsummene rulles opp i én av tre dommer. Den midterste forvirrer folk, så la oss være presise.

Bestått betyr at skillen installerte fra forfatterens egne instruksjoner, utløste korrekt, og slo no-skill-baseline på en ekte oppgave. Av de 73 skillene i katalogen, bærer 35 denne dommen.

Fungerer med oppsett betyr at skillen leverer reell verdi, men ikke rett ut av boksen. Den trenger en tilleggsskill eller et konfigurasjonssteg først, og oppføringen sier hvilket. Ti skills befinner seg her, og dommen er ikke en eufemisme for feil. Noen skills krever oppsett av design: en merkevareretningslinje-skill skal være ubrukelig helt til du fyller inn paletten og stemmen din, og en pipeline-gjennomgang-skill kan ikke gjennomgå en pipeline den ikke kan se. Dommen finnes slik at du vet hva en ærlig halvtime med konfigurasjon kjøper deg før du bruker den.

I testkø betyr at vi listet skillen fordi den ser lovende ut og ikke er ferdig testet ennå. Ingen dom er antydet i noen retning; 28 skills venter. Skills som feiler testing rett ut, blir heller ikke stille slettet: testnotatene sier hva vi kjørte og hva som gikk galt, fordi en dokumentert feil er mer nyttig for deg enn et hull i katalogen.

Retesting, fordi Claude fortsetter å endre seg

En dom er et øyeblikksbilde, og bakken under den beveger seg. Skills sitter oppå en modell, og modeller oppdateres. En beskrivelse som utløste pålitelig i én Claude Code-utgivelse, kan begynne å feiltrigge i den neste, fordi triggering avhenger av hvordan modellen leser beskrivelser, og den lesningen skifter. Drift er ikke hypotetisk; vi har sett en pålitelig skill begynne å ignorere én av sine tre positive formuleringer etter en utgivelse, uten at en eneste bokstav i skillen ble endret.

Så hver oppføring bærer en testet dato og Claude Code-versjonen, og større utgivelser setter hele bestått-listen tilbake i retest-køen, mest installerte skills først. Når en dom endres, endres oppføringen. En aldrende testet-dato er din pekepinn til å vurdere dommen deretter; det er den ærlige kostnaden ved å teste mot en plattform i bevegelse.

Hva vi ikke tester, og hvor metoden er svak

En protokoll du ikke kan kritisere, er en protokoll ingen har beskrevet ærlig. De kjente begrensningene:

Eksempeloppgaver kan ikke dekke enhver bruk. Vi kjører én eller to ekte oppgaver per skill, valgt for å være representative, og en skill som utmerker seg på vårt regneark med 40 000 rader, kan fortsatt snuble på ditt med 400 000 rader. Dommen er bevis, aldri en garanti.

Dokumentasjonspoengsummen lener seg på én testers vurdering. Å lese en SKILL.md for ærlighet ligger nærmere redigering enn måling, og to nøye lesere kan vekte den samme vage setningen forskjellig. Vi publiserer testnotater delvis slik at du kan revidere oss.

Vi tester ikke i skala eller over lange tidshorisonter. Én ren maskin, dager snarere enn måneder. Langsom degradering og arbeidsflyter som involverer flere skills samtidig, er utenfor metodens rekkevidde foreløpig.

Sikkerhetsgjennomgang er en lesning, ikke en revisjon. Vi sjekker etter udeklarerte nettverkskall og injeksjonsformede instruksjoner, men en bestemt ondsinnet aktør kunne fått noe forbi en manuell lesning. Behandle dokumentasjonspoengsummen vår som et filter, og hold vakten oppe for alt som rører ved legitimasjon.

Og selve baseline beveger seg. "Slår naken Claude" betyr naken Claude på testdatoen; etter hvert som grunnmodellen forbedres, vil noen bestått-skills se forskjellen sin krympe mot null. Enda en grunn til at retesting ikke er valgfritt.

Å kjøre protokollen på din egen skill

Hvis du er i ferd med å publisere en skill, tar en kondensert versjon av dette rundt en time og setter deg foran halve økosystemet.

1. Ren profil. Tom skills-mappe, standardinnstillinger. Din daglige maskin skjuler feilene dine.
2. Installer kun fra README-en din. Bedre: gi README-en til noen som aldri har sett repoet, og se på. Hvert spørsmål de stiller, er en manglende setning.
3. Kjør fem-prompt-batteriet. Tre formuleringer som burde utløse, inkludert én som aldri bruker nøkkelordene dine, pluss to nærliggende prompter som ikke burde det. Fiks bommer ved å omskrive beskrivelsesfeltet, ikke ved å legge til README-forbehold.
4. Gjør baseline-sammenligningen. Samme oppgave, med og uten skillen din. Hvis du ikke kan skille outputene fra hverandre, tenk gjennom hva skillen faktisk er til for før du publiserer.
5. Les SKILL.md-en din på nytt som en skeptiker. Hver påstand du ikke kan demonstrere, kutt. Hver avhengighet, deklarer.
6. Lint formatet. Frontmatter-feil er den mest forebyggbare feilklassen vi ser, og en validator fanger dem på sekunder.

FAQ

Hvor lang tid tar det å teste en Claude skill?

Den kondenserte selvtesten tar rundt en time. Vår fulle protokoll kjører 45 minutter for en enkel dokumentskill og opptil en uke for skills hvis verdi bare viser seg over tid, som ukentlig-gjennomgang-skills. Triggerbatteriet tar minutter; baseline-sammenligningen er der timene går.

Kan jeg teste en skill uten en ekstra maskin?

Ja. Du trenger en ren profil, ikke ren maskinvare. Pek Claude Code mot en tom skills-mappe (eller flytt din egen til side), så får du isolasjonen som betyr noe: ingen andre skills som konkurrerer om triggere, ingen som stille dekker for den som testes.

Hva er den vanligste grunnen til at skills feiler testing?

Output som ikke slår baseline, i rundt 35 % av feilene, med ødelagte installasjoner tett bak på 30 %. Installasjonsfeilene svir mest fordi de er billigst å forebygge: forfatteren fulgte aldri sin egen README på en maskin som ikke var deres egen.

Hvordan får jeg skillen min testet og listet på SkillProof?

Send den inn her med repo-lenken. Den går inn i oppdagelseskøen, blir triagert etter trekkraft og kategoripassform, og går deretter gjennom protokollen på denne siden. Kjør selvtesten først, så øker sjansene dine for en bestått-dom, fordi du fanger de samme feilene vi ville gjort.

Protokollen er ikke smart. Den er en ren maskin, en README tatt på ordet, fem prompter, én ærlig sammenligning. Det som får den til å fungere, er at ingen andre i pipelinen gjør engang så mye: forfattere tester på sine egne maskiner, og stjerner måler begeistring. Gapet mellom de to er der den dødfødte produktivitetsskillen fra sent 2025 levde. Vi fortsetter å lukke det, én installasjon om gangen.