GitHub hat am 29. Juli 2026 angekündigt, dass die Unterstützung für Agent Skills und MCP-Server in Copilot Code Review nun allgemein verfügbar ist. Die Schlagzeile ist unkompliziert: Automatisierte Reviews können die eigenen Standards Ihres Teams anwenden und Kontext aus den Werkzeugen lesen, die Sie ohnehin nutzen. Das Detail, das zweimal Lesen verdient, ist, dass jeder MCP-Aufruf auf Lesezugriff beschränkt ist, und genau das macht die Funktion einführbar statt bloß interessant.
Was tatsächlich ausgeliefert wurde
Zwei Fähigkeiten haben gleichzeitig die Preview verlassen, und sie lösen unterschiedliche Hälften desselben Problems.
Agent Skills erlauben es einem Review, die internen Werkzeuge und Coding-Standards Ihres Teams heranzuziehen. Sie legen eine SKILL.md-Datei in einem Skill-Unterverzeichnis unter .github/skills ab, und ihr Inhalt erweitert die Analyse um Kontext und Anweisungen, die für Ihr Repository oder Ihre Organisation spezifisch sind. Die praktische Folge ist, dass Konventionen, die in einem Wiki liegen, das niemand liest, oder im Kopf einer einzelnen erfahrenen Entwicklerin, zu etwas werden, das der Reviewer konsistent anwendet.
MCP-Server-Verbindungen ziehen Kontext aus Drittanbieter-Plattformen, die Ihr Team bereits betreibt: Ticketsysteme, Dokumentationssysteme, Servicekataloge. Statt ein Diff isoliert zu prüfen, kann der Reviewer sehen, was das verknüpfte Ticket tatsächlich gefordert hat.
GitHub listet die Funktion für Copilot Pro, Pro+, Business und Enterprise. Das ist erwähnenswert, weil mehrere jüngere Copilot-Releases weiter oben auf der Tarifleiter starteten. Wenn Sie eine der beiden Fähigkeiten während der Public Preview konfiguriert haben, gibt GitHub an, dass keine Änderungen nötig sind und Ihre bestehende Einrichtung weiter funktioniert.
Die Read-only-Einschränkung ist die eigentliche Nachricht
Einen automatisierten Agenten mit Ihren internen Systemen zu verbinden, ist die Art von Vorschlag, die im Sicherheits-Review stecken bleibt, und meist aus guten Gründen. Die Frage ist nie, ob der Kontext helfen würde, sondern was passiert, wenn der Agent falsch liegt oder manipuliert wird.
GitHubs Antwort ist hier eine Designentscheidung statt eines Richtlinienversprechens: alle MCP-Tool-Aufrufe von Copilot Code Review sind auf Lesezugriff beschränkt. Der Reviewer kann Ihr Ticketsystem lesen; er kann keine Tickets schließen, keine Dokumentation bearbeiten und keine Servicedefinition ändern. Das verwandelt ein offenes Risiko in ein begrenztes, und das ist der Unterschied zwischen einer Funktion, die ein Sicherheitsteam freigeben kann, und einer, die es nicht kann.
Es lohnt sich, genau zu sein, was das nicht abdeckt. Lesezugriff bedeutet immer noch, dass der Inhalt dieser Systeme den Reviewer erreicht, die üblichen Fragen dazu, welche Daten Ihren Perimeter verlassen, bleiben also relevant. Wir haben diese größere Angriffsfläche in unserer Analyse zur MCP-Sicherheit betrachtet, und die dortige Argumentation gilt unverändert: Schreibzugriffe einzuschränken verkleinert den Wirkungsradius, es beseitigt die Frage der Datenexposition nicht.
Zuordnung: die leise Funktion, die Skills nutzbar macht
GitHub gibt außerdem an, dass Copilot Code Review jetzt kennzeichnet, wenn ein Kommentar mithilfe von Agent Skills oder MCP-Kontext erzeugt wurde.
Das liest sich wie eine kleine Transparenzgeste und ist tatsächlich das, was den Rest praktikabel macht. Ohne Zuordnung ist ein Review-Kommentar ununterscheidbar: Sie können nicht erkennen, ob er einen von Ihnen kodierten Standard oder das allgemeine Training des Modells widerspiegelt. Das zählt in dem Moment, in dem ein Skill anfängt, Rauschen zu produzieren, denn Sie haben keine Möglichkeit zu wissen, welche Kommentare Sie auf welche SKILL.md zurückführen müssen. Mit Zuordnung ist ein schlecht geschriebener Skill debuggbar. Ohne sie hören Teams stillschweigend auf, dem gesamten Reviewer zu vertrauen.
Was sich in der Praxis ändert
Wenn Ihr Team Copilot Code Review bereits betreibt, ist der sinnvolle Schritt eng statt ehrgeizig. Kodieren Sie die Konventionen, die die meisten wiederholten Review-Kommentare erzeugen, jene, die ein Mensch diesen Monat zum zehnten Mal schreibt, und fangen Sie dort an. Das sind die Fälle, in denen sich eine SKILL.md sofort auszahlt und in denen eine falsche Antwort billig zu erkennen ist.
Wenn Sie das Verbinden interner Systeme aufgeschoben haben, räumt die Read-only-Grenze den Einwand aus, der die Diskussion sonst beendete. Sie nimmt Ihnen nicht die Entscheidung ab, welche Server sich zu verbinden lohnen, und die Antwort lautet vermutlich: weniger, als Ihnen lieb wäre. Kontext, der die Schlussfolgerung eines Reviews verändert, ist wertvoll; Kontext, der nur Volumen hinzufügt, macht Reviews langsamer und lauter.
Wenn Sie noch einen Reviewer auswählen, verkleinert das den Abstand zwischen Copilot und Werkzeugen, die sich über Anpassbarkeit differenziert haben. Unser Vergleich der KI-Code-Review-Tools legt die Kategorien und Abwägungen dar, stammt allerdings von vor dieser Ankündigung und behandelt Anpassbarkeit als Differenzierungsmerkmal, das Copilot fehlte.
Fazit
Die Funktion ist seit dem 29. Juli 2026 allgemein verfügbar für Pro, Pro+, Business und Enterprise, konfiguriert über SKILL.md-Dateien unter .github/skills und über MCP-Server-Verbindungen, mit jedem MCP-Aufruf auf Lesezugriff und Kommentaren, die ihrer Quelle zugeordnet sind.
Zusammengenommen ist das eine konservativere Form, als die Rahmung der Ankündigung nahelegt, und konservativ ist hier die richtige Entscheidung. Ein automatisierter Reviewer, der Ihre Systeme lesen und Ihnen sagen kann, woher seine Einschätzungen stammen, ist nützlich. Einer, der in sie schreiben könnte, ohne zu sagen, welcher Kommentar woher kam, wäre eine Belastung. Ausgeliefert wurde Ersteres. Für die Modellseite desselben Stacks haben wir letzte Woche Claude Opus 5 in Copilot behandelt, einschließlich eines Schutzmechanismus, der für Sicherheitsarbeit in die andere Richtung wirkt.
Basierend auf GitHubs veröffentlichtem Changelog-Eintrag vom 29. Juli 2026. Die Tarifnamen, der SKILL.md-Pfad, die Read-only-Beschränkung und das Zuordnungsverhalten sind GitHubs eigene Formulierung, nicht unsere Darstellung. Wir haben die Review-Qualität mit und ohne Skills nicht gebenchmarkt und erheben dazu keine Behauptung.
