Zum Hauptinhalt springen

Copilot Kontext, Instructions und Governance

Was diese Seite abdeckt

Die Copilot-Qualität hängt stark vom Kontext ab. Diese Seite erklärt, wie du Copilot deine Repository-Konventionen beibringst, wann du AGENTS.md nutzt, wo Spaces und MCP hineinpassen und welche Governance-Details wichtig werden, sobald ein Team über gelegentliches Experimentieren hinausgeht.

1. Beginne mit Repository-Instructions​

Wenn Copilot nicht weiß, wie dein Projekt organisiert ist, wie du Änderungen testest oder was „fertig" bedeutet, ist die Modellqualität weniger wichtig, als du denkst.

GitHub unterstützt Repository-Custom-Instructions, damit Copilot projektspezifische Vorgaben automatisch aufnehmen kann.

Die wichtigsten Bausteine sind:

  • .github/copilot-instructions.md für repository-weite Vorgaben,
  • .github/instructions/*.instructions.md für pfadspezifische Vorgaben,
  • AGENTS.md für agentenorientierte Instructions nahe am Arbeitsverzeichnis,
  • persönliche und Organisations-Instructions für breitere Präferenzen.

GitHubs Doku weist auch darauf hin, dass Copilot in manchen Agent-Workflows CLAUDE.md oder GEMINI.md im Repository-Root als Alternativen nutzen kann, aber AGENTS.md ist die portabelste Wahl, wenn du agentengerichtete Instructions willst, ohne das Repo an einen Modellanbieter zu binden.

2. Eine praktische copilot-instructions.md​

Halte Repository-Instructions kurz, konkret und operativ. Gute Instructions beantworten:

  • wie das Repo strukturiert ist,
  • welche Befehle Änderungen bauen, testen, linten oder validieren,
  • welche Sprach-, Framework- und Stil-Konventionen wichtig sind,
  • was niemals leichtfertig geändert werden sollte,
  • wie entschieden wird, ob eine Aufgabe abgeschlossen ist.

Beispiel:

# Project conventions

- Use Yarn for package management.
- Run `yarn build` before considering documentation changes complete.
- Write source docs in English.
- Keep MDX frontmatter concise and consistent with nearby pages.
- Prefer updating existing pages over creating near-duplicate content.

Das Ziel ist nicht, alles zu beschreiben. Das Ziel ist, die Fehler zu eliminieren, die Copilot sonst wiederholen würde.

3. Wo AGENTS.md hineinpasst​

AGENTS.md ist nützlich, wenn du Instructions willst, die besonders für agentische Arbeit relevant sind:

  • Freigabe- und Bearbeitungsregeln,
  • Validierungserwartungen,
  • Repository-Grenzen,
  • Workflow-Präferenzen für autonome Änderungen.

Es ist besonders wertvoll in größeren Monorepos, weil GitHub dokumentiert, dass die nächstgelegene AGENTS.md im Verzeichnisbaum Vorrang hat, während Copilot arbeitet. Das macht es zu einer guten Wahl für bereichsspezifisches Verhalten.

Nutze AGENTS.md, wenn:

  • Unterprojekte unterschiedliche Regeln haben,
  • das Agentenverhalten stärkere Kontrolle braucht als eine generische Instructions-Datei,
  • dein Team Konventionen ohnehin über mehrere Coding-Agenten hinweg teilt.

4. Copilot Spaces​

Copilot Spaces sind die kollaborative Kontext-Schicht. Ein Space kann enthalten:

  • Repositories,
  • Code,
  • Pull Requests,
  • Issues,
  • Notizen und Transkripte,
  • Bilder und Uploads.

Das macht Spaces nützlich für:

  • Onboarding,
  • Feature- oder Incident-Kontextpakete,
  • wiederkehrende Team-Workflows,
  • repository-übergreifende Fragen, bei denen der normale Chat-Verlauf zu fragil ist.

Spaces sind kein Ersatz für Repository-Instructions. Sie lösen ein anderes Problem:

  • Instructions definieren stabiles Projektverhalten,
  • Spaces sammeln Aufgaben- oder Domänenkontext, den Leute wiederverwenden und teilen wollen.

5. MCP in Copilot​

MCP ist der Punkt, an dem Copilot sinnvoll erweiterbar wird.

GitHub dokumentiert MCP-Unterstützung über:

  • IDE-Clients,
  • die Copilot CLI,
  • die GitHub-Copilot-App,
  • repository-weite Konfiguration für Cloud Agent und Code Review.

Zwei besonders wichtige operative Details:

  • Die Copilot CLI unterstützt sowohl lokale als auch Remote-MCP-Server.
  • Für repository-weite GitHub-Workflows sind der GitHub MCP Server und der Playwright MCP Server standardmäßig für Cloud Agent und Code Review aktiviert.

Das bedeutet, dass Copilot über „antworte auf Basis von Repo-Text" hinaus zu „nutze Tools und externe Systeme" gehen kann, aber es bedeutet auch, dass Zugriffskontrolle weit wichtiger wird.

Für eine tiefere GitHub-spezifische MCP-Aufschlüsselung siehe den GitHub MCP Server - Developer Guide.

6. Governance, die wirklich zählt​

Sobald Copilot von einem Team statt von einem Entwickler genutzt wird, verschieben sich die wichtigen Fragen.

Du musst wissen:

  • welche Modelle erlaubt sind,
  • wer den Cloud Agent nutzen darf,
  • ob Code Review aktiviert ist,
  • ob MCP erlaubt ist und aus welcher Registry,
  • wie Nutzung und AI-Credits überwacht werden,
  • welche Repositories ein- oder ausgeschlossen sind.

Hier wird Copilot weniger zum persönlichen Assistenten und mehr zu einer Plattform-Fähigkeit.

7. Wichtige Vorbehalte für echte Repositories​

Manche Details sind leicht zu übersehen:

  • Cloud Agent und einige fortgeschrittene Customization-Features hängen von kostenpflichtigen Plänen und Richtlinienkonfiguration ab,
  • der Cloud Agent nutzt sowohl AI-Credits als auch GitHub-Actions-Ressourcen,
  • Repository-Custom-Instructions können Chat, Code Review und Agent-Sessions beeinflussen,
  • GitHub dokumentiert, dass der Cloud Agent Content Exclusions nicht auf die gleiche Weise berücksichtigt wie andere Copilot-Features, daher braucht der Rollout für sensible Repos zusätzliche Sorgfalt.

Dieser letzte Punkt ist besonders wichtig für Unternehmen. Wenn du dich aus Sicherheitsgründen auf Exclusions verlässt, verifiziere das Verhalten Feature für Feature, bevor du breit ausrollst.

8. Ein vernünftiger Team-Rollout​

Wenn du Copilot in einem Repository oder einer Organisation einführst, sieht ein drama-armer Rollout meist so aus:

  1. Füge Repository-Instructions hinzu.
  2. Entscheide, wo AGENTS.md gebraucht wird.
  3. Pilotiere IDE-Chat oder CLI mit einer kleinen Gruppe.
  4. Aktiviere den Cloud Agent nur für Repositories mit klarer Review-Disziplin.
  5. Füge MCP-Server schrittweise hinzu, nicht alle auf einmal.
  6. Prüfe Credits, Auditierbarkeit und Richtlinieneinstellungen, bevor du auf das gesamte Team skalierst.

Copilot wird deutlich besser, wenn das Team Kontext als Infrastruktur behandelt, nicht als optionale Dekoration.