Claude skills vs Copilot instructions vergeleken

GitHub Copilot heeft meer gebruikers dan enige andere AI-codeertool, dus zijn aanpassingsformaat is waarschijnlijk het meest verspreide stukje AI-configuratie dat bestaat. Miljoenen repo's dragen nu een .github/copilot-instructions.md. Claude skills kwamen later, verspreidden zich snel, en lossen een overlappend probleem op een andere manier op. Als je beide tools gebruikt, of je beslist welke de configuratie-inspanning van je team verdient, doen de verschillen er meer toe dan de marketing suggereert.

We draaien SkillProof, waar we Claude skills installeren op schone machines en ze testen tegen echt werk voordat we ze vermelden, dus onze bias zit aan de skills-kant en we zeggen dat vooraf. We hebben ook honderden instructiebestanden in beide formaten zien slagen en falen, en de faalpatronen blijken bijna identiek. Deze vergelijking probeert eerlijk te zijn voor beide.

TL;DR

Copilot custom instructions zijn altijd-aan context voor code. Claude skills zijn expertise op aanvraag voor elke taak. Instructions winnen op teamdistributie en IDE-integratie; skills winnen op activatielogica, gebundelde bronnen, en alles wat geen code is.

	Claude skills	Copilot custom instructions
Mechanisme	SKILL.md met een beschrijvingsveld; Claude laadt de body wanneer een taak matcht	.github/copilot-instructions.md toegepast op de hele repo, plus *.instructions.md-bestanden geschaald door applyTo-globs
Activatie	Semantisch: het model matcht je verzoek tegen de beschrijving	Altijd aan (repo-bestand) of bestandspad-match (globs)
Bereik	Elke taak die Claude aankan: code, documenten, e-mail, analyse	Code en Copilot-oppervlakken: chat, code review, coding agent
Portabiliteit	Eén formaat over Claude Code, claude.ai, desktop, API	Gebonden aan Copilot; gedeeltelijke ondersteuning varieert per IDE en oppervlak
Gebundelde bronnen	Scripts, templates, referentiebestanden, lui geladen	Alleen markdown-tekst
Tokengedrag	~100 tokens stationair per skill; volledige body laadt bij trigger	Volledig toepasselijk bestand koppelt aan elk verzoek
Ecosysteem	Duizenden community-skills, grotendeels ongetest	Grotendeels privé per-repo-bestanden; awesome-lists in opkomst, ook ongetest

Als je maar één regel onthoudt: instructions beschrijven je codebase, skills beschrijven een capaciteit. Dat zijn verschillende taken, en de meeste teams willen uiteindelijk beide. Voor grounding aan de skills-kant behandelt onze complete gids voor Claude skills het formaat diepgaand. Beide formaten veranderen hoe een model zich gedraagt; een model verbinden met externe data is een andere as, behandeld in Claude skills vs MCP-servers.

Wat Copilot custom instructions eigenlijk zijn

De kern van het systeem is één bestand: .github/copilot-instructions.md, gecommit naar de repository. Copilot Chat leest het automatisch en zet het voor verzoeken in die repo, over VS Code, Visual Studio, JetBrains IDE's en github.com. De coding agent leest het wanneer hij aan issues werkt; Copilot code review leest het bij het reviewen van pull requests. Eén markdown-bestand, en elk Copilot-oppervlak dat de repo aanraakt gedraagt zich ernaar.

In 2025 breidde GitHub het formaat uit met geschaalde instructiebestanden: .github/instructions/*.instructions.md, elk met frontmatter die bestandspaden target.

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

De glob doet wat hij zegt. Bewerk een bestand onder src/api/, en deze instructies rijden mee met het verzoek. Bewerk een README, en dat doen ze niet. Er zijn ook persoonlijke instructies, ingesteld in je github.com Copilot-instellingen, en organisatie-instructies, die Business- en Enterprise-beheerders naar elk lid kunnen pushen.

De sterke punten hier verdienen een eerlijke blik, want ze zijn echt.

Instructions zijn repo-native. Het bestand leeft waar de code leeft, en wijzigingen doorlopen pull request-review zoals al het andere. Wanneer iemand de foutafhandelingsconventie bijwerkt, is de diff zichtbaar en krijgt het hele team het bij de pull. Niets in het Claude-ecosysteem distribueert teamconfiguratie zo schoon, behalve project-level skills in .claude/skills/, die dezelfde truc lenen.

Glob-targeting is precies op een manier die semantische triggering niet is. applyTo: "**/*.test.ts" vuurt exact op die bestanden, elke keer, zonder ambiguïteit. Een Claude skill triggert wanneer het model beslist dat de beschrijving matcht, wat flexibel is en af en toe fout. Voor regels die op bestandspaden mappen, verslaat deterministisch slim.

