Claude Skills vs Copilot Instructions: Fuld sammenligning

GitHub Copilot har flere brugere end noget andet AI-kodningsværktøj, så dets tilpasningsformat er nok det mest udbredte stykke AI-konfiguration, der findes. Millioner af repos bærer nu en .github/copilot-instructions.md. Claude-skills ankom senere, spredte sig hurtigt og løser et overlappende problem på en anden måde. Hvis du bruger begge værktøjer, eller du beslutter, hvilket der fortjener dit teams konfigurationsindsats, betyder forskellene mere end markedsføringen antyder.

Vi driver SkillProof, hvor vi installerer Claude-skills på rene maskiner og tester dem mod reelt arbejde, før vi lister dem, så vores bias ligger på skills-siden, og det siger vi højt med det samme. Vi har også set hundredvis af instruktionsfiler i begge formater lykkes og fejle, og fejltilstandene viser sig at være næsten identiske. Denne sammenligning forsøger at være fair over for begge.

TL;DR

Copilot custom instructions er altid-på kontekst for kode. Claude-skills er ekspertise efter behov til enhver opgave. Instructions vinder på teamdistribution og IDE-integration; skills vinder på aktiveringslogik, bundlede ressourcer og alt, der ikke er kode.

	Claude skills	Copilot custom instructions
Mekanisme	SKILL.md med et beskrivelsesfelt; Claude loader indholdet, når en opgave matcher	.github/copilot-instructions.md anvendt repo-bredt, plus *.instructions.md-filer scopet med applyTo-globs
Aktivering	Semantisk: modellen matcher din forespørgsel mod beskrivelsen	Altid på (repo-fil) eller filsti-match (globs)
Omfang	Enhver opgave Claude håndterer: kode, dokumenter, e-mail, analyse	Kode og Copilot-flader: chat, kodereview, coding agent
Portabilitet	Ét format på tværs af Claude Code, claude.ai, desktop, API	Bundet til Copilot; delvis support varierer efter IDE og flade
Bundlede ressourcer	Scripts, skabeloner, referencefiler, loadet dovent	Kun markdown-tekst
Token-adfærd	~100 tokens i hvile per skill; fuldt indhold loader ved trigger	Hele den anvendelige fil hægtes på hver forespørgsel
Økosystem	Tusindvis af community-skills, mest utestede	Mest private per-repo-filer; awesome-lister på vej frem, også utestede

Hvis du kun husker én linje: instructions beskriver din kodebase, skills beskriver en evne. Det er forskellige job, og de fleste teams vil før eller siden have begge dele. For fundamentet på skills-siden dækker vores komplette guide til Claude-skills formatet i dybden. Begge formater ændrer, hvordan en model opfører sig; at forbinde en model til ekstern data er en anden akse, dækket i Claude skills vs MCP-servere.

Hvad Copilot custom instructions egentlig er

Kernen i systemet er én fil: .github/copilot-instructions.md, committet til repoet. Copilot Chat læser den automatisk og indsætter den foran forespørgsler i det repo, på tværs af VS Code, Visual Studio, JetBrains-IDE'er og github.com. Coding agent læser den, når den arbejder på issues; Copilot code review læser den, når den reviewer pull requests. Én markdown-fil, og hver Copilot-flade, der rører repoet, opfører sig derefter.

I 2025 udvidede GitHub formatet med scopede instruktionsfiler: .github/instructions/*.instructions.md, hver med frontmatter, der målretter filstier.

---
applyTo: "src/api/**/*.ts"
---

All API route handlers return the ApiResponse<T> envelope.
Never throw inside a handler; return err() with a typed error code.

Globbet gør præcis, hvad det siger. Redigér en fil under src/api/, og disse instruktioner følger med i forespørgslen. Redigér en README, og det gør de ikke. Der findes også personlige instructions, sat i dine github.com Copilot-indstillinger, og organisationsinstructions, som Business- og Enterprise-admins kan skubbe ud til hvert medlem.

Styrkerne her fortjener en fair læsning, for de er reelle.

Instructions er repo-native. Filen ligger, hvor koden ligger, og ændringer går gennem pull request-review som alt andet. Når nogen opdaterer error-handling-konventionen, er diffen synlig, og hele teamet får den ved pull. Intet i Claude-økosystemet distribuerer teamkonfiguration lige så rent, undtagen projekt-niveau-skills i .claude/skills/, som låner samme trick.

