Claude-skills vs Copilot-instruksjoner: full sammenligning

GitHub Copilot har flere brukere enn noe annet AI-kodeverktøy, så formatet dets for tilpasning er trolig den mest utbredte AI-konfigurasjonen som finnes. Millioner av repoer bærer nå en .github/copilot-instructions.md. Claude-skills kom senere, spredte seg raskt, og løser et overlappende problem på en annen måte. Bruker du begge verktøyene, eller skal du avgjøre hvilket som fortjener teamets konfigurasjonsinnsats, betyr forskjellene mer enn markedsføringen antyder.

Vi driver SkillProof, der vi installerer Claude-skills på rene maskiner og tester dem mot reelt arbeid før vi lister dem, så vår vinkling ligger på skill-siden, og det sier vi rett ut. Vi har også sett hundrevis av instruksjonsfiler i begge formater lykkes og mislykkes, og feilmodusene viser seg å være nesten identiske. Denne sammenligningen prøver å være rettferdig mot begge.

Kort fortalt

Copilots custom instructions er alltid-på kontekst for kode. Claude-skills er ekspertise på forespørsel for enhver oppgave. Instruksjoner vinner på teamdistribusjon og IDE-integrasjon; skills vinner på aktiveringslogikk, bundlede ressurser, og alt som ikke er kode.

	Claude-skills	Copilot custom instructions
Mekanisme	SKILL.md med et beskrivelsesfelt; Claude laster innholdet når en oppgave matcher	.github/copilot-instructions.md gjeldende for hele repoet, pluss *.instructions.md-filer skopet med applyTo-globs
Aktivering	Semantisk: modellen matcher forespørselen din mot beskrivelsen	Alltid på (repo-fil) eller filbane-match (globs)
Omfang	Enhver oppgave Claude håndterer: kode, dokumenter, e-post, analyse	Kode og Copilot-flater: chat, code review, coding agent
Portabilitet	Ett format på tvers av Claude Code, claude.ai, desktop, API	Bundet til Copilot; delvis støtte varierer per IDE og flate
Bundlede ressurser	Skript, maler, referansefiler, lastet lat	Bare markdown-tekst
Tokenatferd	~100 tokens i ro per skill; fullt innhold lastes ved trigger	Hele den gjeldende filen kobles på hver forespørsel
Økosystem	Tusenvis av community-skills, stort sett utestet	Mest private per-repo-filer; awesome-lister vokser frem, også utestet

Husker du bare én linje: instruksjoner beskriver kodebasen din, skills beskriver en evne. Det er forskjellige jobber, og de fleste team vil etter hvert ha begge. For grunnlaget på skill-siden dekker vår komplette guide til Claude-skills formatet i dybden. Begge formater endrer hvordan en modell oppfører seg; å koble en modell til eksterne data er en annen akse, dekket i Claude-skills vs MCP-servere.

Hva Copilot custom instructions egentlig er

Kjernen i systemet er én fil: .github/copilot-instructions.md, commitet til repoet. Copilot Chat leser den automatisk og setter den foran forespørsler i det repoet, på tvers av VS Code, Visual Studio, JetBrains-IDE-er og github.com. Coding agent leser den når den jobber med issues; Copilot code review leser den når den vurderer pull requests. Én markdown-fil, og hver Copilot-flate som rører repoet oppfører seg deretter.

I 2025 utvidet GitHub formatet med skopede instruksjonsfiler: .github/instructions/*.instructions.md, hver med frontmatter som retter seg mot filbaner.

---
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.

Globen gjør det den sier. Rediger en fil under src/api/, og disse instruksjonene følger med forespørselen. Rediger en README, og de gjør ikke det. Det finnes også personlige instruksjoner, satt i dine github.com Copilot-innstillinger, og organisasjonsinstruksjoner, som Business- og Enterprise-administratorer kan pushe til hvert medlem.

Styrkene her fortjener en rettferdig lesning, for de er reelle.

Instruksjoner er repo-native. Filen ligger der koden ligger, og endringer går gjennom pull request-review som alt annet. Når noen oppdaterer feilhåndteringskonvensjonen, er diffen synlig og hele teamet får den ved pull. Ingenting i Claude-økosystemet distribuerer teamkonfigurasjon like rent, bortsett fra prosjektnivå-skills i .claude/skills/, som låner samme triks.

Glob-retting er presist på en måte semantisk triggering ikke er. applyTo: "**/*.test.ts" utløses på nettopp de filene, hver gang, uten tvetydighet. En Claude-skill utløses når modellen bestemmer at beskrivelsen matcher, som er fleksibelt og av og til feil. For regler som samsvarer med filbaner, slår deterministisk smart.