En het bereik is breed. Hetzelfde bestand stuurt live chat in de editor en de asynchrone oppervlakken waar geen mens stuurt: code review en de coding agent. Die review-integratie in het bijzonder heeft geen directe skills-tegenhanger.

Wat skills doen dat instructions niet kunnen

Het structurele verschil is activatie. Een Copilot instructions-bestand staat altijd in de prompt (of wordt path-matched erin). Een skill ligt op schijf tegen een kost van ruwweg 100 tokens metadata tot een taak daadwerkelijk zijn beschrijving matcht, dan laadt de volledige body. Dit is progressive disclosure, en het verandert wat je je kunt veroorloven te schrijven.

Een instructions-bestand moet kort blijven omdat elke regel elk verzoek belast; GitHub's eigen richtlijn zegt houd het kort, en opgeblazen bestanden verdunnen zichzelf tot het model het midden begint te negeren. Een skill-body kan duizenden woorden lang zijn, plus referentiebestanden die alleen laden wanneer nodig, omdat niets ervan iets kost tot het moment dat het relevant is. Onze geteste Test-Driven Development-skill draagt een volledige rood-groen-refactor-discipline die absurd zou zijn om in elk verzoek te injecteren; als skill activeert het wanneer je een feature bouwt en blijft het stil wanneer je vraagt wat een regex doet.

Skills bundelen ook dingen die geen proza zijn. Een skill-map kan uitvoerbare scripts, documenttemplates, checklists en uitgewerkte voorbeelden dragen; de DOCX-skill bevat code die daadwerkelijk Word-XML manipuleert. Copilot instructions zijn markdown-tekst, punt uit. Je kunt een procedure beschrijven; je kunt niet de tool leveren die het uitvoert.

Dan is er de grens die het meest telt voor niet-developers: Copilot instructions eindigen waar code eindigt. Ze configureren een codeer-assistent. Claude skills configureren Claude, dat mensen gebruiken voor contracten, spreadsheets, koude e-mail, vergadernotities en data-analyse. Een skill zoals Code Review Checklist overlapt met Copilot-terrein, maar de helft van onze catalogus heeft zelfs in theorie geen Copilot-equivalent. Als je AI-gebruik verder gaat dan de IDE, gingen instructions-bestanden dat nooit dekken.

Eén formaatnotitie: skills zijn portabel over elk Claude-oppervlak. Dezelfde map werkt in Claude Code, upload naar claude.ai, en koppelt aan API-verzoeken. Copilot instructions zijn portabel over Copilot-oppervlakken, wat smaller is, hoewel de langzame convergentie van de industrie op AGENTS.md (dat Copilot nu ook leest) de randen begint te vervagen.

Wat instructions doen dat skills niet kunnen

Eerlijkheid werkt beide kanten op, en er zijn drie taken waar Copilot instructions gewoon de betere tool zijn.

PR-review-context is de grote. Copilot code review draait op GitHub's infrastructuur tegen je pull requests, en het leest je instructions-bestand daarbij. Schrijf "markeer elk nieuw endpoint dat geen rate limit heeft" en de reviewer past het toe op elke PR, van elke bijdrager, of ze nu iets lokaal geconfigureerd hebben of niet. Claude heeft geen gehoste tegenhanger die automatisch je skills oppikt bij elke pull request; je zou het zelf bedraden via CI.

Organisatiebreed beleid is de tweede. Een Copilot Enterprise-beheerder kan instructions instellen die elke developer in de organisatie bereiken zonder dat iemand van hen iets installeert. Claude skills installeren per machine of per repo. Voor een platformteam dat probeert "stel nooit de verouderde auth-client voor" af te dwingen bij 400 engineers, verslaat push-van-bovenaf hopen dat iedereen de juiste dotfiles kloont.

