Claude Code Skills: 9 tips direkte fra Anthropics tech lead

Thariq Shihipar er tech lead for Claude Code hos Anthropic. I marts 2026 delte han den mest grundige samling af erfaringer fra at bygge og bruge skills internt hos Anthropic, hvor de har hundredvis af skills i aktiv drift.

Det er ikke teori. Det er mønstre fra daglig brug af det samme værktøj du sidder med lige nu.

Jeg har taget hans ni tips, oversat dem, og tilføjet praktisk kontekst så du kan bruge dem direkte. Hvert tip inkluderer et eksempel du kan tage med hjem i dag.

Sig ikke det åbenlyse

Claude ved allerede en masse om kodning, frameworks og standardmønstre. Din skill skal ikke genfortælle det. Den skal fokusere på information der skubber Claude ud af sin normale tænkning.

Thariq nævner et konkret eksempel: Anthropics interne frontend design-skill. Den blev bygget fordi Claude har en default-tendens: Inter-fonten, lilla gradienter, afrundede hjørner. Hver gang Claude designer noget uden instrukser, lander det der. Skillen eksisterer udelukkende for at bryde det mønster.

I praksis: Tænk over hvad Claude gør forkert eller generisk i dit domæne. Det er der din skill skal sætte ind. Hvis du laver e-commerce og Claude altid foreslår en standard Stripe checkout-flow, men I bruger Nets Easy med en custom betaling. Det er information skillen skal indeholde.

Spild ikke plads på at forklare hvad en React-komponent er. Brug pladsen på hvad der er unikt ved jeres projekt.

Byg en gotchas-sektion

Det her er ifølge Thariq det mest værdifulde indhold i enhver skill. En gotchas-sektion er en samling af kendte faldgruber: ting der ofte går galt, og som Claude skal undgå.

Du bygger den ikke på dag ét. Du bygger den over tid. Hver gang Claude laver en fejl du skal rette, tilføjer du den til gotchas. Hver gang en kollega opdager et problem, kommer det ind. Det er her compound-værdien bygges op.

Et eksempel fra en deploy-skill:

## Gotchas
- ALDRIG kør `npm run build` før tests er grønne — build-processen
  overskriver output.css og det er svært at rulle tilbage
- Brug altid `--dry-run` først ved database-migrationer i produktion
- API-nøgler til Kit.com udløber hver 90. dag — tjek udløbsdato
  hvis API-kald fejler med 401

I praksis: Start med en tom gotchas-sektion i din skill. Den første uge tilføjer du måske to punkter. Efter en måned har du ti. Efter tre måneder er det den sektion der sparer dig mest tid, fordi den fanger præcis de fejl Claude ellers ville gentage.

Det er Compound Engineering i praksis: fejl der kun sker én gang.

Brug filsystemet til progressive disclosure

En skill er en mappe, ikke bare en fil. Det er et centralt pointe som mange overser.

Idéen er enkel: du fortæller Claude hvilke filer der findes i mappen, og Claude læser dem når det er relevant. Det er progressive disclosure: information leveret på det rigtige tidspunkt i stedet for alt på én gang.

Thariq anbefaler at opdele detaljeret dokumentation i undermapper:

my-skill/
├── SKILL.md              # Hovedfil med overblik og gotchas
├── references/
│   └── api.md            # Detaljeret API-dokumentation
├── templates/
│   └── component.tsx     # Skabelon Claude kan kopiere
└── examples/
    ├── simple.md         # Simpelt eksempel
    └── advanced.md       # Avanceret eksempel

I SKILL.md skriver du noget i retning af:

## Referencefiler
- `references/api.md` — Komplet API-dokumentation for vores betalingsgateway.
  Læs denne når du arbejder med betalinger.
- `templates/component.tsx` — Standard komponentstruktur.
  Brug denne som udgangspunkt for nye komponenter.
- `examples/` — Eksempler på færdige implementeringer.

Claude læser SKILL.md ved aktivering. Når en opgave kræver API-detaljerne, læser den references/api.md. Når den skal bygge en komponent, henter den skabelonen. De andre filer forbliver ulæste og koster ingen tokens.

Hvis du derimod putter alt i én stor SKILL.md, betaler du for hele konteksten hver gang, også de 80% der ikke er relevante for den aktuelle opgave.

