Claude Skills vs. Copilot Instructions im Vergleich

GitHub Copilot hat mehr Nutzer als jedes andere KI-Coding-Tool, sein Anpassungsformat ist also wahrscheinlich das am weitesten verbreitete Stück KI-Konfiguration überhaupt. Millionen Repos tragen inzwischen eine .github/copilot-instructions.md. Claude Skills kamen später, verbreiteten sich schnell und lösen ein überlappendes Problem auf andere Weise. Wenn du beide Tools nutzt oder entscheidest, welches die Konfigurationsarbeit deines Teams verdient, zählen die Unterschiede mehr, als die Werbung nahelegt.

Wir betreiben SkillProof, wo wir Claude Skills auf sauberen Maschinen installieren und gegen echte Arbeit testen, bevor wir sie listen, unsere Neigung liegt also auf der Skill-Seite, und wir sagen das gleich vorweg. Wir haben auch Hunderte Anweisungsdateien in beiden Formaten scheitern und gelingen sehen, und die Fehlermuster sind fast identisch. Dieser Vergleich versucht, beiden gerecht zu werden.

Kurzfassung

Copilots eigene Anweisungen sind always-on Kontext für Code. Claude Skills sind bedarfsweise abrufbares Fachwissen für jede Aufgabe. Anweisungen gewinnen bei Teamverteilung und IDE-Integration; Skills gewinnen bei Aktivierungslogik, zusätzlichen Ressourcen und allem, was nicht Code ist.

	Claude Skills	Copilot Custom Instructions
Mechanismus	SKILL.md mit einem Beschreibungsfeld; Claude lädt den Body, wenn eine Aufgabe passt	.github/copilot-instructions.md, repoweit angewendet, plus *.instructions.md-Dateien, gescopt per applyTo-Globs
Aktivierung	Semantisch: das Modell gleicht deine Anfrage mit der Beschreibung ab	Immer aktiv (Repo-Datei) oder Dateipfad-Abgleich (Globs)
Umfang	Jede Aufgabe, die Claude übernimmt: Code, Dokumente, E-Mail, Analyse	Code und Copilot-Oberflächen: Chat, Code Review, Coding Agent
Portabilität	Ein Format über Claude Code, claude.ai, Desktop, API	An Copilot gebunden; teilweise Unterstützung variiert je nach IDE und Oberfläche
Zusätzliche Ressourcen	Skripte, Templates, Referenzdateien, bedarfsweise geladen	Nur Markdown-Text
Token-Verhalten	~100 Tokens Leerlauf pro Skill; voller Body lädt bei Trigger	Die jeweils zutreffende Datei hängt an jedem Request
Ökosystem	Tausende Community-Skills, größtenteils ungetestet	Meist private Pro-Repo-Dateien; Awesome-Listen entstehen, ebenfalls ungetestet

Wenn du dir nur eine Zeile merkst: Instructions beschreiben deine Codebasis, Skills beschreiben eine Fähigkeit. Das sind unterschiedliche Jobs, und die meisten Teams wollen irgendwann beides. Für den Skill-Hintergrund deckt unser vollständiger Guide zu Claude Skills das Format ausführlich ab. Beide Formate verändern, wie sich ein Modell verhält; ein Modell an externe Daten anzubinden ist eine andere Achse, behandelt in Claude Skills vs. MCP-Server.

Was Copilot Custom Instructions eigentlich sind

Der Kern des Systems ist eine Datei: .github/copilot-instructions.md, ins Repository eingecheckt. Copilot Chat liest sie automatisch und stellt sie Anfragen in diesem Repo voran, über VS Code, Visual Studio, JetBrains-IDEs und github.com hinweg. Der Coding Agent liest sie, wenn er an Issues arbeitet; Copilot Code Review liest sie beim Review von Pull Requests. Eine Markdown-Datei, und jede Copilot-Oberfläche, die das Repo berührt, verhält sich entsprechend.

