Skapa en Claude skill: skriv SKILL.md på 10 minuter

Vi testar Claude skills för vårt levebröd, hundratals hittills, och mönstret är nedslående: de flesta skills som misslyckas i vår granskning misslyckades inte för att författaren inte kunde skriva instruktioner. De misslyckades för att skillen aldrig laddades, eller laddades när den inte skulle, eller var tre skills i en trenchcoat. Allt går att åtgärda vid författandet, inget går att åtgärda i efterhand genom att skriva en snyggare README.

Det här är genomgången vi önskar att varje inskickare hade läst först. Vid slutet har du en fungerande skill: en checklista för kodgranskning som får Claude förbi "ser bra ut, döp kanske om den här variabeln" till att faktiskt kontrollera gränsvillkor, felvägar och död kod. Det är ett exempel valt med flit. Den bästa community-skillen i vår kodningskategori, Code Review Checklist, gör precis detta och får 8/10 på output. Din kommer inte slå den dag ett, men du kommer förstå varje beslut den skillens författare tog.

10-minutersluftet håller med en asterisk. Att skriva den första fungerande versionen tar cirka 10 minuter. Att testa den ordentligt tar ytterligare 30. Hoppar du över den andra delen ansluter du dig till hälften av alla publicerade skills som inte överlever mötet med en ny session. Vi skrev obduktionen i varför hälften av Claude skills inte fungerar, och vi hellre slipper lägga till din i datasetet.

Om du aldrig installerat en skill och inte vet vad en är, läs vad Claude skills är och hur du installerar dem först. Det här inlägget förutsätter att du använt minst en.

Steg 1: avgränsa till ett enda jobb

Innan du skriver en rad, bestäm vad din skill gör. Halvera det sedan.

Det enskilt största felet vi ser i testning är skills som försöker göra allt. "Hjälper med kodkvalitet" låter som en rimlig avgränsning. Det är det inte. En sådan skill vill trigga på granskningar, refaktorering, testskrivning, lint-frågor och arkitekturdebatter, vilket i praktiken betyder att Claude inte kan avgöra när den ska laddas, så den laddas oförutsägbart eller inte alls. Triggerproblem är den vanligaste anledningen till att en skill får låg poäng i vår metodik, före dåliga instruktioner och trasiga installationer. Inte för att triggning är den svåraste delen av skillskrivande, utan för att avgränsningsglidning uppströms gör det olösligt nedströms.

En skill, ett jobb. Här är testet: kan du avsluta meningen "använd denna skill när användaren ber om att ___" med en enda konkret verbfras? "Granska en pull request eller diff" godkänns. "Förbättra sin kod" underkänns. Om din mening har "och" eller "eller" som binder ihop orelaterade aktiviteter skriver du två skills. Skriv två skills. Mappar är gratis.

För vårt exempel är avgränsningen: granska en diff eller PR efter korrekthetsbuggar, med en fast checklista, som undertrycker stilanmärkningar. Inte "hjälp med granskningar". Inte "granska och fixa". Granska, rapportera, stanna.

Steg 2: SKILL.md-mallen

En skill är en mapp med en obligatorisk fil. Vår hamnar i ~/.claude/skills/ för personligt bruk, eller .claude/skills/ inuti ett repo om hela teamet ska få den:

review-checklist/
  SKILL.md          ← obligatorisk, och ofta allt du behöver
  reference/        ← valfritt, laddas bara när Claude bestämmer sig för att läsa det
  templates/        ← valfritt, filer dina instruktioner pekar på

Här är hela SKILL.md vi ska bygga, kommenterad. Kopiera den, läs sedan kommentarerna, för två av dessa rader är viktigare än resten tillsammans:

---
# 'name' är en identifierare: gemener, bindestreck, inga mellanslag.
# Claude ser den, men den styr INTE triggning.
name: review-checklist

# 'description' är det ENDA Claude läser när den avgör
# om skillen ska laddas. Allt under frontmatter är
# osynligt tills det beslutet är taget. Skriv den som
# ett triggervillkor, inte reklamtext.
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 var hela skillen. Inget byggsteg, ingen manifest, ingen registrering. Starta om din Claude-session och den är live.

