Sådan opretter du en Claude skill: skriv SKILL.md på 10 min

Vi tester Claude skills til daglig, hundredvis indtil videre, og mønstret er deprimerende: de fleste skills, der fejler vores review, fejlede ikke, fordi forfatteren ikke kunne skrive instruktioner. De fejlede, fordi skillen aldrig loadede, eller loadede, når den ikke skulle, eller var tre skills i en trenchcoat. Alt sammen rettbart ved forfattertidspunktet, intet rettbart bagefter ved at skrive en pænere README.

Dette er tutorialen, vi ønsker, at hver indsender havde læst først. Ved slutningen har du en fungerende skill: en code review-tjekliste, der skubber Claude forbi "ser godt ud, måske omdøb denne variabel" til at tjekke grænsebetingelser, fejlveje og død kode. Det er et rigtigt eksempel med vilje. Den bedste community-skill i vores kodekategori, Code Review Checklist, gør præcis dette og scorer 8/10 på output. Din vil ikke slå den på dag ét, men du vil forstå hver beslutning, den skills forfatter traf.

10-minutters-løftet er ærligt med ét forbehold. At skrive den første fungerende version tager omkring 10 minutter. At teste den ordentligt tager yderligere 30. Spring det andet trin over, og du slutter dig til halvdelen af udgivne skills, der ikke overlever mødet med en frisk session. Vi skrev obduktionen op i hvorfor halvdelen af Claude skills ikke virker, og vi vil helst ikke tilføje din til datasættet.

Har du aldrig installeret en skill og ved ikke, hvad en er, så læs hvad Claude skills er og hvordan du installerer dem først. Dette indlæg antager, du har brugt mindst én.

Trin 1: afgræns den til ét job

Før du skriver en linje, beslut hvad din skill gør. Skær det derefter i halvdelen.

Den enkeltstørste fejl, vi ser i testning, er skills, der forsøger at gøre alt. "Hjælper med kodekvalitet" lyder som en rimelig afgrænsning. Det er det ikke. En skill som den vil trigge på reviews, refaktoreringer, testskrivning, linting-spørgsmål og arkitekturdebatter, hvilket i praksis betyder, at Claude ikke kan afgøre, hvornår den skal loades, så den loader uforudsigeligt eller slet ikke. Triggerproblemer er den mest almindelige årsag til, at en skill scorer lavt i vores metodologi, foran dårlige instruktioner og ødelagte installationer. Ikke fordi triggering er den sværeste del af skill-forfatterskab, men fordi scope creep opstrøms gør det uløseligt nedstrøms.

Én skill, ét job. Her er testen: kan du afslutte sætningen "brug denne skill, når brugeren beder om ___" med én konkret verbumfrase? "Reviewe en pull request eller diff" består. "Forbedre deres kode" fejler. Har din sætning "og" eller "eller", der forbinder urelaterede aktiviteter, skriver du to skills. Skriv to skills. Mapper er gratis.

For vores eksempel er afgrænsningen: reviewe en diff eller PR for korrekthedsfejl, ved brug af en fast tjekliste, der undertrykker stilistiske bemærkninger. Ikke "hjælp med reviews." Ikke "reviewe og fikse." Reviewe, rapportere, stoppe.

Trin 2: SKILL.md-skabelonen

En skill er en mappe med én påkrævet fil. Vores går i ~/.claude/skills/ til personlig brug, eller .claude/skills/ inde i et repo, hvis hele teamet skal have den:

review-checklist/
  SKILL.md          ← påkrævet, og ofte alt du behøver
  reference/        ← valgfri, kun loadet når Claude vælger at læse den
  templates/        ← valgfri, filer dine instruktioner peger på

Her er den fulde SKILL.md, vi bygger, annoteret. Kopiér den, læs derefter annotationerne, for to af disse linjer betyder langt mere end resten:

---
# 'name' er en identifikator: små bogstaver, bindestreger, ingen mellemrum.
# Claude ser det, men det styrer IKKE triggering.
name: review-checklist

# 'description' er det ENESTE, Claude læser, når den afgør,
# om denne skill skal loades. Alt under frontmatter er
# usynligt indtil efter den beslutning. Skriv den som en
# triggerbetingelse, ikke marketingtekst.
description: Use when the user asks to review code, review a
  PR, review a diff, or check a branch before merging. Runs a
  correctness-focused review checklist. Do NOT use for writing
  new code, fixing bugs the user already identified, or
  general refactoring requests.
---

# Code review checklist

When reviewing a diff or PR, work through this checklist in
order. Report only findings; do not fix anything unless asked.

## Procedure