Glob-målretning er præcis på en måde, semantisk triggering ikke er. applyTo: "**/*.test.ts" fyrer på præcis de filer, hver gang, uden tvetydighed. En Claude-skill trigger, når modellen beslutter, at beskrivelsen matcher, hvilket er fleksibelt og lejlighedsvis forkert. For regler, der kortlægges til filstier, slår deterministisk det kloge.

Og rækkevidden er bred. Samme fil styrer live chat i editoren og de asynkrone flader, hvor intet menneske styrer: kodereview og coding agent. Den review-integration har især ingen direkte skills-ækvivalent.

Hvad skills gør, som instructions ikke kan

Den strukturelle forskel er aktivering. En Copilot instructions-fil er altid i prompten (eller sti-matchet ind i den). En skill ligger på disk til en pris af omkring 100 tokens metadata, indtil en opgave rent faktisk matcher dens beskrivelse, hvorefter hele indholdet loader. Det er progressiv afsløring, og det ændrer, hvad du har råd til at skrive.

En instructions-fil skal forblive kort, fordi hver linje beskatter hver forespørgsel; GitHubs egen vejledning siger, hold det kort, og oppustede filer udvander sig selv, indtil modellen begynder at ignorere midten. En skills indhold kan løbe op i tusindvis af ord, plus referencefiler, der kun loader ved behov, fordi intet af det koster noget, før øjeblikket er relevant. Vores testede Test-Driven Development-skill bærer en fuld red-green-refactor-disciplin, det ville være absurd at injicere i hver forespørgsel; som skill aktiverer den, når du bygger en feature, og forbliver stille, når du spørger, hvad en regex gør.

Skills bundler også ting, der ikke er prosa. En skill-mappe kan bære eksekverbare scripts, dokumentskabeloner, tjeklister og gennemarbejdede eksempler; DOCX-skillen leverer kode, der faktisk manipulerer Word-XML. Copilot instructions er markdown-tekst, punktum. Du kan beskrive en procedure; du kan ikke levere værktøjet, der udfører den.

Så er der grænsen, der betyder mest for ikke-udviklere: Copilot instructions slutter, hvor kode slutter. De konfigurerer en kodningsassistent. Claude-skills konfigurerer Claude, som folk bruger til kontrakter, regneark, koldt salg-e-mails, mødenotater og dataanalyse. En skill som Code Review Checklist overlapper med Copilot-territorium, men halvdelen af vores katalog har ingen Copilot-ækvivalent selv i teorien. Hvis din AI-brug rækker ud over IDE'en, var instructions-filer aldrig gået til at dække det.

Én formatnote: skills er portable på tværs af hver Claude-flade. Samme mappe virker i Claude Code, uploader til claude.ai og kobles på API-forespørgsler. Copilot instructions er portable på tværs af Copilot-flader, hvilket er snævrere, selvom branchens langsomme konvergens mod AGENTS.md (som Copilot nu også læser) begynder at udviske kanterne.

Hvad instructions gør, som skills ikke kan

Fairness går begge veje, og der er tre job, hvor Copilot instructions ganske enkelt er det bedre værktøj.

PR-reviewkontekst er den store. Copilot code review kører på GitHubs infrastruktur mod dine pull requests, og den læser din instructions-fil, når den gør. Skriv "flag enhver ny endpoint, der mangler rate-limiting", og revieweren anvender det på hver PR, fra hver bidragyder, uanset om de har konfigureret noget lokalt. Claude har ingen hostet ækvivalent, der automatisk henter dine skills på hver pull request; du skal selv koble det gennem CI.

Organisationsdækkende politik er den anden. En Copilot Enterprise-admin kan sætte instructions, der når hver udvikler i organisationen uden at nogen af dem installerer noget. Claude-skills installeres per maskine eller per repo. For et platform-team, der forsøger at håndhæve "foreslå aldrig den udfasede auth-klient" på tværs af 400 udviklere, slår push-fra-oven at håbe, alle klonede de rigtige dotfiles.

For det tredje, IDE-native adfærd. Instructions former Copilot inde i editoren, folk allerede lever i, uden et separat værktøj at tage i brug. Aktiveringsspørgsmålet opstår aldrig, fordi der ingen aktivering er: konteksten er bare der, på hver forespørgsel. For altid-sande fakta om en kodebase er altid-på korrekt adfærd, hvilket er samme grund til, at Claude Code har CLAUDE.md ved siden af skills. Vi lavede den parallelle pointe i Claude skills vs Cursor rules: hvert værktøj ender med at have brug for både et altid-loadet lag og et efter-behov-lag, og værktøjerne adskiller sig hovedsageligt i, hvilket lag de har bygget godt.