Frontmatter har exakt två fält som spelar roll. name är bokföring. description avgör allt, och här är varför: Claude behåller bara namn och beskrivning för varje installerad skill i kontexten. Innehållet i din SKILL.md existerar inte såvitt modellen anbelangar förrän den läser din beskrivning, avgör "det här matchar vad användaren vill", och laddar resten. En briljant 200-radig checklista bakom en vag beskrivning är en briljant 200-radig checklista ingen någonsin kommer köra. I vår poängrubrik viktas triggning lika tungt som outputkvalitet av exakt denna anledning. En skill som aktiveras 40% av gångerna är ett myntkast med extra steg.

Steg 3: skriv triggerbeskrivningen

Eftersom beskrivningen är ett triggervillkor, skriv den som ett. Namnge formuleringarna en verklig användare skulle skriva. Inkludera det negativa utrymmet, det vill säga de närliggande förfrågningarna där skillen ska hålla tyst.

Sida vid sida, från riktiga inskickningar vi testat (lätt anonymiserade):

Dåligt:

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

Bra:

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åliga beskriver fördelen. Den bra beskriver ögonblicket. Claude läser inte din beskrivning för att övertygas; den mönstermatchar mot användarens faktiska ord. "Granska den här PR:en" delar noll ordförråd med "hjälper till att förbättra kodkvalitet", så skillen sover genom sitt eget användningsfall. Vi testade en inskickning nästan identisk med det dåliga exemplet: den aktiverades på 1 av 8 granskningsliknande promptar. Efter att ha skrivit om beskrivningen för att namnge formuleringar, med samma innehåll, aktiverades den på 8 av 8.

Ett till par, den här gången om det negativa utrymmet:

Dåligt:

description: Use for anything related to testing.

Bra:

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.

"Allt relaterat till testning" är hur du slutar kapa en felsökningssession. Överaktivering är tystare än underaktivering och lika skadligt: användaren får checklistesmakande svar på frågor som behövde något annat, skyller på modellen, avinstallerar skillen.

Mekaniska regler som håller genom allt vi testat: namnge tre till fem konkreta användarformuleringar, inkludera minst en "använd INTE"-klausul, håll dig under ungefär 500 tecken, och använd aldrig orden "kraftfull", "omfattande" eller "hjälper med". De orden korrelerar med underkända triggerpoäng i vår data så konsekvent att vi nu rycker till vid åsynen av dem.

Steg 4: skriv ett innehåll Claude faktiskt följer

När skillen väl laddats är innehållet instruktionsuppsättningen. Felmönstret här är mer subtilt än triggning men lika vanligt: instruktioner som inspirerar istället för att begränsa. "Skriv en grundlig, genomtänkt granskning" är en motivationsposter. Claude vill redan vara grundlig och genomtänkt; det är standardbeteendet du försöker forma, inte formen.

Skillsen som toppar våra rankningar är listor med begränsningar. Test-Driven Development förbjuder implementation innan ett misslyckat test existerar, punkt slut. Vårt exempel begränsar antalet fynd till 10 och förbjuder stilanmärkningar rakt av. Lägg märke till hur många av dess rader som börjar med "gör inte". Det är avsiktligt. Modeller övergenererar som standard, så de mest värdefulla instruktionerna är oftast subtraktiva.

Tumregler för innehållet:

1. Numrerade procedurer slår löpande text. "Arbeta igenom detta i ordning" ger Claude en ryggrad; stycken ger den känslor.
2. Ange stoppvillkoret. Vår skill säger rapportera fynd, fixa inte. Utan den raden kommer Claude hjälpsamt börja skriva om koden, vilket ingen bad om.
3. Lagstifta om outputformatet. Maxantal, obligatoriska fält, hur ett rent resultat ser ut. "Om diffen är ren, säg det" förhindrar uppfunna fynd, ett fel vi ständigt fångar i granskningstypskills.
4. Lägg sällan behövd detalj i reference/-filer. Om din skill har en 300-raders stilguide som tillämpas en gång i månaden, klistra inte in den i SKILL.md där den bränner kontext vid varje aktivering. Spara den som reference/style-guide.md och skriv "när användaren frågar om X, läs reference/style-guide.md först". Claude laddar den vid behov.