I praksis: Har du en skill der er over 200 linjer? Flyt detaljer ud i undermapper. Behold kun overblik, triggers og gotchas i SKILL.md.

Vi gennemgik progressive disclosure i detaljer i kapitel 3.

Undgå at låse Claude fast

Thariq kalder det “railroading”: at give Claude så specifikke instrukser at den ikke kan tilpasse sig. Det gør skillen skør og ubrugelig i alle de situationer du ikke forudså.

Skrøbeligt:

Brug altid `prisma.user.findUnique()` til at hente brugerdata.

Fleksibelt:

Foretræk `prisma.user.findUnique()` til at hente enkeltbrugere.
Brug `findMany()` med pagination når der er behov for lister.
Undgå raw SQL medmindre der er en performance-grund dokumenteret i gotchas.

Forskellen er subtil men afgørende. Den første version fejler når Claude møder en situation der kræver en liste. Den anden giver Claude informationen og friheden til at vælge det rigtige værktøj.

I praksis: Hver gang du skriver “altid” eller “aldrig” i en skill, stop og spørg dig selv: er der undtagelser? Hvis ja, skriv dem. Giv Claude det den skal vide for at tage gode beslutninger, men lad være med at tage beslutningerne for den.

Gode skills er som gode jobbeskrivelser: de definerer rammer og kriterier, ikke hvert eneste skridt.

Tænk setup-flowet igennem

Nogle skills har brug for brugerspecifik konfiguration. Hvilken Slack-kanal skal der postes i? Hvilken database? Hvilket API-endpoint?

Thariq anbefaler at gemme konfiguration i en config.json i skill-mappen. Det vigtige: hvis filen ikke findes, skal skillen bede brugeren om at opsætte den.

## Setup
Denne skill kræver en `config.json` i skill-mappen.
Hvis den ikke findes, spørg brugeren om:
- `slack_channel`: Hvilken Slack-kanal skal standup postes i?
- `timezone`: Hvilken tidszone bruges? (default: Europe/Copenhagen)
- `team_members`: Liste af teammedlemmer (til at nævne dem i standups)

Gem svarene i `config.json` og brug dem fremover.

Første gang brugeren aktiverer skillen, bliver de guidet igennem opsætningen. Anden gang er alt klar.

I praksis: Hvis din skill refererer til noget brugerspecifikt, et firmanavn, et API-endpoint, en mappestruktur, hardcode det ikke. Læg det i config, og lad skillen håndtere første gangs opsætning automatisk. Det gør skillen delbar med dit team uden at de skal rette i SKILL.md.

Description-feltet er til modellen

Vi gennemgik dette i detaljer i kapitel 4, men Thariq understreger det igen fordi det er så vigtigt.

Når Claude starter, læser den description-feltet i alle installerede skills for at afgøre hvilke der er relevante. Det er ikke et resumé til mennesker. Det er en trigger-instruktion til modellen.

Et dårligt description-felt: "Hjælper med deployment."

Et godt description-felt: "Håndterer deploy til produktion via Vercel. Aktivér når brugeren nævner deploy, release, staging eller produktion. Inkluderer pre-deploy tjekliste og rollback-procedurer."

Thariq nævner at forskellen i aktiveringsrate er stor. Den rigtige formulering kan betyde forskellen mellem en skill der aktiveres 20% af gangene og en der aktiveres 84% af gangene.

I praksis: Gå dine eksisterende skills igennem. Læs description-feltet højt. Ville du som model vide hvornår den skal aktiveres? Hvis ikke, omskriv det.

Gem data i skillen

Skills kan lagre data. Ikke bare instruktioner, men faktisk tilstand: append-only logfiler, JSON-tilstand, endda SQLite-databaser.

Thariq giver et konkret eksempel: en standup-post skill der holder en log over tidligere standups. Når den genererer dagens standup, ved den hvad der blev nævnt i går og kan fokusere på hvad der har ændret sig.

## Data
Denne skill vedligeholder en log i `$CLAUDE_PLUGIN_DATA/standup-log.jsonl`.
Hver entry er en JSON-linje med dato, indhold og status.
Læs de seneste 5 entries før du genererer en ny standup,
så du kan fokusere på hvad der er nyt.