Og rekkevidden er bred. Samme fil styrer live chat i editoren og de asynkrone flatene der ingen mennesker styrer: code review og coding agent. Den review-integrasjonen har spesielt ingen direkte skill-ekvivalent.

Hva skills gjør som instruksjoner ikke kan

Den strukturelle forskjellen er aktivering. En Copilot-instruksjonsfil er alltid i prompten (eller bane-matchet inn i den). En skill ligger på disk til en kostnad av omtrent 100 tokens metadata inntil en oppgave faktisk matcher beskrivelsen, deretter lastes hele innholdet. Dette er progressiv avsløring, og det endrer hva du har råd til å skrive.

En instruksjonsfil må holdes kort fordi hver linje beskatter hver forespørsel; GitHubs egen veiledning sier hold den kort, og oppblåste filer utvanner seg selv til modellen begynner å ignorere midten. Et skill-innhold kan strekke seg over tusenvis av ord, pluss referansefiler som bare lastes ved behov, fordi ingenting av det koster noe før øyeblikket det er relevant. Vår testede Test-Driven Development-skill bærer en full red-green-refactor-disiplin som ville vært absurd å injisere i hver forespørsel; som en skill aktiveres den når du bygger en funksjon og forblir stille når du spør hva et regex gjør.

Skills bundler også ting som ikke er prosa. En skill-mappe kan bære kjørbare skript, dokumentmaler, sjekklister og gjennomarbeidede eksempler; DOCX-skillen leverer kode som faktisk manipulerer Word-XML. Copilot-instruksjoner er markdown-tekst, punktum. Du kan beskrive en prosedyre; du kan ikke levere verktøyet som utfører den.

Så er det grensen som betyr mest for ikke-utviklere: Copilot-instruksjoner slutter der koden slutter. De konfigurerer en kodeassistent. Claude-skills konfigurerer Claude, som folk bruker til kontrakter, regneark, kald e-post, møtenotater og dataanalyse. En skill som Code Review Checklist overlapper med Copilot-territorium, men halve katalogen vår har ingen Copilot-ekvivalent selv i teorien. Strekker AI-bruken din seg forbi IDE-en, var instruksjonsfiler aldri ment å dekke det.

Én formatnotat: skills er portable på tvers av hver Claude-flate. Samme mappe fungerer i Claude Code, lastes opp til claude.ai, og kobles til API-forespørsler. Copilot-instruksjoner er portable på tvers av Copilot-flater, som er smalere, selv om bransjens sakte konvergens mot AGENTS.md (som Copilot nå også leser) begynner å viske ut kantene.

Hva instruksjoner gjør som skills ikke kan

Rettferdighet går begge veier, og det er tre jobber der Copilot-instruksjoner rett og slett er det bedre verktøyet.

PR-review-kontekst er den store. Copilot code review kjører på GitHubs infrastruktur mot pull requestene dine, og den leser instruksjonsfilen din når den gjør det. Skriv «flag any new endpoint that lacks a rate limit» og reviewer-en anvender det på hver PR, fra hver bidragsyter, uansett om de har konfigurert noe lokalt. Claude har ingen hostet ekvivalent som plukker opp skillsene dine automatisk på hver pull request; du må koble det opp selv gjennom CI.

Organisasjonsomfattende policy er den andre. En Copilot Enterprise-administrator kan sette instruksjoner som når hver utvikler i organisasjonen uten at noen av dem installerer noe. Claude-skills installeres per maskin eller per repo. For et plattformteam som prøver å håndheve «foreslå aldri den utgåtte auth-klienten» på tvers av 400 ingeniører, slår push-fra-toppen å håpe at alle kloner de riktige dotfilene.

