Sådan tester vi Claude-skills: SkillProof-protokollen

Hele siden startede med en skill, der ikke gjorde noget. Sidst i 2025 gik en produktivitetsskill sin sejrsgang på X med et par tusind stjerner bag sig. Vi installerede den, genstartede Claude Code, skrev den præcise use case fra README'en, og så Claude svare, som om skillen ikke eksisterede. Tjekkede mappen: filer til stede, frontmatter gyldig. Skrev en anden formulering. Intet. Skillen trigget aldrig én gang på fyrre minutter, og intet på repo-siden ville have forudsagt det. Stjerner måler, om en README er spændende. De siger intet om, hvorvidt mappen under den virker.

Den aften efterlod et spørgsmål, vi ikke kunne ryste af os: hvis en skill med den opmærksomhed kan være dødfødt, hvordan ser resten af økosystemet så ud? Så vi begyndte at installere skills på en ren maskine og skrive ned, hvad der skete. Svaret, dokumenteret i vores fejldata, er, at omkring halvdelen af community-skills fejler, før de hjælper nogen. Dette indlæg er den anden side af det fund: den præcise protokol bag hver dom på SkillProof, i nok detalje til, at du kan køre den på din egen skill, før du udgiver den.

Protokollen, trin for trin

En fuld test tager mellem 45 minutter og flere dage, afhængigt af kategorien. En dokument-skill beviser sig selv i én siddeplads; en ugentlig-review-skill skal overleve en faktisk uge. Uanset hvad er trinene de samme, og rækkefølgen betyder noget, fordi hvert trin porter til det næste. Der er ingen pointe i at score output på en skill, der aldrig trigger.

Trin 0: et frisk miljø

Hver test starter på en maskinprofil med en tom skills-mappe og standard Claude Code-indstillinger. Det lyder som ceremoni, indtil den første gang det redder dig. Skills interagerer: én kan se ud til at virke, fordi en anden skill på maskinen stille løfter det tunge arbejde. Vi lærte dette ved at teste en proposal-skill på en maskine, der allerede havde docx-skillen installeret. Outputtet så fantastisk ud. På en ren profil forsvandt halvdelen af værdien, fordi dokument-skillen havde produceret den polerede .docx hele tiden.

Trin 1: installér fra forfatterens egne instruktioner

Vi åbner repoets README og følger den bogstaveligt. Ikke "vi finder ud af, hvordan man installerer den." Vi gør præcis, hvad forfatteren skrev, tastefejl og det hele, fordi det er, hvad hver rigtig bruger vil gøre. Hvis kommandoerne faktisk producerer ~/.claude/skills/name/name/SKILL.md, én mappe for dybt, er det en fejlet installation, selvom enhver, der kender formatet, kunne fikse det på ti sekunder. Vi kunne også fikse det. Pointen er, at nybegynderen, der følger med klokken 23, ikke kan, og de vil konkludere, at Claude-skills er ødelagte, frem for at én sti var forkert.

Alt README'en ikke nævner, tæller imod den: udeklarerede afhængigheder, instruktioner skrevet til en Claude Code-version to udgivelser tilbage. Vi noterer tiden fra klon til virkende skill, og om vi måtte forlade README'en for at nå dertil.

Trin 2: trigger-batteriet

En installeret skill, der aldrig aktiverer, er dekoration. Så før nogen reel opgave kører vi et fem-prompt-batteri: tre formuleringer, der bør trigge, og to, der ikke bør.

De tre positive prompter er bevidst varierede. For en Word-dokument-skill: "lav disse noter til en rapport, jeg kan sende som .docx," derefter "udkast denne kontrakt som en Word-fil," og noget mere indirekte som "jeg har brug for dette formateret ordentligt til juridisk gennemgang." Den første er README'ens eget eksempel. Den anden bruger andet ordforråd for samme hensigt. Den tredje nævner aldrig filformatet, hvilket tester, om beskrivelsen dækker jobbet frem for nøgleordene.

De to negative prompter afprøver overtriggering, fejltilstanden ingen taler om. En dokument-skill, der trigger, når du beder "opsummer dette dokument" (indsat tekst, ingen fil involveret), injicerer instruktioner ind i samtaler, hvor de ikke hører hjemme, og det betaler du for i kontekst og i mærkelige outputs. En skill, der trigger på alt, er værre end en, der trigger på intet; i det mindste er den døde nem at diagnosticere.