Ten derde, IDE-native gedrag. Instructions vormen Copilot binnen de editor waar mensen al leven, zonder aparte tool om over te nemen. De activatievraag komt nooit op, want er is geen activatie: de context is er gewoon, bij elk verzoek. Voor altijd-ware feiten over een codebase is altijd-aan correct gedrag, wat dezelfde reden is waarom Claude Code CLAUDE.md naast skills heeft. We maakten het parallelle argument in Claude skills vs Cursor rules: elke tool heeft uiteindelijk zowel een altijd-geladen laag als een on-demand laag nodig, en de tools verschillen vooral in welke laag ze goed gebouwd hebben.

Converteren tussen de twee formaten

De formaten liggen dicht genoeg bij elkaar dat migratie vooral reorganisatie is. Hier is een echt-vormig blok uit een 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.

Als skill krijgt dezelfde kennis een triggervoorwaarde en ruimte om te groeien:

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

Merk op wat er veranderde. De beschrijving draagt nu triggerzinnen, het deel dat auteurs het vaakst verkeerd doen; vage beschrijvingen vuren nooit. De body kreeg negatieve constraints ("markeer het, herschrijf het niet stilletjes") waar een altijd-aan bestand de tokens niet voor kan betalen. En de laatste regel wijst naar een referentiebestand dat alleen laadt wanneer retries ter sprake komen.

De omgekeerde richting is een compressie-oefening. Neem een skill-body, behoud de regels die op elk verzoek in de doelpaden van toepassing zijn, snoei de procedures en de randgevallen, en zet het resultaat in een geschaald bestand:

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

Wat je op deze manier verliest: het voorwaardelijk laden en het gebundelde referentiemateriaal. Wat je wint: de regels gelden nu ook voor Copilot code review op elke PR die src/services/ aanraakt. Geen van beide ruilen is fout. Het zijn verschillende plaatsingen van dezelfde kennis.

Claude Code en Copilot naast elkaar draaien

Genoeg teams kiezen nooit, en de taakverdeling die ontstaat is consistent genoeg om te beschrijven.

Copilot behandelt de in-editor-laag plus PR-review, geconfigureerd door instructions-bestanden die de codebase beschrijven. Claude Code behandelt de sessielaag: multi-bestand features, refactors, debug-onderzoeken, en het omliggende werk zoals changelogs en migratiedocs, geconfigureerd door CLAUDE.md voor repo-feiten en skills voor capaciteiten. De overlap is kleiner dan het lijkt, omdat de tools op verschillende hoogtes zitten. Autocomplete wil beknopte altijd-ware regels; een agent die een taak van 40 minuten draait wil procedures.

De praktische setup die we zien werken: houd .github/copilot-instructions.md en CLAUDE.md als zussen die hetzelfde zeggen in het dialect van elke tool (sommige teams genereren beide uit één bronbestand), gebruik applyTo-globs voor pad-geschaalde coderegels, en gebruik skills voor alles procedureels. Een Git Workflow-skill die je branching- en commitdiscipline draait, heeft geen zinvolle uitdrukking als Copilot instructions, en een "we gebruiken pnpm, geen npm"-regel heeft niets te zoeken als skill. Als je de Claude-kant van dit vanaf nul bouwt, is onze beste coding-skills-ranglijst gesorteerd op geteste score.

De grens ligt ook niet vast. Teams die beginnen met Copilot voor aanvullingen geven na verloop van tijd meer van het agentische werk aan Claude Code, niet omdat instructions falen, maar omdat een sessietool met skills meer oplevert bij lange taken. Het omgekeerde gebeurt ook: teams diep in Claude Code houden Copilot toch aan omdat de PR-review-integratie zo handig is. Behandel de splitsing als een standaard, geen doctrine.

Eén waarschuwing uit ons testwerk: duplicatie drijft uit elkaar. Wanneer het Copilot-bestand zegt dat services nooit gooien en de skill zegt dat services mogen gooien in de adapterlaag, krijg je twee assistenten die vol vertrouwen verschillende regels afdwingen. Wie de conventie bezit, moet beide bestanden bezitten in dezelfde PR.

Niemand test instructions-bestanden ook