Variablen $CLAUDE_PLUGIN_DATA er vigtig. Den peger på en stabil lagerplacering der overlever opgraderinger af Claude Code. Hvis du gemmer data direkte i skill-mappen, risikerer du at miste det næste gang pluginnet opdateres.

I praksis: Tænk over hvilke skills der ville være bedre med hukommelse. En nyhedsbrev-skill der husker hvad der allerede er dækket. En deploy-skill der logger hver deployment. En content-skill der tracker hvilke emner der er skrevet om. Data gør skills smartere over tid. Det er den mekanisme der skaber reel compound-effekt.

Inkludér scripts og generer kode

Giv Claude kode den kan sammensætte, ikke bare instruktioner den skal fortolke.

Det betyder: hjælpefunktioner, library-wrappers, API-klienter, boilerplate-skabeloner. Når Claude har en færdig funktion den kan importere, bruger den sine turns på at komponere og tilpasse i stedet for at rekonstruere noget fra bunden.

Et eksempel:

my-api-skill/
├── SKILL.md
├── helpers/
│   ├── api-client.ts      # Færdig wrapper til jeres API
│   ├── auth.ts            # Authentication-hjælper
│   └── error-handler.ts   # Standard fejlhåndtering
└── templates/
    └── endpoint.ts        # Skabelon for nye endpoints

I SKILL.md:

## Kodebibliotek
- `helpers/api-client.ts` — Brug denne til alle API-kald.
  Den håndterer auth, retry og rate limiting.
- `helpers/error-handler.ts` — Standard fejlhåndtering.
  Wrap alle async operationer med denne.
- `templates/endpoint.ts` — Skabelon for nye API-endpoints.
  Kopiér og tilpas.

I praksis: Næste gang Claude skriver den samme boilerplate for tredje gang, pak den som en hjælpefil i din skill. Du sparer tokens, du sparer tid, og du får konsistens på tværs af dit projekt.

Brug on-demand hooks

Skills kan registrere hooks der kun aktiveres under den pågældende skills session. Dermed kan du bygge sikkerhedsforanstaltninger og specialiserede arbejdsgange.

Thariq giver to eksempler:

/careful: en skill der blokerer farlige kommandoer som rm -rf og DROP TABLE når du arbejder på produktionsdata. Hooket aktiveres når du starter skillen og deaktiveres når sessionen slutter.

/freeze: en skill der blokerer redigeringer udenfor en specifik mappe under debugging. Hvis du fejlsøger en komponent, vil du ikke have at Claude ved et uheld ændrer noget i en anden del af kodebasen.

---
name: careful
description: "Aktivér sikkerhedstjek for produktionsarbejde.
  Brug denne når du arbejder med produktionsdata eller live systemer."
hooks:
  PreToolUse:
    - matcher: Bash
      script: |
        if echo "$input" | grep -qE "rm -rf|DROP TABLE|TRUNCATE|DELETE FROM"; then
          echo "BLOKERET: Farlig kommando i careful-mode. Bekræft med brugeren først."
          exit 1
        fi
---

I praksis: Hooks er særligt nyttige for teams. Du kan bygge en /deploy-skill med hooks der automatisk kører pre-deploy tjek, eller en /hotfix-skill der begrænser ændringer til kun den berørte fil. Det er sikkerhedsnet der aktiveres præcis når de er nødvendige.

Det store billede

Her er alle ni tips samlet:

Thariq slutter med en vigtig nuance:

"Skills are incredibly powerful, flexible tools for agents, but it's still early and we're all figuring out how to use them best."

Det er en ærlig udmelding fra personen der bygger værktøjet. Skills er ikke en færdig opskrift. De er et fleksibelt system du former efter dine behov, og de bedste mønstre bliver stadig opdaget.

Men de ni tips her er ikke gæt. De kommer fra hundredvis af skills i daglig brug hos det team der bygger Claude Code. Start med dem, og du har et godt udgangspunkt.

Næste kapitel: Del Skills med dit team: Sådan deler du skills via Git og marketplace, og hvorfor det er den bedste form for vidensdeling du kan have i en lille virksomhed.

Serien og begreberne

Dette kapitel er en del af guiden til Claude Code Skills. Se alle kapitler der, hvis du vil følge forløbet fra start.