2025 erweiterte GitHub das Format um gescopte Instruction-Dateien: .github/instructions/*.instructions.md, jede mit Frontmatter, das auf Dateipfade zielt.

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

Der Glob tut, was er sagt. Bearbeitest du eine Datei unter src/api/, fahren diese Anweisungen bei der Anfrage mit. Bearbeitest du eine README, tun sie es nicht. Es gibt außerdem persönliche Instructions, gesetzt in deinen github.com-Copilot-Einstellungen, und Organisations-Instructions, die Business- und Enterprise-Admins an jedes Mitglied ausrollen können.

Die Stärken hier verdienen eine faire Würdigung, weil sie echt sind.

Instructions sind repo-nativ. Die Datei lebt dort, wo der Code lebt, und Änderungen durchlaufen Pull-Request-Review wie alles andere. Wenn jemand die Fehlerbehandlungs-Konvention aktualisiert, ist der Diff sichtbar, und das ganze Team bekommt sie beim Pull. Nichts im Claude-Ökosystem verteilt Teamkonfiguration so sauber, außer Projekt-Skills in .claude/skills/, die sich denselben Trick abschauen.

Glob-Targeting ist präzise auf eine Art, wie es semantisches Triggern nicht ist. applyTo: "**/*.test.ts" feuert genau bei diesen Dateien, jedes Mal, ohne jede Mehrdeutigkeit. Ein Claude Skill triggert, wenn das Modell entscheidet, dass die Beschreibung passt, was flexibel und gelegentlich falsch ist. Für Regeln, die sich auf Dateipfade abbilden, schlägt deterministisch clever.

Und die Reichweite ist breit. Dieselbe Datei steuert Live-Chat im Editor und die asynchronen Oberflächen, wo kein Mensch steuert: Code Review und der Coding Agent. Diese Review-Integration insbesondere hat kein direktes Skill-Äquivalent.

Was Skills können, was Instructions nicht können

Der strukturelle Unterschied ist die Aktivierung. Eine Copilot-Instructions-Datei steckt immer im Prompt (oder wird per Pfad hineingematcht). Ein Skill liegt auf der Platte zu Kosten von etwa 100 Tokens Metadaten, bis eine Aufgabe tatsächlich zu seiner Beschreibung passt, dann lädt der volle Body. Das ist Progressive Disclosure, und es verändert, was du dir zu schreiben leisten kannst.

Eine Instructions-Datei muss kurz bleiben, weil jede Zeile jeden Request belastet; GitHubs eigene Leitlinie sagt, sie kurz zu halten, und aufgeblähte Dateien verwässern sich selbst, bis das Modell die Mitte ignoriert. Ein Skill-Body kann sich über Tausende Wörter erstrecken, plus Referenzdateien, die nur bei Bedarf laden, weil nichts davon kostet, bis es tatsächlich relevant ist. Unser getesteter Test-Driven-Development-Skill trägt eine vollständige Red-Green-Refactor-Disziplin, die absurd wäre, in jeden Request zu injizieren; als Skill aktiviert er, wenn du ein Feature baust, und bleibt still, wenn du fragst, was ein Regex tut.

Skills bringen auch Dinge mit, die keine Prosa sind. Ein Skill-Ordner kann ausführbare Skripte, Dokumentvorlagen, Checklisten und durchgearbeitete Beispiele tragen; der DOCX-Skill bringt Code mit, der tatsächlich Word-XML manipuliert. Copilot Instructions sind Markdown-Text, Punkt. Du kannst ein Verfahren beschreiben; du kannst nicht das Werkzeug mitliefern, das es ausführt.