När lägger man till skript och mallar? Bara när instruktioner inte kan göra jobbet. En skill som genererar en specifik konfigurationsfil bör leverera en templates/config.yaml och säga "kopiera denna, modifiera sedan". En skill som behöver deterministiskt beteende, säg tolka ett lockfile-format, bör leverera ett skript och instruera Claude att köra det snarare än återskapa det ur minnet varje gång. Men de flesta skills behöver ingetdera. Vårt exempel behöver ingetdera. Varje fil i mappen är något du nu underhåller, så förtjäna varje fil.

Steg 5: testa den lokalt

Du är inte klar när det fungerar en gång. "Det fungerade när jag testade" är teststandarden för varenda trasig skill vi någonsin underkänt. Här är minimibatteriet, och det speglar nära vad vår metodik kör på inskickningar:

1. Ny session. Starta om Claude Code helt. Skills laddas vid sessionsstart; att testa i sessionen där du skrev den bevisar ingenting.
2. Triggertest, positivt. Prova tre olika formuleringar en verklig användare skulle skriva: "granska den här PR:en", "kan du kolla den här diffen innan jag mergar", "titta igenom mina ändringar". Alla tre borde aktivera skillen. Du kan se att den aktiverades genom att outputen följer dina regler (en begränsad, allvarlighetsordnad fyndlista ser inget alls ut som en standardgranskning). Är du osäker, fråga Claude direkt om den använde skillen.
3. Triggertest, negativt. Prova tre närliggande förfrågningar som INTE ska aktivera den: "fixa den här buggen", "skriv en funktion som tolkar datum", "varför failar det här testet?". Om din granskningschecklista dyker upp i en felsökningssession behöver din beskrivning en "använd INTE"-klausul.
4. Baseline-jämförelse. Kör samma granskningsprompt i en session med skillen och en utan. Om du inte kan skilja outputen åt förtjänar skillen inte sin kontext och du bör skärpa begränsningarna. Det här är vårt favorittest eftersom det är brutalt. Ungefär en tredjedel av skillsen vi granskar misslyckas med det.
5. Ren-installations-test. Om du planerar att publicera: kopiera mappen till en annan maskin (eller ta bort och klona på nytt), följ din egen README ordagrant, och se om det fungerar. Saknade beroendeanteckningar dör här.

Hela batteriet tar 30 minuter. Det filtrerar bort ungefär 80% av felen vi ser, vilket är en stark avkastning på en halvtimme.

Steg 6: kör den genom validatorn

Innan du publicerar, klistra in din SKILL.md i vår kostnadsfria skill-validator. Den poängsätter mot samma rubrik vi använder i granskningar: beskrivningens längd och specificitet, förekomst av konkreta triggerformuleringar, negativa-utrymme-klausuler, begränsningstäthet i innehållet, formatlagstiftning, uppenbara antimönster som "kraftfull" och "allt relaterat till".

Det är statisk analys, så behandla den därefter. Den fångar de fel som syns i texten, vilket enligt vår erfarenhet är de flesta, men den kan inte köra din skill mot levande promptar. Ett godkänt validatortest plus steg 5-batteriet är den riktiga ribban. Ett godkänt validatortest ensamt är en lintad skill som fortfarande kanske inte triggar.

Vill du ha interaktiv hjälp istället för en kontrollant är Anthropics Skill Creator verktyget vi rekommenderar. Den fick 9,6 i vår testning, bygger mappen åt dig, och dess beskrivningsoptimeringssteg förbättrade mätbart triggningen i våra egna interna skills. Att använda en skill för att skriva skills låter som ett skämt och fungerar ändå.

Steg 7: publicera och skicka in

Publicering är ett vanligt GitHub-repo. Layout-konvention:

your-repo/
  README.md           ← vad den gör, installationskommando, ett exempel
  review-checklist/
    SKILL.md
    reference/

Lägg installationskommandot i README som ett kopiera-klistra-block, standardmönstret är git clone plus cp -r review-checklist ~/.claude/skills/. Lägg sedan till taggen claude-skills på repot. Det här är inte dekoration: taggen är hur vår crawler och alla andra kataloger upptäcker nya skills. Ett otaggat skill-repo är i praktiken osynligt.