1. Read the full diff before commenting on any line.
2. For each changed function, check:
   - Off-by-one risks at loop bounds and slice indices
   - Null/undefined paths: what happens when inputs are empty?
   - Error handling: are failures swallowed or logged and re-raised?
3. Check for dead code the change creates: unused imports,
   unreachable branches, orphaned helpers.
4. Check concurrency only if the diff touches shared state.
5. Verify new logic has test coverage. Missing tests are a
   finding, not a blocker.

## Reporting rules

- Max 10 findings, ordered by severity. If you found 30,
  report the 10 worst.
- Every finding needs a file, a line reference, and a one-line
  fix suggestion.
- Do NOT report: naming preferences, formatting, comment
  style, or anything a linter would catch.
- If the diff is clean, say so in one sentence. Do not invent
  findings to seem thorough.

Det er hele skillen. Intet build-trin, intet manifest, ingen registrering. Genstart din Claude-session, og den er live.

Frontmatter har præcis to felter, der betyder noget. name er bogholderi. description afgør alt, og her er hvorfor: Claude beholder kun navn og beskrivelse for hver installeret skill i konteksten. Selve indholdet af din SKILL.md eksisterer ikke, hvad modellen angår, før den læser din beskrivelse, beslutter "dette matcher, hvad brugeren vil," og loader resten. En genial 200-linjers tjekliste bag en vag beskrivelse er en genial 200-linjers tjekliste, ingen nogensinde vil eksekvere. I vores scoringsrubrik vejes triggering lige så tungt som outputkvalitet af præcis denne grund. En skill, der fyrer 40% af tiden, er plat og krone med ekstra trin.

Trin 3: skriv triggerbeskrivelsen

Da beskrivelsen er en triggerbetingelse, så skriv den som én. Navngiv de formuleringer, en rigtig bruger ville skrive. Inkludér negativrummet, altså de nærliggende anmodninger, hvor skillen skal forblive stille.

Side om side, fra rigtige indsendelser vi har testet (let anonymiseret):

Dårlig:

description: A powerful skill that helps improve code quality
  and catch issues early in the development process.

God:

description: Use when the user asks to review code, review a
  PR, review a diff, or check a branch before merging. Do NOT
  use for writing new code or fixing already-identified bugs.

Den dårlige beskriver fordelen. Den gode beskriver øjeblikket. Claude læser ikke din beskrivelse for at blive overbevist; den mønstermatcher mod brugerens faktiske ord. "Review denne PR" deler nul ordforråd med "hjælper med kodekvalitet," så skillen sover gennem sit eget brugstilfælde. Vi testede en indsendelse næsten identisk med det dårlige eksempel: den fyrede på 1 af 8 review-lignende prompts. Efter omskrivning af beskrivelsen til at navngive formuleringer, samme indhold, fyrede den på 8 af 8.

Endnu et par, denne gang om negativrummet:

Dårlig:

description: Use for anything related to testing.

God:

description: Use when the user asks to write tests for
  existing code or asks what to test. Do NOT use when the
  user is doing TDD (writing tests before implementation) or
  debugging a failing test.

"Alt relateret til testning" er, hvordan du ender med at kapre en debugging-session. Overtriggering er stillere end undertriggering og lige så skadeligt: brugeren får tjekliste-smagende svar på spørgsmål, der krævede noget andet, bebrejder modellen, afinstallerer skillen.

Mekaniske regler, der holder på tværs af alt, vi har testet: navngiv tre til fem konkrete brugerformuleringer, inkludér mindst én "brug IKKE"-klausul, hold dig under omkring 500 tegn, og brug aldrig ordene "kraftfuld," "omfattende" eller "hjælper med." De ord korrelerer med fejlende triggerscorer i vores data så konsistent, at vi nu rykker sammen ved synet af dem.

Trin 4: skriv en krop, Claude faktisk følger

Når skillen først er loadet, er kroppen instruktionssættet. Fejltypen her er mere subtil end triggering, men lige så almindelig: instruktioner, der inspirerer i stedet for at begrænse. "Skriv en grundig, gennemtænkt review" er en motivationsplakat. Claude vil allerede være grundig og gennemtænkt; det er standardadfærden, du forsøger at forme, ikke formen.

Skillsene, der topper vores rangeringer, er lister af begrænsninger. Test-Driven Development forbyder implementering, før en fejlende test findes, punktum. Vores eksempel-skill sætter et loft på 10 fund og forbyder stilistiske bemærkninger helt. Læg mærke til, hvor mange af dens linjer der starter med "gør ikke." Det er bevidst. Modeller overgenererer som standard, så de mest værdifulde instruktioner er som regel subtraktive.

Tommelfingerregler for kroppen:

1. Nummererede procedurer slår prosa. "Arbejd gennem dette i rækkefølge" giver Claude en rygrad; afsnit giver den stemninger.
2. Angiv stopbetingelsen. Vores skill siger rapporter fund, fiks ikke. Uden den linje vil Claude hjælpsomt begynde at omskrive koden, hvilket ingen bad om.
3. Lovgiv om outputformatet. Maksimumtal, påkrævede felter, hvordan et rent resultat ser ud. "Hvis diffen er ren, sig det" forhindrer opdigtede fund, en fejl vi konstant fanger i review-type skills.
4. Læg sjældent nødvendige detaljer i reference/-filer. Har din skill en 300-linjers stilguide, der gælder én gang om måneden, så indsæt den ikke i SKILL.md, hvor den brænder kontekst ved hver aktivering. Gem den som reference/style-guide.md og skriv "når brugeren spørger om X, læs reference/style-guide.md først." Claude loader den on-demand.

Hvornår tilføjer du scripts og skabeloner? Kun når instruktioner ikke kan klare jobbet. En skill, der genererer en specifik konfigfil, bør levere en templates/config.yaml og sige "kopiér denne, modificér derefter." En skill, der har brug for deterministisk adfærd, for eksempel at parse et lockfile-format, bør levere et script og instruere Claude til at køre det i stedet for at genopfinde det fra hukommelsen hver gang. Men de fleste skills har brug for hverken. Vores eksempel har brug for hverken. Hver fil i mappen er noget, du nu vedligeholder, så optjen hver enkelt.

Trin 5: test den lokalt

Du er ikke færdig, når den virker én gang. "Den virkede, da jeg prøvede den" er teststandarden for hver ødelagt skill, vi nogensinde har fejlet. Her er minimumsbatteriet, og det matcher tæt, hvad vores metodologi kører på indsendelser:

1. Frisk session. Genstart Claude Code helt. Skills loader ved sessionsstart; at teste i den session, hvor du skrev den, beviser intet.
2. Triggertest, positiv. Prøv tre forskellige formuleringer, en rigtig bruger ville skrive: "review denne PR," "kan du tjekke denne diff, før jeg merger," "kig over mine ændringer." Alle tre bør aktivere skillen. Du kan se, den fyrede, fordi outputtet følger dine regler (en loftbelagt, sværhedsgrad-sorteret fundliste ligner intet som en standardreview). Er du usikker, spørg Claude direkte, om den brugte skillen.
3. Triggertest, negativ. Prøv tre nærliggende anmodninger, der IKKE bør fyre den: "fix denne bug," "skriv en funktion, der parser datoer," "hvorfor fejler denne test?" Dukker din review-tjekliste op i en debugging-session, har din beskrivelse brug for en "brug IKKE"-klausul.
4. Baseline-sammenligning. Kør den samme review-prompt i en session med skillen og én uden. Kan du ikke skelne outputtene fra hinanden, optjener skillen ikke sin kontekst, og du bør skærpe begrænsningerne. Dette er vores yndlingstest, fordi den er brutal. Omkring en tredjedel af de skills, vi reviewer, fejler den.
5. Ren-installations-test. Planlægger du at udgive: kopiér mappen til en anden maskine (eller slet og re-klon), følg din egen README ordret, og se om den virker. Manglende afhængighedsnotater dør her.

Hele batteriet tager 30 minutter. Det filtrerer omkring 80% af de fejl, vi ser, fra, hvilket er et stærkt afkast for en halv time.

Trin 6: kør den gennem validatoren

Før du udgiver, indsæt din SKILL.md i vores gratis skill-validator. Den scorer mod samme rubrik, vi bruger i reviews: beskrivelseslængde og specificitet, tilstedeværelse af konkrete triggerformuleringer, negativrums-klausuler, begrænsningstæthed i kroppen, formatlovgivning, åbenlyse antimønstre som "kraftfuld" og "alt relateret til."

Det er statisk analyse, så behandl det derefter. Den fanger fejlene, der er synlige i teksten, hvilket efter vores erfaring er de fleste af dem, men den kan ikke køre din skill mod live prompts. En validator-godkendelse plus trin 5-batteriet er den reelle bar. En validator-godkendelse alene er en lintet skill, der stadig måske ikke fyrer.

Foretrækker du interaktiv hjælp frem for en tjekker, er Anthropics Skill Creator værktøjet, vi anbefaler. Den scorede 9,6 i vores testning, skaffolder mappen, og dens beskrivelses-optimeringstrin målbart forbedrede triggeringen på vores egne interne skills. At bruge en skill til at skrive skills lyder som en joke og virker alligevel.

Trin 7: udgiv og indsend

Udgivelse er et normalt GitHub-repo. Mappekonvention:

your-repo/
  README.md           ← hvad den gør, installationskommando, ét eksempel
  review-checklist/
    SKILL.md
    reference/

Sæt installationskommandoen i README'en som en kopiér-indsæt-blok, standardmønstret er git clone plus cp -r review-checklist ~/.claude/skills/. Tilføj derefter claude-skills-emnetagget til repoet. Det her er ikke dekoration: emnetagget er, hvordan vores crawler og alle andre kataloger opdager nye skills. Et utagget skill-repo er usynligt i praksis.

En README, det er værd at skrive, har fire ting: én sætning om hvad skillen gør, installationsblokken, ét før/efter-eksempel, og eventuelle afhængigheder. Før/efter-eksemplet gør mere for adoption end alt andet tilsammen, fordi det er den eneste del, der viser i stedet for at hævde.

Indsend den derefter til SkillProof. Testning og listning er gratis. Vi kører indsendelsen gennem samme proces som alt andet i kataloget: frisk installation fra din README, triggerbatteri, baseline-sammenligning, outputscoring. Består den, bliver den listet med en score, og du kan indlejre et "SkillProof tested"-badge i din README. For en ukendt forfatter med et to dage gammelt repo er en uafhængig testdom forskellen mellem "tilfældig SKILL.md fra internettet" og noget en fremmed rent faktisk vil installere. Består den ikke, får du fejlnotaterne, fikser det, og indsender igen. Adskillige listede skills gik gennem to runder.

Almindelige fejl, vi ser i indsendelser

Efter et par hundrede reviews dukker de samme fem konsekvent op.

Vage beskrivelser. Stadig førstepladsen med stor margin. Kan din beskrivelse beskrive tre andre skills, beskriver den ingen af dem.

Køkkenvask-skillen. Én SKILL.md, der håndterer reviews, commits, refaktoreringer og dokumentation. Hvert job udvander triggeren for de andre. Del den op.

Genfortæller modellens standarder. En krop, der siger "vær klar, vær præcis, tænk trin for trin," tilføjer intet. Claude gør det alligevel. Vil sletning af en linje ikke ændre outputtet, så slet linjen.

Ingen negative begrænsninger. Skills, der kun siger, hvad de skal gøre, aldrig hvad de skal stoppe med at gøre. "Gør ikke"-linjerne er, hvor det meste af adfærdsændringen bor.

Utestede installationsinstruktioner. README'en siger kopiér én mappe; skillen afhænger stiltiende af en anden skill eller en Python-pakke. Dør på vores ren-installations-trin hver gang, og det er den mest undgåelige fejl på denne liste.

Ofte stillede spørgsmål

Skal jeg kunne kode for at oprette en Claude skill? Nej. En SKILL.md er markdown med en YAML-header. Leverer din skill hjælpescripts, skal du skrive dem, men instruktions-only skills, hvilket er de fleste, er ren skrivning. Skillen i dette indlæg indeholder nul kode.

Hvor lang skal en SKILL.md være? Så kort som muligt, mens den stadig begrænser adfærd, typisk 30 til 150 linjer. Under omkring 20 linjer tilføjer den normalt intet ud over standarder; over et par hundrede bør du flytte detaljer til reference/-filer. Længde er en omkostning, du betaler pr. aktivering, ikke et kvalitetssignal.

Hvorfor trigger min skill ikke? Beskrivelsen, næsten altid. Tjek at den navngiver formuleringer, en bruger faktisk ville skrive, frem for at beskrive fordele, og bekræft, du genstartede sessionen efter installation, da skills loader ved sessionsstart. Trigger den på nogle formuleringer og ikke andre, så tilføj de manglende til beskrivelsen eksplicit.

Hvad er forskellen på en skill og en MCP-server? En skill er instruktioner: markdown, der former hvordan Claude opfører sig, ingen kode kører nogen steder. En MCP-server er et program, der giver Claude nye evner, som at forespørge din database. Er din idé "Claude bør gribe X anderledes an," er det en skill. Er det "Claude har brug for adgang til Y," er det MCP. Længere version i Claude skills vs MCP.

Kan jeg tage betaling for en Claude skill? Der er ingen indbygget betalingsmekanisme; skills er filer, og det offentlige økosystem kører på åbne repos. Nogle forfattere sælger private skill-pakker til teams som konsulentleverancer, hvilket virker, fordi værdien er den indkodede ekspertise, ikke filen. Alt beregnet til det offentlige katalog bør være åbent licenseret, for ingen installerer en skill, de ikke kan læse.

Afgræns ét job, skriv triggeren som en regex i prosa, begræns i stedet for at inspirere, og test i en frisk session, før du fortæller nogen. Det er hele håndværket. Resten er iteration, og indsendelseskøen er åben.