Tredje, IDE-innebygd atferd. Instruksjoner former Copilot inne i editoren folk allerede lever i, uten et separat verktøy å ta i bruk. Aktiveringsspørsmålet oppstår aldri fordi det ikke finnes noen aktivering: konteksten er bare der, på hver forespørsel. For alltid-sanne fakta om en kodebase er alltid-på riktig atferd, som er samme grunn til at Claude Code har CLAUDE.md ved siden av skills. Vi laget det parallelle argumentet i Claude-skills vs Cursor-regler: hvert verktøy ender opp med å trenge både et alltid-lastet lag og et på-forespørsel-lag, og verktøyene skiller seg hovedsakelig i hvilket lag de har bygget godt.

Å konvertere mellom de to formatene

Formatene er nære nok til at migrering stort sett er omorganisering. Her er en reell-formet blokk 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 en skill får samme kunnskap en triggerbetingelse og rom til å 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).

Legg merke til hva som endret seg. Beskrivelsen bærer nå triggerfraser, delen forfattere oftest gjør feil; vage beskrivelser aktiverer aldri. Innholdet fikk negative begrensninger («flag it, do not silently rewrite it») som en alltid-på-fil ikke har råd til tokens for. Og siste linje peker til en referansefil som bare lastes når retries kommer opp.

Motsatt retning er en komprimeringsøvelse. Ta et skill-innhold, behold reglene som gjelder for hver forespørsel i mål-banene, kutt prosedyrene og edge-casene, og legg resultatet i en skopet 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.

Hva du mister ved å gå denne veien: den betingede lastingen og det bundlede referansematerialet. Hva du får: reglene styrer nå også Copilot code review på hver PR som rører src/services/. Ingen av byttene er feil. De er forskjellige plasseringer av samme kunnskap.

Å kjøre Claude Code og Copilot side om side

Mange team velger aldri, og arbeidsdelingen som oppstår er konsekvent nok til å beskrive.

Copilot håndterer laget i editoren pluss PR-review, konfigurert av instruksjonsfiler som beskriver kodebasen. Claude Code håndterer økt-laget: funksjoner over flere filer, refaktoreringer, feilsøkingsundersøkelser, og det omkringliggende arbeidet som changelogs og migreringsdokumenter, konfigurert av CLAUDE.md for repo-fakta og skills for evner. Overlappet er mindre enn det ser ut som, fordi verktøyene ligger på forskjellige høyder. Autofullføring vil ha korte alltid-sanne regler; en agent som kjører en 40-minutters oppgave vil ha prosedyrer.

Det praktiske oppsettet vi ser fungere: hold .github/copilot-instructions.md og CLAUDE.md som søsken som sier det samme på hvert verktøys dialekt (noen team genererer begge fra én kildefil), bruk applyTo-globs for bane-skopede kodregler, og bruk skills for alt prosedyremessig. En Git Workflow-skill som kjører din branching- og commit-disiplin har ingen nyttig uttrykk som Copilot-instruksjon, og en «vi bruker pnpm, ikke npm»-regel har ingenting å gjøre som en skill. Bygger du Claude-siden av dette fra bunnen, er vår beste kodeskills-rangering sortert etter testet poengsum.

Grensen er heller ikke fast. Team som starter med Copilot til fullføringer, gir gjerne mer av det agentiske arbeidet til Claude Code over tid, ikke fordi instruksjoner feiler, men fordi et økt-verktøy med skills lønner seg mer på lange oppgaver. Det motsatte skjer også: team dypt inne i Claude Code beholder Copilot likevel fordi PR-review-integrasjonen er så praktisk. Behandle delingen som en standard, ikke en doktrine.

En advarsel fra vår testing: duplisering driver. Når Copilot-filen sier tjenester aldri kaster, og skillen sier tjenester kan kaste i adapterlaget, får du to assistenter som selvsikkert håndhever forskjellige regler. Den som eier konvensjonen bør eie begge filene i samme PR.