Konvertering mellem de to formater

Formaterne er tætte nok på hinanden til, at migrering mest er omorganisering. Her er en reel-formet blok fra en copilot-instructions.md:

## Error handling

- All service functions return Result<T, AppError>, never throw.
- Map external errors to AppError codes in the adapter layer only.
- Log with the request ID from context; never log raw error objects
  from third-party SDKs, they can contain tokens.
- New AppError codes go in errors/codes.ts with a doc comment.

Som skill får den samme viden en triggerbetingelse og plads til at vokse:

---
name: error-handling-conventions
description: Applies our Result-based error handling conventions when
  writing or reviewing service code, adding error paths, or creating
  new AppError codes. Use when the user works on error handling,
  exceptions, or failure cases in the services layer.
---

# Error handling conventions

When writing or modifying service-layer code:

1. Service functions return Result<T, AppError>. Never throw from
   a service function. If you find existing code that throws,
   flag it, do not silently rewrite it.
2. Map external errors to AppError codes in the adapter layer only.
   If a service needs a new mapping, it belongs in the adapter.
3. Log with the request ID from context. Never log raw error
   objects from third-party SDKs; they can contain tokens.
4. New AppError codes go in errors/codes.ts with a doc comment
   explaining when the code fires.

For retry and timeout conventions, see [resilience.md](resilience.md).

Læg mærke til, hvad der ændrede sig. Beskrivelsen bærer nu trigger-fraser, den del forfattere oftest fejler på; vage beskrivelser trigger aldrig. Indholdet fik negative begrænsninger ("flag it, do not silently rewrite it"), som en altid-på-fil ikke har råd til tokens til. Og den sidste linje peger på en referencefil, der kun loader, når retries kommer på tale.

Den modsatte retning er en komprimeringsøvelse. Tag en skills indhold, behold reglerne, der gælder for hver forespørgsel i målstierne, skær procedurerne og edge cases væk, og læg resultatet i en scopet fil:

---
applyTo: "src/services/**/*.ts"
---

Service functions return Result<T, AppError> and never throw.
Error mapping lives in the adapter layer. Log with the request ID;
never log raw third-party error objects.

Hvad du mister ved at gøre det: betinget loading og bundlet referencemateriale. Hvad du vinder: reglerne styrer nu også Copilot code review på hver PR, der rører src/services/. Ingen af byttehandlerne er forkerte. De er forskellige placeringer af samme viden.

At køre Claude Code og Copilot side om side

Mange teams vælger aldrig, og arbejdsdelingen, der opstår, er konsistent nok til at beskrive.

Copilot håndterer in-editor-laget plus PR-review, konfigureret af instructions-filer, der beskriver kodebasen. Claude Code håndterer sessionslaget: multi-fil-features, refaktoreringer, debug-undersøgelser, og det omkringliggende arbejde som changelogs og migreringsdokumenter, konfigureret af CLAUDE.md for repo-fakta og skills for evner. Overlappet er mindre, end det ser ud til, fordi værktøjerne sidder i forskellige højder. Autocomplete vil have korte altid-sande regler; en agent, der kører en 40-minutters opgave, vil have procedurer.

Den praktiske opsætning, vi ser fungere: hold .github/copilot-instructions.md og CLAUDE.md som søskende, der siger det samme på hvert værktøjs dialekt (nogle teams genererer begge fra én kildefil), brug applyTo-globs til sti-scopede koderegler, og brug skills til alt procedureagtigt. En Git Workflow-skill, der kører din branching- og commit-disciplin, har intet nyttigt udtryk som en Copilot instruction, og en "vi bruger pnpm, ikke npm"-regel har intet at gøre som en skill. Hvis du bygger Claude-siden af dette fra bunden, er vores bedste kodningsskills-rangliste sorteret efter testet score.

Grænsen er heller ikke fast. Teams, der starter med Copilot til fuldførelser, plejer at give mere af det agentiske arbejde til Claude Code over tid, ikke fordi instructions fejler, men fordi et sessionsværktøj med skills betaler sig mere på lange opgaver. Det modsatte sker også: teams dybt i Claude Code beholder Copilot alligevel, fordi PR-review-integrationen er så bekvem. Behandl opdelingen som en standard, ikke en doktrin.