Hier is de ongemakkelijke symmetrie. We bouwden SkillProof omdat ruwweg de helft van de community Claude skills die we installeren bij de eerste poging falen, een patroon dat we documenteerden in waarom de helft van de Claude skills niet werkt. De twee dominante faalmodi zijn installs die niet werken volgens de eigen instructies van de README en beschrijvingen te vaag om ooit te triggeren.

Copilot instructions hebben dezelfde ziekte met andere symptomen. De awesome-copilot-lijsten en instructiebestand-collecties die zich verspreiden op GitHub zijn dezelfde ongeteste markdown: bestanden gekopieerd uit een blogpost naar .github/, nooit geverifieerd tegen echt modelgedrag. De faalmodi mappen bijna één op één. Een vage skill-beschrijving betekent dat de skill nooit vuurt; een opgeblazen instructions-bestand betekent dat de regels verwateren tot het model ze negeert. Een skill-body die standaardgedrag van het model herhaalt voegt niets toe; een instructions-bestand vol "schrijf schone, goed gedocumenteerde code" voegt niets toe. In beide ecosystemen wordt het bestaan van het bestand verward met de functie van het bestand.

Het verschil is dat falen van instructiebestanden stiller is. Een skill die nooit triggert is tenminste detecteerbaar inert. Een instructions-bestand is altijd technisch "toegepast", dus teams gaan ervan uit dat het werkt, en niemand draait de met-en-zonder-vergelijking die zou laten zien of het de output überhaupt verandert. Die vergelijking is precies ons outputcriterium voor skills, en het is de test die we ook voor je Copilot-bestand zouden suggereren: neem drie echte taken, draai ze met en zonder het instructions-bestand, en diff de resultaten. Als je niet kunt zien welke welke is, heb je tokens betaald voor een placebo.

FAQ

Kan GitHub Copilot Claude skills gebruiken?

Nee. Skills zijn een Claude-side formaat gelezen door Claude Code, claude.ai, en de API. Copilot kan geen SKILL.md laden, ook al biedt Copilot Claude-modellen als backend aan; het model is verwisselbaar, de configuratielaag niet. De kennis in een skill zet meestal om naar een instructions-bestand, min het voorwaardelijk laden en eventuele gebundelde scripts.

Werken Claude skills samen met repository-instructions zoals copilot-instructions.md?

Ze bestaan naast elkaar zonder conflict omdat elke tool alleen zijn eigen bestanden leest. Claude Code negeert .github/copilot-instructions.md, en Copilot negeert .claude/skills/. Het risico is geen botsing, het is drift: twee bestanden die dezelfde conventie coderen zullen het uiteindelijk oneens worden tenzij ze samen onderhouden worden.

Wat is beter voor het afdwingen van teamcoderichtlijnen?

Voor regels die op bestandspaden mappen en elke bijdrager moeten bereiken: Copilot instructions met applyTo-globs, omdat ze ook gelden voor Copilot code review op PR's. Voor procedurele standaarden, zoals hoe een migratie te draaien: skills, omdat ze lange procedures kunnen bevatten en ze alleen laden wanneer relevant. De meeste standaarddocumenten bevatten beide soorten en willen dienovereenkomstig gesplitst worden.

Zijn Copilot instructions goedkoper op tokens dan skills?

Meestal het tegenovergestelde. Een toepasselijk instructions-bestand koppelt aan elk verzoek, dus een bestand van 1.500 tokens kost 1.500 tokens per interactie, of het nu relevant is of niet. Een skill kost ongeveer 100 tokens stationair en laadt zijn body alleen bij een match. Altijd-aan is de moeite waard wanneer de regels echt voor elk verzoek gelden, wat waarom korte instructions-bestanden lange verslaan.

Moet ik mijn copilot-instructions.md omzetten naar skills als ik overstap naar Claude Code?

Splits het in plaats van het te converteren. De altijd-ware feiten over de repo, zijn buildcommando's en conventies, horen in CLAUDE.md, wat de dichtstbijzijnde analoog is. De procedurele secties, alles dat leest als "bij het doen van X, volg deze stappen", horen in skills zodat ze op aanvraag laden. Een directe conversie produceert meestal ofwel een opgeblazen CLAUDE.md of skills die op alles triggeren.