Fem for fem er et rent resultat. Under det noterer vi, hvilke formuleringer der fejlede; mønsteret er som regel diagnostisk. En skill, der kun trigger på README'ens eksakte ordlyd, har en beskrivelse skrevet som en tagline i stedet for en trigger-spec.

Trin 3: baseline-kørslen

Det er testens hjerte og grunden til, protokollen findes. Vi tager en reel opgave fra skillens domæne og kører den to gange: én gang med skillen installeret, én gang på den nøgne model med identisk prompt. Så sammenligner vi.

Sammenligningen er det eneste spørgsmål, der betyder noget: er output-med-skill klart bedre end, hvad Claude producerer alligevel? Claude er allerede god til meget. En "skriveforbedrings"-skill, der konkurrerer mod en model, der skriver godt, skal demonstrere en delta, og de fleste kan ikke. Da vi testede frontend-design, kørte vi samme landingsside-brief begge veje. Med-skill-versionen havde en reel typeskala og en bevidst palet; baseline havde det neon-gradient-look, alle genkender. Den delta tjente en 10. Når de to outputs er svære at skelne, har skillen ingen grund til at eksistere, uanset hvor behagelig dens README er.

Reelle input betyder lige så meget som sammenligningen. Et regneark med misdannede overskrifter, en fakturamappe hvor en tredjedel af filerne er scanninger. Demo-data-performance er markedsføring; vi tester tirsdag-eftermiddag-versionen af jobbet, fordi det er versionen, du vil give den.

Trin 4: dokumentationstjekket

Til sidst læser vi hele SKILL.md og alt, den refererer til, og sammenligner så påstandene med, hvad vi observerede. Lover README'en evner, skillen ikke har? Afslører den sine afhængigheder? Er der noget begravet midt i filen, der ligner mindre opgave-vejledning og mere prompt injection, eller et netværkskald, dokumentationen aldrig nævner?

Dette trin flager måske én skill ud af ti, men dem det fanger, betyder mest. En skill er tekst injiceret i din models kontekst. At læse hver linje, før du stoler på den, er minimum, og vi behandler den læsning som en del af produktet.

De fire scorer, og hvorfor output tæller dobbelt

Hver testet skill får fire tal, beskrevet på vores metodologiside. Kort version, med hvad der adskiller en 5 fra en 2:

Installerer rent (ud af 5). En 5 betyder, en nybegynder, der følger README'en, får en virkende skill på en frisk opsætning uden omveje. En 2 betyder, vi til sidst fik den til at virke gennem viden, README'en ikke indeholder: at fikse stier, læse kildekoden. Skillen kan være fremragende; døren til den er ødelagt.

Trigger pålideligt (ud af 5). En 5 er fem for fem på batteriet: alle tre positive formuleringer trigger, begge negative forbliver stille. En 2 trigger kun på ordlyd hentet fra sin egen README, eller trigger på urelateret arbejde, eller begge. Fælles årsag i begge retninger: et beskrivelsesfelt skrevet for at imponere mennesker frem for at informere modellen.

Output vs. baseline (ud af 10). En 9 eller 10 betyder, resultatet med skillen er utvetydigt bedre på en reel opgave, den slags forskel, du ville bemærke uden et scorekort. En 4 betyder, vi måtte anstrenge os for at se det. En 2 betyder, baseline-kørslen var lige så god eller bedre, hvilket sker oftere, end forfattere ville tro.

Dokumentation og ærlighed (ud af 5). En 5 betyder, README'en matcher virkeligheden: præcise påstande, deklarerede afhængigheder, intet uafsløret. En 2 betyder løfter, skillen ikke kan holde, eller adfærd, dokumentationen aldrig nævner.

Output scores ud af 10, mens alt andet er ud af 5, og den vægtning er bevidst: outputkvalitet er værd lige så meget som alt det andet tilsammen. Installationsproblemer har workarounds. Trigger-problemer kan lappes ved at redigere ét beskrivelsesfelt. Men en skill, hvis output ikke slår baseline, er uforbederlig på nogen måde, der betyder noget. De andre scorer måler, om du kan nå værdien. Outputscoren måler, om der overhovedet er nogen.

To tests fra loggen: en 24 og en 17

Tal betyder mere med testene vedhæftet. Her er én fra hver ende af det udgivne spektrum.