Dann ist da die Grenze, die für Nicht-Entwickler am meisten zählt: Copilot Instructions enden, wo Code endet. Sie konfigurieren einen Coding-Assistenten. Claude Skills konfigurieren Claude, das Leute für Verträge, Tabellen, Kaltakquise-E-Mails, Meeting-Notizen und Datenanalyse nutzen. Ein Skill wie Code Review Checklist überschneidet sich mit Copilot-Terrain, aber die halbe Katalog hat kein Copilot-Äquivalent, nicht einmal theoretisch. Wenn deine KI-Nutzung über die IDE hinausgeht, war Instructions-Dateien nie dafür gedacht, das abzudecken.

Eine Formatnotiz: Skills sind über jede Claude-Oberfläche portabel. Derselbe Ordner funktioniert in Claude Code, lädt auf claude.ai hoch und hängt an API-Requests an. Copilot Instructions sind über Copilot-Oberflächen portabel, was enger ist, wenngleich die langsame Branchen-Konvergenz auf AGENTS.md (das Copilot jetzt auch liest) beginnt, die Grenzen zu verwischen.

Was Instructions können, was Skills nicht können

Fairness geht in beide Richtungen, und es gibt drei Jobs, bei denen Copilot Instructions schlicht das bessere Werkzeug sind.

PR-Review-Kontext ist der große Punkt. Copilot Code Review läuft auf GitHubs Infrastruktur gegen deine Pull Requests, und es liest deine Instructions-Datei dabei. Schreib "markiere jeden neuen Endpoint ohne Rate-Limit" und der Reviewer wendet das auf jeden PR an, von jedem Mitwirkenden, ob der etwas konfiguriert hat oder nicht. Claude hat kein gehostetes Äquivalent, das deine Skills automatisch bei jedem Pull Request aufgreift; das müsstest du selbst über CI verdrahten.

Organisationsweite Policy ist der zweite Punkt. Ein Copilot-Enterprise-Admin kann Instructions setzen, die jeden Entwickler in der Organisation erreichen, ohne dass jemand von ihnen etwas installiert. Claude Skills installieren pro Maschine oder pro Repo. Für ein Plattformteam, das "schlage niemals den veralteten Auth-Client vor" bei 400 Ingenieuren durchsetzen will, schlägt Push-von-oben das Hoffen, dass alle die richtigen Dotfiles klonen.

Drittens IDE-natives Verhalten. Instructions formen Copilot innerhalb des Editors, in dem die Leute schon leben, ohne separates Tool zur Einführung. Die Aktivierungsfrage stellt sich nie, weil es keine Aktivierung gibt: Der Kontext ist einfach da, bei jedem Request. Für immer-wahre Fakten über eine Codebasis ist always-on das richtige Verhalten, aus demselben Grund, aus dem Claude Code neben Skills auch CLAUDE.md hat. Wir haben das parallele Argument in Claude Skills vs. Cursor Rules gebracht: Jedes Tool braucht am Ende sowohl eine immer geladene Schicht als auch eine bedarfsweise Schicht, und die Tools unterscheiden sich vor allem darin, welche Schicht sie gut gebaut haben.

Umwandlung zwischen beiden Formaten

Die Formate sind nah genug beieinander, dass Migration größtenteils Umorganisation ist. Hier ein realitätsnaher Block aus einer 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 gewinnt dasselbe Wissen eine Trigger-Bedingung und Raum zum Wachsen:

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

Beachte, was sich geändert hat. Die Beschreibung trägt jetzt Trigger-Formulierungen, der Teil, den Autoren am häufigsten falsch machen; vage Beschreibungen feuern nie. Der Body hat Negativ-Bedingungen aufgenommen ("flag it, do not silently rewrite it"), für die sich eine always-on-Datei die Tokens nicht leisten kann. Und die letzte Zeile verweist auf eine Referenzdatei, die nur lädt, wenn Retries zur Sprache kommen.

Die umgekehrte Richtung ist eine Kompressionsübung. Nimm einen Skill-Body, behalte die Regeln, die für jeden Request in den Ziel-Pfaden gelten, streich die Prozeduren und Sonderfälle und lege das Ergebnis in eine gescopte Datei:

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

