Skapa en egen Claude Code-skill för teamet – från arbetsrutin till testad SKILL.md

När lönar sig en egen skill?

En skill passar när teamet gör samma sak ofta, på ett bestämt sätt, och när instruktionen är för lång för att stå i CLAUDE.md. Exempel: PR-granskning, release notes, migreringar, incidentrapporter och onboarding till en kodbas.

Exempel: teamets PR-granskning som skill

1. Skriv ner rutinen först

Fråga den som granskar bäst i teamet: vad tittar du på, i vilken ordning, och hur ser en bra kommentar ut? Skriv ner det som en vanlig checklista. Om rutinen inte går att skriva ner för en människa fungerar den inte för Claude heller.

2. Mappstruktur

.claude/skills/pr-review/
├── SKILL.md                 # instruktioner + frontmatter
├── references/
│   └── kodstandard.md       # teamets regler, läses vid behov
├── scripts/
│   └── check.sh             # lint + tester, samma varje gång
└── CHANGELOG.md

3. SKILL.md

---
name: pr-review
description: Granskar en pull request enligt teamets kodstandard.
  Använd när användaren ber om kodgranskning, PR-review eller
  "granska ändringarna". Använd inte för att skriva ny kod.
---

# PR-granskning enligt vår standard

## Arbetsgång
1. Kör `git diff main...HEAD` och läs alla ändrade filer.
2. Kontrollera mot reglerna i [references/kodstandard.md](references/kodstandard.md).
3. Kör `scripts/check.sh` och ta med resultatet.
4. Skriv granskningen i formatet nedan.

## Format
- **Sammanfattning:** 2–3 meningar.
- **Måste åtgärdas:** fil:rad + varför.
- **Förslag:** valfria förbättringar.
- **Tester:** saknas tester för ändrad logik?

## Regler
- Gissa aldrig – citera koden du kommenterar.
- Kommentera inte formatering som lintern redan fångar.

4. Skriptet

#!/usr/bin/env bash
set -euo pipefail
npm run lint --silent
npm test --silent -- --changedSince=main

Det som ska bli exakt likadant varje gång läggs i skript. Det som kräver omdöme står i SKILL.md. Långa regelverk ligger i references/ och läses bara när de behövs, så att skillen hålls kort.

Skriv en description som triggar rätt

Beskrivningen avgör när Claude använder skillen. Skriv vad den gör och när den ska användas, med de ord teamet faktiskt skriver, och när den inte ska användas.

Testa skillen

1. Positiva fall: 3–5 prompter som ska trigga skillen, t.ex. "granska min PR".
2. Negativa fall: 2–3 prompter som inte ska trigga, t.ex. "skriv en ny endpoint".
3. Före/efter: kör samma PR med och utan skill och jämför mot checklistan.
4. Ny session: testa alltid i en ren session så att tidigare kontext inte påverkar.
5. Riktig data: använd 2–3 verkliga, redan granskade PR:er som facit.

Tips: Anthropics skill-creator (se topplistan) kan hjälpa till att skapa och utvärdera skills.

Versionshantering

• Skillen ligger i repot och ändras bara via pull request med granskning.
• För en CHANGELOG.md med version och vad som ändrats.
• Kör om testprompterna vid varje ändring av SKILL.md.
• Ge skillen en namngiven ägare, t.ex. via CODEOWNERS.
• Behöver flera repon samma skill: paketera den som plugin i en intern marknadsplats i stället för att kopiera.

Utrullning i teamet

1. Pilot (1–2 veckor): 2–3 utvecklare använder skillen och noterar fel.
2. Justera: uppdatera description och regler utifrån piloten.
3. Hela teamet: merga till huvudgrenen, presentera på ett teammöte.
4. Följ upp: gå igenom skillen varje kvartal och ta bort det som inte används.

Vanliga misstag

• För vag description – skillen triggar aldrig, eller jämt.
• Allt i en enda lång SKILL.md i stället för referensfiler.
• Ingen testning efter ändringar.
• Flera skills som gör nästan samma sak.
• Ingen ägare – skillen blir inaktuell när kodstandarden ändras.

Vanliga frågor