Systematic-debugging, fra Jesse Vincents Superpowers-samling, scorede 24 ud af 25: install 5, trigger 5, output 9, docs 5. Installationen er to plugin-kommandoer, der virkede præcis som skrevet, og trigger-batteriet gik fem for fem. Baseline-kørslen er den del, vi stadig bringer op i samtaler: vi gav den en race condition, baseline-Claude allerede havde "fikset" tre gange, hvert fix et gæt, der flyttede symptomet rundt. Med skillen loadet stoppede Claude med at gætte. Den formede en hypotese, skrev en test for at tjekke den, så testen fejle, og gik den løkke igennem, indtil den fandt den faktiske rodårsag. Dokumentationen lover en disciplineret debug-proces, og det er præcis, hvad vi så ske. Den har været et fast punkt på vores kodningsside lige siden.

Proposal-builder, en community-skill, scorede 17: install 3, trigger 4, output 7, docs 3. Den første kørsel var en fiasko i ordets egentlige forstand. Ud af boksen, på en ren profil, kunne den ikke levere, hvad dens README lover: den polerede .docx-output afhænger stille af at have docx-skillen installeret, og den brandede formatering afhænger af en proposal-skabelon, README'en knap nævner. Følg instruktionerne bogstaveligt, som en ny bruger ville, og du får en mur af markdown, hvor et proposal burde være. Da vi først havde installeret companion-skillen og sat en skabelon op, samlede den et genuint nyttigt brandet proposal fra opkaldsnoter og prissætning. Evnen er reel. Vejen dertil er ikke i README'en, og scorerne siger præcis det, ned til de manglende trin, der er stavet ud i testnoterne.

Det gab er det, stjerneantallet ikke kan se. Begge repos ser kompetente ud udefra. Den ene virker, i det øjeblik du følger sine egne instruktioner. Den anden virker kun, hvis du allerede ved, hvad den glemte at fortælle dig.

Hvad en dom betyder

Scorerne rulles op i én af tre domme. Den midterste forvirrer folk, så lad os være præcise.

Pass betyder, at skillen installerede fra forfatterens egne instruktioner, trigget korrekt, og slog no-skill-baseline på en reel opgave. Af de 73 skills i kataloget bærer 35 denne dom.

Virker med opsætning betyder, at skillen leverer reel værdi, men ikke ud af boksen. Den kræver en companion-skill eller et konfigurationstrin først, og listen siger hvilket. Ti skills sidder her, og dommen er ikke en eufemisme for fiasko. Nogle skills kræver opsætning per design: en brand-guidelines-skill skal per definition være ubrugelig, indtil du udfylder din palet og stemme, og en pipeline-review-skill kan ikke reviewe en pipeline, den ikke kan se. Dommen findes, så du ved, hvad en ærlig halv time konfiguration køber, før du bruger den.

I testkøen betyder, at vi listede skillen, fordi den ser lovende ud, og vi ikke er færdige med at teste den. Ingen dom er antydet i nogen retning; 28 skills venter. Skills, der fejler testning direkte, får heller ikke en stille sletning: testnoterne siger, hvad vi kørte, og hvad der gik i stykker, fordi en dokumenteret fiasko er mere nyttig for dig end et hul i kataloget.

Retest, fordi Claude bliver ved med at ændre sig

En dom er et øjebliksbillede, og jorden under den bevæger sig. Skills sidder oven på en model, og modeller bliver opdateret. En beskrivelse, der triggede pålideligt i én Claude Code-udgivelse, kan begynde at fejlfyre i den næste, fordi triggering afhænger af, hvordan modellen læser beskrivelser, og den læsning skifter. Drift er ikke hypotetisk; vi har set en pålidelig skill begynde at ignorere én af sine tre positive formuleringer efter en udgivelse, uden en eneste bogstav i skillen ændret.

Så hver listing bærer en testdato og Claude Code-versionen, og større udgivelser sætter hele pass-listen tilbage i retest-køen, mest installerede skills først. Når en dom ændrer sig, ændrer listen sig. En aldrende testdato er dit signal til at veje dommen derefter; det er den ærlige omkostning ved at teste mod en flyttende platform.

Hvad vi ikke tester, og hvor metoden er svag

En protokol, du ikke kan kritisere, er en protokol, ingen har beskrevet ærligt. De kendte grænser:

Eksempelopgaver kan ikke dække hver brug. Vi kører én eller to reelle opgaver per skill, valgt til at være repræsentative, og en skill, der skinner på vores 40.000-rækkers regneark, kan stadig snuble på dit 400.000-rækkers. Dommen er bevis, aldrig en garanti.

Dokumentationsscoren læner sig på én testers vurdering. At læse en SKILL.md for ærlighed er tættere på redigering end på måling, og to omhyggelige læsere kan veje samme vage sætning forskelligt. Vi udgiver testnoter delvist, så du kan auditere os.

Vi tester ikke i skala eller over lange horisonter. Én ren maskine, dage snarere end måneder. Langsom forringelse og workflows, der involverer flere skills på én gang, er uden for metodens rækkevidde for nu.

Sikkerhedsreview er en læsning, ikke en audit. Vi tjekker for uafslørede netværkskald og injektion-formede instruktioner, men en fast besluttet ond aktør kunne få noget forbi en manuel læsning. Behandl vores docs-score som et filter, og hold vagt oppe for alt, der rører legitimationsoplysninger.

Og selve baseline flytter sig. "Slår nøgen Claude" betyder nøgen Claude på testdatoen; efterhånden som grundmodellen forbedres, vil nogle bestående skills se deres delta krympe mod nul. Endnu en grund til, at retest ikke er valgfrit.

At køre protokollen på din egen skill

Er du ved at udgive en skill, tager en kondenseret version af dette omkring en time og sætter dig foran halvdelen af økosystemet.

1. Frisk profil. Tom skills-mappe, standardindstillinger. Din daglige maskine skjuler dine bugs.
2. Installér kun fra din README. Bedre: giv README'en til nogen, der aldrig har set repoet, og se på. Hvert spørgsmål de stiller, er en manglende sætning.
3. Kør fem-prompt-batteriet. Tre formuleringer, der bør trigge, inklusive én, der aldrig bruger dine nøgleord, plus to nærliggende prompter, der ikke bør. Ret misser ved at omskrive beskrivelsesfeltet, ikke ved at tilføje README-forbehold.
4. Lav baseline-sammenligningen. Samme opgave, med og uden din skill. Kan du ikke se forskel på outputtene, genovervej hvad skillen er til, før du udgiver.
5. Genlæs din SKILL.md som en skeptiker. Hver påstand, du ikke kan demonstrere, skær væk. Hver afhængighed, deklarér.
6. Lint formatet. Frontmatter-fejl er den mest forebyggelige fejlklasse, vi ser, og en validator fanger dem på sekunder.

Ofte stillede spørgsmål

Hvor lang tid tager det at teste en Claude-skill?

Den kondenserede selvtest tager omkring en time. Vores fulde protokol kører 45 minutter for en simpel dokument-skill og op til en uge for skills, hvis værdi først viser sig over tid, som ugentlige-review-skills. Trigger-batteriet tager minutter; baseline-sammenligningen er, hvor timerne går.

Kan jeg teste en skill uden en anden maskine?

Ja. Du har brug for en ren profil, ikke ren hardware. Peg Claude Code på en tom skills-mappe (eller flyt din til side), og du får den isolation, der betyder noget: ingen andre skills konkurrerer om triggere, ingen dækker stille for den, der testes.

Hvad er den mest almindelige grund til, at skills fejler testning?

Output, der ikke slår baseline, ved omkring 35% af fejlene, med ødelagte installationer tæt på med 30%. Installationsfejlene svier mest, fordi de er billigst at forebygge: forfatteren fulgte aldrig sin egen README på en maskine, der ikke var deres.

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

Indsend den her med repo-linket. Den kommer ind i opdagelseskøen, bliver triageret efter traction og kategori-fit, og går så gennem protokollen på denne side. Kør selvtesten først, og dine odds for en pass-dom stiger, fordi du fanger de samme defekter, vi ville.

Protokollen er ikke smart. Det er en ren maskine, en README taget på ordet, fem prompter, én ærlig sammenligning. Hvad der får den til at virke, er, at ingen andre i pipelinen gør bare det: forfattere tester på deres egne maskiner, og stjerner måler begejstring. Gabet mellem de to er, hvor den døde produktivitetsskill fra sidst i 2025 boede. Vi bliver ved med at lukke det, én installation ad gangen.