Was du auf diesem Weg verlierst: das bedingte Laden und das zusätzliche Referenzmaterial. Was du gewinnst: Die Regeln steuern jetzt auch Copilot Code Review bei jedem PR, der src/services/ berührt. Kein Tausch ist falsch. Es sind unterschiedliche Ablageorte desselben Wissens.

Claude Code und Copilot nebeneinander betreiben

Viele Teams entscheiden sich nie, und die Arbeitsteilung, die entsteht, ist konsistent genug, um sie zu beschreiben.

Copilot übernimmt die In-Editor-Schicht plus PR-Review, konfiguriert durch Instructions-Dateien, die die Codebasis beschreiben. Claude Code übernimmt die Session-Schicht: mehrteilige Features, Refactorings, Debugging-Untersuchungen und begleitende Arbeit wie Changelogs und Migrationsdokumente, konfiguriert durch CLAUDE.md für Repo-Fakten und Skills für Fähigkeiten. Die Überlappung ist kleiner, als sie aussieht, weil die Tools auf unterschiedlichen Höhen sitzen. Autovervollständigung will knappe, immer-wahre Regeln; ein Agent, der eine 40-minütige Aufgabe durchläuft, will Prozeduren.

Das praktische Setup, das wir funktionieren sehen: .github/copilot-instructions.md und CLAUDE.md als Geschwister behandeln, die im jeweiligen Dialekt des Tools dasselbe sagen (manche Teams generieren beide aus einer Quelldatei), applyTo-Globs für pfadgescopte Coderegeln nutzen und Skills für alles Prozedurale. Ein Git-Workflow-Skill, der deine Branching- und Commit-Disziplin durchführt, hat keinen sinnvollen Ausdruck als Copilot-Instruction, und eine "wir nutzen pnpm, nicht npm"-Regel hat nichts als Skill verloren. Wenn du die Claude-Seite davon von Grund auf aufbaust, ist unser Ranking der besten Coding-Skills nach getestetem Score sortiert.

Auch die Grenze ist nicht fix. Teams, die mit Copilot für Vervollständigungen starten, geben mit der Zeit tendenziell mehr agentische Arbeit an Claude Code ab, nicht weil Instructions versagen, sondern weil ein Session-Tool mit Skills sich bei langen Aufgaben mehr auszahlt. Das Umgekehrte passiert auch: Teams tief in Claude Code behalten Copilot trotzdem, weil die PR-Review-Integration so praktisch ist. Behandle die Aufteilung als Standard, nicht als Doktrin.

Eine Warnung aus unseren Tests: Duplikation driftet. Wenn die Copilot-Datei sagt, Services werfen nie, und der Skill sagt, Services dürfen in der Adapter-Schicht werfen, hast du zwei Assistenten, die selbstbewusst unterschiedliche Regeln durchsetzen. Wer die Konvention besitzt, sollte beide Dateien im selben PR besitzen.

Niemand testet auch Instructions-Dateien

Hier ist die unangenehme Symmetrie. Wir haben SkillProof gebaut, weil etwa die Hälfte der Community-Claude-Skills, die wir installieren, beim ersten Versuch scheitert, ein Muster, das wir in warum die Hälfte der Claude Skills nicht funktioniert dokumentiert haben. Die zwei dominanten Fehlermodi sind Installationen, die nicht nach den eigenen Anweisungen der README funktionieren, und Beschreibungen, die zu vage sind, um je zu triggern.

Copilot Instructions haben dieselbe Krankheit mit anderen Symptomen. Die awesome-copilot-Listen und Instructions-Datei-Sammlungen, die sich auf GitHub verbreiten, sind dasselbe ungetestete Markdown: Dateien, kopiert aus einem Blogpost in .github/, nie gegen echtes Modellverhalten verifiziert. Die Fehlermodi bilden sich fast eins zu eins ab. Eine vage Skill-Beschreibung bedeutet, der Skill feuert nie; eine aufgeblähte Instructions-Datei bedeutet, die Regeln werden verwässert, bis das Modell sie ignoriert. Ein Skill-Body, der Standard-Modellverhalten wiederholt, bringt nichts; eine Instructions-Datei voller "schreibe sauberen, gut dokumentierten Code" bringt nichts. In beiden Ökosystemen wird die Existenz der Datei mit ihrer Funktion verwechselt.