En advarsel fra vores testning: duplikering driver. Når Copilot-filen siger, at services aldrig kaster, og skillen siger, at services må kaste i adapter-laget, får du to assistenter, der selvsikkert håndhæver forskellige regler. Den, der ejer konventionen, bør eje begge filer i samme PR.

Ingen tester instructions-filer heller

Her er den ubehagelige symmetri. Vi byggede SkillProof, fordi omkring halvdelen af de community Claude-skills, vi installerer, fejler i første forsøg, et mønster vi dokumenterede i hvorfor halvdelen af Claude-skills ikke virker. De to dominerende fejltilstande er installationer, der ikke virker fra README'ens egne instruktioner, og beskrivelser for vage til nogensinde at trigge.

Copilot instructions har samme sygdom med andre symptomer. De awesome-copilot-lister og instructions-fil-samlinger, der breder sig på GitHub, er den samme utestede markdown: filer kopieret fra et blogindlæg til .github/, aldrig verificeret mod faktisk modeladfærd. Fejltilstandene kortlægges næsten en-til-en. En vag skill-beskrivelse betyder, skillen trigger aldrig; en oppustet instructions-fil betyder, reglerne udvandes, indtil modellen ignorerer dem. En skill-krop, der gentager standard modeladfærd, tilføjer intet; en instructions-fil fuld af "skriv ren, veldokumenteret kode" tilføjer intet. I begge økosystemer forveksles filens eksistens med filens funktion.

Forskellen er, at instructions-fil-fejl er stillere. En skill, der aldrig trigger, er i det mindste detekterbart inaktiv. En instructions-fil er altid teknisk "anvendt", så teams antager, den virker, og ingen kører den med-og-uden-sammenligning, der ville vise, om den overhovedet ændrer output. Den sammenligning er præcis vores outputkriterium for skills, og det er den test, vi ville foreslå for din Copilot-fil også: tag tre reelle opgaver, kør dem med instructions-filen til stede og fraværende, og diff resultaterne. Hvis du ikke kan se, hvad der er hvad, har du betalt tokens for en placebo.

Ofte stillede spørgsmål

Kan GitHub Copilot bruge Claude-skills?

Nej. Skills er et Claude-side format læst af Claude Code, claude.ai og API'et. Copilot kan ikke loade en SKILL.md, selvom Copilot tilbyder Claude-modeller som backend; modellen er udskiftelig, konfigurationslaget er det ikke. Viden inde i en skill konverterer som regel til en instructions-fil, minus betinget loading og eventuelle bundlede scripts.

Virker Claude-skills sammen med repo-instructions som copilot-instructions.md?

De sameksisterer uden konflikt, fordi hvert værktøj kun læser sine egne filer. Claude Code ignorerer .github/copilot-instructions.md, og Copilot ignorerer .claude/skills/. Risikoen er ikke en kollision, det er drift: to filer, der koder samme konvention, vil før eller siden være uenige, medmindre de vedligeholdes sammen.

Hvad er bedst til at håndhæve teamkodningsstandarder?

For regler, der kortlægges til filstier og skal nå hver bidragyder, Copilot instructions med applyTo-globs, fordi de også gælder for Copilot code review på PR'er. For procedurestandarder, som hvordan man kører en migrering, skills, fordi de kan bære lange procedurer og loade dem, kun når relevant. De fleste standarddokumenter indeholder begge slags og vil gerne splittes derefter.

Er Copilot instructions billigere på tokens end skills?

Som regel det modsatte. En anvendelig instructions-fil hægtes på hver forespørgsel, så en 1.500-token-fil koster 1.500 tokens per interaktion, uanset om den er relevant. En skill koster omkring 100 tokens i hvile og loader kun sit indhold ved et match. Altid-på er værd at betale for, når reglerne genuint gælder for hver forespørgsel, hvilket er grunden til, at korte instructions-filer slår lange.

Bør jeg konvertere min copilot-instructions.md til skills, hvis jeg flytter til Claude Code?

Split den frem for at konvertere den. De altid-sande fakta om repoet, dets build-kommandoer og konventioner, hører hjemme i CLAUDE.md, som er den nærmeste analog. De procedurale afsnit, alt der læses som "når du gør X, følg disse trin," hører hjemme i skills, så de loader efter behov. En lige konvertering giver som regel enten en oppustet CLAUDE.md eller skills, der trigger på alt.