Claude Code Skills · Kapitel 6 af 9
5 Claude Code Skill-patterns med eksempler
De 5 arkitekturer der gør skills brugbare i rigtige workflows
18. marts 2026 · Opdateret 23. september 2026
Kort fortalt
Fem gennemprøvede mønstre til skills, der skal gøre mere end én ting: Sequential Workflow til trin-for-trin processer, Multi-MCP Coordination til flows på tværs af tjenester, Iterative Refinement til generer-validér-forbedr, Context-Aware Selection til skills der vælger tilgang efter situationen, og Domain-Specific Intelligence til ekspertviden indlejret i logik.
De kan kombineres. Anti-mønsteret er mega-skillen, der prøver at være alle fem på én gang.
Indhold
Du har bygget din første skill. Den gør én ting, og den gør det godt. Men de fleste opgaver i virkeligheden er ikke én ting. De er sekvenser, de kræver data fra flere systemer, og de kræver iteration.
De 5 patterns i dette kapitel kommer fra Anthropics officielle 33-siders guide til skills, kombineret med erfaringer fra praktikere der bruger skills dagligt i produktion. Hvert pattern løser et specifikt problem, og de kan kombineres.
For hvert pattern gennemgår vi: hvad det er, hvornår du bruger det, og et konkret eksempel du kan tilpasse.
Pattern 1
Sequential Workflow: trin-for-trin processer
Hvad det er
Det simpleste pattern og det du sandsynligvis bygger først. Skillen definerer en sekvens af trin som Claude udfører i rækkefølge. Hvert trin bygger på outputtet fra det foregående.
Hvornår du bruger det
Når du har en proces du kører på samme måde hver gang. Nøglen er “samme måde”. Hvis trinene varierer afhængigt af kontekst, er du bedre tjent med pattern 4 (Context-Aware Selection).
Eksempel: SEO-indholdsproduktion
---
name: seo-content-pipeline
description: >
Runs the full SEO content pipeline: keyword research, outline,
draft, optimization, and publishing preparation. Use when user
mentions 'SEO', 'write article', 'blog post', 'skriv guide',
'indholdsproduktion', or 'keyword'.
---
## Workflow
Kør disse trin i rækkefølge. Afslut ikke et trin før resultatet
er godkendt.
### Trin 1: Keyword Research
- Analysér det givne emne med tilgængelige søgedata
- Identificér primært keyword, sekundære keywords og relaterede søgninger
- Estimér søgevolumen og konkurrence
- Output: Keyword-rapport i markdown
### Trin 2: Outline
- Byg en artikelstruktur baseret på keyword-rapporten
- Inkludér H2/H3-hierarki, estimeret ordantal per sektion
- Identificér featured snippet-muligheder
- Output: Detaljeret outline med noter
### Trin 3: Første udkast
- Skriv artiklen baseret på outlinen
- Følg stilguiden i references/style-guide.md
- Inkludér interne links til eksisterende ordbogs-indgange
- Output: Komplet artikel i markdown
### Trin 4: SEO-optimering
- Tjek keyword-densitet (primært keyword i title, H1, intro, 2-3x i body)
- Tilføj meta-description (maks 155 tegn)
- Verificér alt-tekster og interne links
- Output: Optimeret artikel med meta-data
### Trin 5: Publiceringsklargøring
- Generér Hugo frontmatter
- Tjek at alle links virker
- Opret commit-besked
- Output: Publiceringsklar fil
## Gotchas
- Spring IKKE trin over, selv om brugeren beder om det
- Hvert trin skal godkendes eksplicit før næste starter
- Hvis keyword-research viser lav volume (<100/måned), rapportér
det og foreslå alternativer før du fortsætter
Det her er det pattern jeg selv bruger mest. Min SEO-pipeline på kristianprimdal.dk er bygget præcis sådan, og det er den der har produceret de 263 ordbogs-indgange og guides du kan læse på sitet.
Pattern 2
Multi-MCP Coordination: flows på tværs af tjenester
Hvad det er
Skillen orkestrerer flere MCP-servere (Model Context Protocol) i én samlet workflow. I stedet for at du manuelt henter data fra GitHub, tjekker Linear og poster i Slack, gør skillen det hele i ét flow.
Hvornår du bruger det
Når en opgave kræver data eller handlinger fra mere end ét system. Det er her skills sparer mest tid, ikke fordi de enkelte trin er svære, men fordi kontekstskiftet mellem systemer koster.
Eksempel: Daglig standup-post
---
name: standup-post
description: >
Generates and posts daily standup update by gathering data from
GitHub, Linear, and Slack. Use when user mentions 'standup',
'daily update', 'daglig status', 'morgenrapport', or
'hvad lavede vi i går'.
---
## Hvad du skal gøre
Saml data fra tre kilder og generér en standup-post:
### Datahentning
1. **GitHub** (via GitHub MCP): Hent commits og merged PRs fra
de sidste 24 timer
2. **Linear** (via Linear MCP): Hent tasks der er markeret som
done/in-progress siden i går
3. **Slack** (via Slack MCP): Tjek #dev-kanalen for relevante
tråde og beslutninger
### Formatering
Kombinér til en standup med tre sektioner:
- **Færdigt i går**: Baseret på GitHub + Linear
- **I gang i dag**: Baseret på Linear (in-progress tasks)
- **Blockers**: Baseret på Slack-tråde med uløste spørgsmål
### Posting
Post den færdige standup i #standup Slack-kanalen.
## Gotchas
- Hvis en MCP-server ikke er tilgængelig, nævn det i posten
i stedet for at fejle
- Deduplikér: samme task kan optræde i både GitHub og Linear
- Hold formateringen kompatibel med Slack-markdown
- Inkludér IKKE kode-diffs — kun commit-beskeder
Det vigtige ved Multi-MCP-patternet er fejlhåndteringen. MCP-servere er eksterne afhængigheder der kan være nede. En god skill stopper ikke bare fordi én kilde ikke svarer. Den rapporterer hvad der mangler og fortsætter med det den har.
Pattern 3
Iterative Refinement: generer, validér, forbedr, gentag
Hvad det er
Skillen genererer et output, evaluerer det mod definerede kriterier, og forbedrer det i en loop indtil kvaliteten er god nok. Princippet er det samme som når du selv arbejder. Du laver et udkast, tjekker det, retter det, tjekker igen.
Hvornår du bruger det
Når kvaliteten af outputtet ikke kan vurderes på forhånd, og når “godt nok” kræver flere gennemgange. Typisk til kreativt output, UI-design, eller kompleks kode der skal opfylde mange krav samtidigt.
Dataen bag
OpenAI offentliggjorde i 2025 hvordan de bruger skills (de kalder det “instructions” og “codegen setups”) til at vedligeholde deres open source Agents SDK. Deres resultat: 45% flere PRs merget efter de implementerede Iterative Refinement-patternet på tværs af deres repositories.
Eksempel: Frontend-design med screenshot-validering
---
name: ui-design-iterate
description: >
Generates frontend UI components and iteratively improves them
by comparing screenshots against design specs. Use when user
mentions 'design', 'UI', 'component', 'layout', 'frontend',
'style', or asks to build visual elements.
---
## Workflow
### Generate
1. Byg komponenten baseret på brugerens beskrivelse
2. Følg design-systemet i references/design-tokens.md
3. Output: Funktionel komponent med styling
### Validate
1. Tag et screenshot af komponenten (via browser-værktøj)
2. Sammenlign med design-specifikation eller brugerens mockup
3. Evaluér på: layout, spacing, typografi, farver, responsivitet
4. Score 1-10 for hvert område
### Improve
1. Identificér de 2-3 vigtigste afvigelser
2. Ret dem i koden
3. Tag nyt screenshot
4. Gentag Validate
### Exit-kriterier
- Stop når alle scores er 7+ OG brugeren godkender
- Maks 4 iterationer — rapportér status hvis grænsen nås
## Gotchas
- Tag ALTID screenshot efter ændringer — stol ikke på at
kode-ændringer ser rigtige ud uden visuel verifikation
- Fokusér på de største afvigelser først — finjustering
kommer i senere iterationer
- Responsivitet: test på mindst 2 breakpoints (mobile + desktop)
Iterative Refinement udnytter noget modeller allerede er gode til: at sammenligne og evaluere. Claude er bedre til at vurdere “er det her godt?” end til at ramme perfekt i første forsøg.
Pattern 4
Context-Aware Selection: vælger tilgang baseret på situation
Hvad det er
Skillen analyserer konteksten og vælger den rigtige tilgang. I stedet for én fast sekvens, har den flere mulige veje og beslutter selv hvilken der passer.
Hvornår du bruger det
Når den samme type opgave kræver forskellige tilgange afhængigt af situationen. Kode-review af en database-migrering kræver andre tjek end review af en frontend-komponent. Et kundesvar til en teknisk forespørgsel kræver en anden tone end et svar til en fakturaklage.
Eksempel: Differentieret kode-review
---
name: smart-code-review
description: >
Reviews code with context-aware rules based on file type and
change category. Applies different checklists for migrations,
API changes, frontend, and tests. Use when user mentions
'review', 'PR', 'pull request', 'tjek kode', or 'code quality'.
---
## Kategorisering
Analysér de ændrede filer og klassificér reviewet:
### Hvis migration-filer (db/migrate/*, migrations/*)
- Tjek for irreversible ændringer (drop column, drop table)
- Verificér rollback-script eksisterer
- Tjek at indeksering er tilføjet for nye foreign keys
- Vurdér impact på eksisterende data
### Hvis API-endpoints (routes/*, controllers/*, api/*)
- Tjek authentication og authorization
- Verificér input-validering
- Tjek rate limiting
- Vurdér backward compatibility
- Tjek at API-dokumentation er opdateret
### Hvis frontend (components/*, pages/*, *.tsx, *.vue)
- Tjek accessibility (ARIA labels, keyboard navigation)
- Verificér responsivitet
- Tjek for hardcodede strenge (i18n)
- Vurdér performance (unødvendige re-renders)
### Hvis tests (test/*, spec/*, *.test.*)
- Tjek at edge cases er dækket
- Verificér at tests er isolerede (ingen afhængigheder mellem tests)
- Vurdér test-navngivning og læsbarhed
## For alle kategorier
- Tjek for credentials/secrets i koden
- Verificér error handling
- Vurdér navngivning og kode-konventioner
- Tjek for TODO/FIXME der burde være issues
## Gotchas
- Én PR kan indeholde filer fra flere kategorier — anvend
alle relevante tjek
- Prioritér sikkerhedsrelaterede fund over stilmæssige
- Hvis PRen er over 500 linjer, foreslå at splitte den op
Geocodio, et geocoding-firma der bruger Laravel, kører præcis dette pattern med 4 skills der automatisk vælger den rette review-tilgang baseret på filtypen. De har kombineret det med git hooks der trigger reviewet automatisk ved PR-oprettelse, så ingen kode kan merges uden kontekst-bevidst review.
Pattern 5
Domain-Specific Intelligence: ekspertviden indlejret i logik
Hvad det er
Skillen indeholder domænespecifik viden som Claude ikke har fra sin træningsdata. Det er dit firmas interne viden: API-detaljer, edge cases, forretningsregler, navnekonventioner, pakket som instruktioner.
Hvornår du bruger det
Når Claude laver de samme fejl fordi den ikke kender dine interne systemer. Når onboarding af en ny medarbejder (eller en ny AI-agent) kræver viden der ikke står i offentlig dokumentation.
Tænk på det som gotchas-sektionen skaleret op. I stedet for en liste med ting der kan gå galt, har du et komplet vidensystem om dit domæne.
Eksempel: Intern faktureringsmotor
---
name: billing-expert
description: >
Provides deep domain knowledge about our internal billing system
including API quirks, edge cases, and common mistakes. Use when
user works with code in billing/, mentions 'faktura', 'billing',
'invoice', 'payment', 'subscription', or 'abonnement'.
---
## Vores billing-system
Vi bruger en custom billing-motor bygget oven på Stripe.
Kodebasen er i `billing/` mappen.
## Kritiske regler
1. **Aldrig slet en invoice-record.** Soft-delete altid.
Bogføringsloven kræver det. Brug `invoice.archive()`,
ikke `invoice.delete()`.
2. **VAT-beregning.** Altid via `VatCalculator.compute()`,
aldrig manuelt. Den håndterer omvendt betalingspligt for
EU-kunder, 0% for ikke-EU, og de 3 danske momssatser.
3. **Subscription lifecycle.** Vores subscriptions har 7
states, ikke 3 som Stripes dokumentation viser:
- trial → active → past_due → canceled
- trial → active → paused → active (genaktivering)
- trial → expired (aldrig konverteret)
Tjek ALTID state-diagrammet i references/sub-states.svg.
4. **Currency.** Alt internt er i øre (cents), ikke kroner.
Konvertér ved display, aldrig ved beregning. 10000 = 100 DKK.
5. **Proration.** Vores proration-logik er custom og matcher
IKKE Stripes default. Se `billing/services/proration.py`.
Rør ikke den fil uden at køre `test_proration_suite` først.
## Kendte fejl i Stripe-integrationen
- Webhook `invoice.payment_failed` kan komme EFTER
`invoice.payment_succeeded` i race conditions. Tjek altid
timestamp, ikke rækkefølge.
- Stripe sender duplicate webhooks ~2% af tiden. Alle handlers
SKAL være idempotente.
## Gotchas
- Test-miljøet bruger Stripe test keys men vores staging har
RIGTIGE subscription IDs — lav aldrig delete-operationer
i staging
- `billing/legacy/` er deprecated kode. Importér ALDRIG fra
den mappe. Den eksisterer kun fordi 12 kunder stadig kører
på det gamle system.
Katie Parrott fra Every bruger Domain-Specific Intelligence-patternet til deres redaktionelle workflow. De har 6 skills der indeholder stilregler, faktakontrol-protokoller og formateringskrav specifikke for deres publikation. Nye skribenter (og AI-agenter) producerer indhold der matcher husets stil fra dag ét.
Kombination og anti-patterns
Kombination af patterns
De fleste skills i produktion bruger 2-3 patterns sammen. SEO-pipelinen fra pattern 1 bruger også Iterative Refinement (pattern 3) til at forbedre hvert udkast. Kode-reviewet fra pattern 4 bruger Domain-Specific Intelligence (pattern 5) til at kende de interne konventioner.
Her er de mest almindelige kombinationer:
| Kombination | Eksempel |
|---|---|
| Sequential + Iterative | Indholdsproduktion: skriv → evaluer → forbedr → publicer |
| Multi-MCP + Sequential | Release-noter: hent data fra 3 systemer → kompilér → formatér → post |
| Context-Aware + Domain | Kode-review: vælg regler baseret på filtype + interne konventioner |
| Sequential + Domain | Onboarding: trin-for-trin setup med firmaviden i hvert trin |
Anti-patternet: mega-skillen
Der er én fælde alle falder i: at bygge én skill der gør alt. En “dev-assistant” der reviewer kode, skriver tests, genererer dokumentation, håndterer deploys og laver kaffe.
Det virker ikke. Grunden er simpel: description-feltet kan ikke trigge på alt, og body-sektionen bliver så lang at den spiser al kontekst.
Hold skills fokuserede. Én skill per ansvarsområde. Hvis en workflow kræver flere ansvarsområder, brug Sequential Workflow-patternet til at kæde dem sammen.
OpenAI viser selv vej her. Deres Agents SDK-repositories bruger 8 Python-skills og 3 JavaScript-skills: 11 i alt, hver med et klart ansvar. Resultatet er de 45% flere PRs merget vi nævnte under Iterative Refinement.
Opsummering
De 5 patterns i overblik
| # | Pattern | Brug når… | Nøgle |
|---|---|---|---|
| 1 | Sequential Workflow | Processen er den samme hver gang | Definér trin i rækkefølge, godkend hvert trin |
| 2 | Multi-MCP Coordination | Data kommer fra flere systemer | Håndtér fejl fornuftigt, deduplikér |
| 3 | Iterative Refinement | Kvalitet kræver flere gennemgange | Definér exit-kriterier, sæt maks-iterationer |
| 4 | Context-Aware Selection | Samme opgave, forskellige situationer | Definér kategorier og regler for hver |
| 5 | Domain-Specific Intelligence | Claude mangler intern viden | Dokumentér regler, edge cases, gotchas |
Start med ét pattern. Byg en skill der bruger det. Brug den i en uge. Tilføj et pattern mere når du har brug for det.
De mest effektive skills er ikke de mest komplekse. Det er dem der løser et reelt problem du har hver uge, med det mindst mulige antal patterns.
I næste kapitel ser vi på hvordan du organiserer og vedligeholder en voksende samling af skills, fra 5 til 60+ uden at miste overblikket.
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.
Hjælp til jeres opgave
Vil I have hjælp til at gå fra idé til brug? Læs om min AI-rådgivning. Jeg hjælper jer med at vælge en opgave og bygge en løsning sammen med jer.