En README värd att skriva har fyra saker: en mening om vad skillen gör, installationsblocket, ett före/efter-exempel, och eventuella beroenden. Före/efter-exemplet gör mer för adoption än allt annat tillsammans, eftersom det är den enda delen som visar istället för att påstå.

Skicka den sedan till SkillProof. Testning och listning är gratis. Vi kör inskickningen genom samma process som allt annat i katalogen: ren installation från din README, triggerbatteri, baseline-jämförelse, outputpoängsättning. Klarar den sig blir den listad med en poäng, och du kan bädda in en "SkillProof-testad"-badge i din README. För en okänd författare med ett två dagar gammalt repo är en oberoende testdom skillnaden mellan "slumpmässig SKILL.md från internet" och något en främling faktiskt installerar. Klarar den sig inte får du felanteckningarna, fixar det, och skickar in igen. Gott om listade skills har gått igenom två omgångar.

Vanliga fel vi ser i inskickningar

Efter några hundra granskningar dyker samma fem upp gång på gång.

Vaga beskrivningar. Fortfarande etta med bred marginal. Om din beskrivning kunde beskriva tre andra skills beskriver den ingen av dem.

Diskbänksskillen. En enda SKILL.md som hanterar granskningar, commits, refaktorering och dokumentation. Varje jobb späder ut triggern för de andra. Dela upp den.

Att upprepa modellens standardbeteende. Ett innehåll som säger "var tydlig, var korrekt, tänk steg för steg" tillför ingenting. Claude gör det ändå. Om att ta bort en rad inte skulle förändra outputen, ta bort raden.

Inga negativa begränsningar. Skills som bara säger vad man ska göra, aldrig vad man ska sluta göra. "Gör INTE"-raderna är där det mesta av beteendeförändringen finns.

Otestade installationsinstruktioner. README säger kopiera en mapp; skillen beror tyst på en andra skill eller ett Python-paket. Dör vid vårt ren-installations-steg varje gång, och det är det mest undvikbara felet på den här listan.

Vanliga frågor

Behöver jag kunna programmera för att skapa en Claude skill? Nej. En SKILL.md är markdown med ett YAML-huvud. Levererar din skill hjälpskript behöver du skriva dem, men rena instruktionsskills, vilket är de flesta, är vanlig skrivning. Skillen i det här inlägget innehåller noll kod.

Hur lång bör en SKILL.md vara? Så kort den kan vara samtidigt som den fortfarande begränsar beteende, typiskt 30 till 150 rader. Under ungefär 20 rader tillför den vanligtvis inget utöver standardbeteende; över några hundra bör du flytta detaljer till reference/-filer. Längd är en kostnad du betalar per aktivering, inte en kvalitetssignal.

Varför triggar inte min skill? Beskrivningen, nästan alltid. Kontrollera att den namnger formuleringar en användare faktiskt skulle skriva istället för att beskriva fördelar, och bekräfta att du startade om sessionen efter installation, eftersom skills laddas vid sessionsstart. Om den triggar på vissa formuleringar men inte andra, lägg till de saknade explicit i beskrivningen.

Vad är skillnaden mellan en skill och en MCP-server? En skill är instruktioner: markdown som formar hur Claude beter sig, ingen kod som körs någonstans. En MCP-server är ett program som ger Claude nya förmågor, som att fråga din databas. Om din idé är "Claude bör angripa X annorlunda" är det en skill. Om det är "Claude behöver åtkomst till Y" är det MCP. Längre version i Claude skills vs MCP.

Kan jag ta betalt för en Claude skill? Det finns ingen inbyggd betalningsmekanism; skills är filer, och det publika ekosystemet drivs av öppna repon. Vissa författare säljer privata skill-paket till team som konsultleveranser, vilket fungerar eftersom värdet är den kodade expertisen, inte filen. Allt tänkt för den publika katalogen bör vara öppet licensierat, eftersom ingen installerar en skill de inte kan läsa.

Avgränsa ett jobb, skriv triggern som ett regex i prosa, begränsa istället för att inspirera, och testa i en ny session innan du berättar för någon. Det är hela hantverket. Resten är iteration, och inskickningskön är öppen.