Der Unterschied ist, dass Instructions-Datei-Versagen leiser ist. Ein Skill, der nie triggert, ist wenigstens erkennbar untätig. Eine Instructions-Datei ist immer technisch "angewendet", also nimmt das Team an, sie funktioniere, und niemand macht den Mit-und-ohne-Vergleich, der zeigen würde, ob sie den Output überhaupt verändert. Genau dieser Vergleich ist unser Output-Kriterium für Skills, und es ist der Test, den wir auch für deine Copilot-Datei vorschlagen würden: Nimm drei echte Aufgaben, führe sie mit und ohne die Instructions-Datei aus und vergleiche die Ergebnisse. Kannst du nicht sagen, welches welches ist, hast du für ein Placebo bezahlt.

FAQ

Kann GitHub Copilot Claude Skills nutzen?

Nein. Skills sind ein Claude-seitiges Format, gelesen von Claude Code, claude.ai und der API. Copilot kann keine SKILL.md laden, auch wenn Copilot Claude-Modelle als Backend anbietet; das Modell ist austauschbar, die Konfigurationsschicht nicht. Das Wissen in einem Skill lässt sich meist in eine Instructions-Datei umwandeln, minus dem bedingten Laden und etwaigen zusätzlichen Skripten.

Funktionieren Claude Skills mit Repository-Instructions wie copilot-instructions.md zusammen?

Sie koexistieren ohne Konflikt, weil jedes Tool nur seine eigenen Dateien liest. Claude Code ignoriert .github/copilot-instructions.md, und Copilot ignoriert .claude/skills/. Das Risiko ist keine Kollision, sondern Drift: zwei Dateien, die dieselbe Konvention kodieren, werden sich irgendwann widersprechen, sofern sie nicht gemeinsam gepflegt werden.

Was ist besser, um Team-Coding-Standards durchzusetzen?

Für Regeln, die sich auf Dateipfade abbilden und jeden Mitwirkenden erreichen müssen, Copilot Instructions mit applyTo-Globs, weil sie auch für Copilot Code Review bei PRs gelten. Für prozedurale Standards, wie man eine Migration durchführt, Skills, weil sie lange Prozeduren tragen und nur bei Bedarf laden können. Die meisten Standarddokumente enthalten beide Arten und wollen entsprechend aufgeteilt werden.

Sind Copilot Instructions günstiger an Tokens als Skills?

Meist das Gegenteil. Eine zutreffende Instructions-Datei hängt an jedem Request an, eine 1.500-Token-Datei kostet also 1.500 Tokens pro Interaktion, ob relevant oder nicht. Ein Skill kostet etwa 100 Tokens im Leerlauf und lädt seinen Body nur bei Treffer. Always-on lohnt sich, wenn die Regeln wirklich für jeden Request gelten, weshalb kurze Instructions-Dateien lange schlagen.

Sollte ich meine copilot-instructions.md zu Skills umwandeln, wenn ich zu Claude Code wechsle?

Teile sie auf, statt sie umzuwandeln. Die immer-wahren Fakten über das Repo, seine Build-Befehle und Konventionen, gehören in CLAUDE.md, das der nähere Verwandte ist. Die prozeduralen Abschnitte, alles, was sich wie "beim Tun von X befolge diese Schritte" liest, gehören in Skills, damit sie bedarfsweise laden. Eine direkte Umwandlung produziert meist entweder eine aufgeblähte CLAUDE.md oder Skills, die bei allem triggern.