Ingen tester instruksjonsfiler heller

Her er den ubehagelige symmetrien. Vi bygde SkillProof fordi omtrent halvparten av community Claude-skillsene vi installerer feiler ved første forsøk, et mønster vi dokumenterte i hvorfor halvparten av Claude-skills ikke fungerer. De to dominerende feilmodusene er installasjoner som ikke fungerer etter README-ens egne instruksjoner, og beskrivelser for vage til noensinne å utløse.

Copilot-instruksjoner har samme sykdom med andre symptomer. Awesome-copilot-listene og instruksjonsfil-samlingene som sprer seg på GitHub, er samme utestede markdown: filer kopiert fra et blogginnlegg inn i .github/, aldri verifisert mot faktisk modellatferd. Feilmodusene kartlegger nesten én til én. En vag skill-beskrivelse betyr at skillen aldri utløses; en oppblåst instruksjonsfil betyr at reglene utvannes til modellen ignorerer dem. Et skill-innhold som gjentar standard modellatferd, tilfører ingenting; en instruksjonsfil full av «skriv ren, veldokumentert kode» tilfører ingenting. I begge økosystemer forveksles filens eksistens med filens funksjon.

Forskjellen er at instruksjonsfil-feil er stillere. En skill som aldri utløses er i det minste merkbart inaktiv. En instruksjonsfil er alltid teknisk «anvendt», så team antar at den virker, og ingen kjører med-og-uten-sammenligningen som ville vist om den endrer noe som helst. Den sammenligningen er nettopp vårt output-kriterium for skills, og det er testen vi ville foreslått for din Copilot-fil også: ta tre reelle oppgaver, kjør dem med instruksjonsfilen til stede og fraværende, og diff resultatene. Kan du ikke se forskjell, har du betalt tokens for en placebo.

Ofte stilte spørsmål

Kan GitHub Copilot bruke Claude-skills?

Nei. Skills er et Claude-side-format lest av Claude Code, claude.ai og API-et. Copilot kan ikke laste en SKILL.md, selv om Copilot tilbyr Claude-modeller som backend; modellen er utskiftbar, konfigurasjonslaget er ikke det. Kunnskapen i en skill konverterer vanligvis til en instruksjonsfil, minus den betingede lastingen og eventuelle bundlede skript.

Fungerer Claude-skills med repo-instruksjoner som copilot-instructions.md?

De sameksisterer uten konflikt fordi hvert verktøy bare leser sine egne filer. Claude Code ignorerer .github/copilot-instructions.md, og Copilot ignorerer .claude/skills/. Risikoen er ikke en kollisjon, det er drift: to filer som koder samme konvensjon vil etter hvert være uenige med mindre de vedlikeholdes sammen.

Hva er best for å håndheve teamets kodestandarder?

For regler som samsvarer med filbaner og må nå hver bidragsyter, Copilot-instruksjoner med applyTo-globs, fordi de også gjelder for Copilot code review på PR-er. For prosedyremessige standarder, som hvordan man kjører en migrering, skills, fordi de kan holde lange prosedyrer og bare laste dem når relevant. De fleste standarddokumenter inneholder begge typer og vil ha en splittelse deretter.

Er Copilot-instruksjoner billigere på tokens enn skills?

Vanligvis motsatt. En gjeldende instruksjonsfil kobles på hver forespørsel, så en 1500-tokens fil koster 1500 tokens per interaksjon uansett om den er relevant. En skill koster rundt 100 tokens i ro og laster innholdet bare ved en match. Alltid-på er verdt å betale for når reglene virkelig gjelder for hver forespørsel, som er hvorfor korte instruksjonsfiler slår lange.

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

Splitt den fremfor å konvertere den. De alltid-sanne faktaene om repoet, byggekommandoer og konvensjoner, hører hjemme i CLAUDE.md, som er den nærmeste analogen. De prosedyremessige delene, alt som leses som «når du gjør X, følg disse trinnene», hører hjemme i skills så de lastes på forespørsel. En direkte konvertering gir vanligvis enten en oppblåst CLAUDE.md eller skills som utløses på alt.