GitHub räumt Copilots Erweiterungsregal auf

Ein Regal für Copilots Erweiterungen

GitHub hat den Customize-Tab der Copilot-App am 25. August 2026 allgemein verfügbar gemacht. Dort stehen MCP-Server, Plugins, Skills und Canvases erstmals in einer gemeinsamen Auswahl. Das ist keine neue Fähigkeit des Modells, sondern eine neue Tür zu vorhandenen Anpassungen. Gerade deshalb lohnt der Blick: Bei Werkzeugen entscheidet oft nicht der fehlende Funktionsumfang, sondern der Moment, in dem jemand eine Verbindung überhaupt entdeckt.

Der GitHub-Changelog benennt diese vier Arten ausdrücklich. GitHub verspricht damit keine besseren Antworten und keine fehlerfreien Releases. Das wäre auch eine ziemlich steile Behauptung für einen Tab, der vor allem Auswahl sortiert. Die Änderung macht Optionen sichtbar; sie bewertet weder ihren Datenzugriff noch ihren Nutzen für ein bestimmtes Repository.

Das klingt klein, ist im Alltag aber nicht egal. Ein versteckter Skill wird nicht ausprobiert, ein schwer auffindbarer Server wird durch einen schnelleren Umweg ersetzt. Die neue Ansicht kann solche Reibung reduzieren. Sie kann ebenso dazu führen, dass Teams mehr Erweiterungen anklicken, als sie später noch erklären können. Ein aufgeräumtes Menü ist eben kein Inventar.

Darin liegt auch die nützliche Spannung des neuen Tabs. GitHub senkt die Einstiegshürde, während ein Team seine eigene Bremse einbauen muss. Ein gut sichtbarer Eintrag kann ein sinnvoller Start für eine Recherche sein. Er sollte nicht schon als Entscheidung gelten. Diese Trennung wirkt pedantisch, bis ein Hilfswerkzeug Zugriff auf den falschen Bereich bekommt oder eine alte Anweisung unbemerkt weiterlebt.

Vier Begriffe, die man nicht vermischen sollte

MCP-Server, Plugins, Skills und Canvases stehen nun nebeneinander. Gleichartig sind sie deshalb nicht. Ein MCP-Server kann Copilot mit einem externen Dienst oder einer Datenquelle verbinden. Ein Plugin erweitert eine Funktion. Ein Skill hält wiederverwendbare Arbeitsanweisungen fest. Ein Canvas ordnet Kontext und Arbeitsschritte auf einer Fläche. Die Oberfläche darf diese Kategorien zusammenführen; bei Freigaben sollten Teams ihre Unterschiede deutlich markieren.

GitHub schreibt, Copilot werde nützlicher, wenn es mit den Werkzeugen, dem Wissen und den Arbeitsabläufen eines Teams arbeitet. Das ist eine nachvollziehbare Produktbeschreibung, keine Sicherheitsgarantie. Je näher eine Anpassung an Tickets, Dokumentation oder Quellcode rückt, desto konkreter muss ihr Zweck sein. Eine Verbindung ohne klaren Besitzer wirkt anfangs bequem und wird später zum Rätsel, wenn Ergebnisse plötzlich aus einer Quelle stammen, die niemand auf dem Schirm hatte.

Wer Copilot-Erweiterungen bereits nutzt, findet in der Einordnung zu Copilot und externen Diensten den passenden Hintergrund. Der Customize-Tab beantwortet nicht, welche Daten ein Dienst sehen darf. Er legt die Auswahl früher auf den Tisch. Das ist hilfreich, wenn Teams diese frühe Stelle nutzen, um Zweck, Rechte und Verantwortlichkeit auseinanderzuhalten.

Empfehlungen erleichtern den Einstieg

GitHub legt ausgewählte Anpassungen im Featured-Bereich zusammen. Der Hersteller beschreibt ihn als Startpunkt für Menschen, die noch nicht wissen, ob sie einen Server, ein Plugin, einen Skill oder ein Canvas brauchen. Das ist eine konkrete Hilfe bei der Orientierung. Mehr behauptet der Changelog nicht. Eine hervorgehobene Karte wird dadurch weder zur besten Lösung noch zur passenden Wahl für Ihre Umgebung.

Der Unterschied ist wichtig, weil Empfehlungen die Auswahl beschleunigen. Geschwindigkeit kann angenehm sein; sie darf nur nicht die einzige Begründung werden. Ein Team sollte bei einer neuen Karte in einem Satz festhalten, welches Problem sie lösen soll. Danach folgt die unromantische Seite: Welches System berührt sie, welche Rechte verlangt sie, und wer entfernt sie wieder, wenn der Test schiefgeht? Genau dort trennt sich ein brauchbares Werkzeug von einer nett aussehenden Abkürzung.

GitHub erlaubt außerdem das Stöbern nach Typ. Das hilft bei der ersten Sortierung, erzeugt aber keine Rangliste für Sicherheit oder Qualität. „Trending“ ist eine Beobachtung der Oberfläche, keine Freigabe. Wenn eine Erweiterung zu Repositories, Rollen oder Regeln passen soll, brauchen Sie diese Informationen außerhalb der Kachel. Das ist keine Schwäche des Tabs. Es wäre vielmehr ein Problem, wenn ein Menü diesen Unterschied verschleiern würde.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptAt night in a calm apartment living room, one engineer gathers four distinct blank colored wooden shapes into one shallow circular tray under a warm floor lamp. No documents, paper, maps, folders, notebooks, cards, labels, text, logos, or markings are present anywhere. No screens, monitors, devices, dashboards, interfaces, diagrams, server rooms, laboratories, factories, or industrial equipment appear in the scene. The one-person arrangement conveys choosing and combining capabilities without turning the scene into a technical workbench. Photorealistic magazine photography in a wide 16:9 composition, with clean blank surfaces and no watermark, signature, blur, distortion, or deformation.

MCP-Server: sichtbar heißt noch lange nicht harmlos

Für MCP-Server nennt GitHub trendende Optionen und Kategorien als Wege zur schnelleren Suche. Der Katalog senkt damit die Hürde, einen bestehenden Dienst in den Blick zu bekommen. Er verändert aber nicht, was dieser Dienst nach einer Verbindung lesen oder auslösen kann. Das ist der technische Punkt, der in jeder hübschen Auswahl gern untergeht.

Bei einem Server zählt deshalb nicht nur der Name. Prüfen Sie, welches System angebunden wird und welche Berechtigungen vorgesehen sind. Prüfen Sie auch, ob Copilot Informationen lediglich abfragt oder eine Aktion vorbereiten kann. Diese Fragen machen aus einer vagen Neugier eine begrenzte Entscheidung. Wer sie überspringt, erkennt einen Fehler oft erst dann, wenn der Kontext bereits am falschen Ort gelandet ist.

Ein sauberer Test kann sehr klein bleiben. Wählen Sie einen Dienst mit begrenztem Umfang und beobachten Sie eine klar beschriebene Aufgabe, bevor Sie weitere Systeme verbinden. Es geht nicht darum, jede Erweiterung mit Misstrauen zu behandeln. Es geht darum, eine Abweichung noch einem Auslöser zuordnen zu können. Sobald fünf neue Verbindungen zugleich starten, gewinnt meist nur der spätere Fehlersuch-Marathon.

Die Analyse zu Copilot Cloud Agent und Linear zeigt, warum das nicht theoretisch bleibt: Sobald Assistenz und Ticketarbeit zusammentreffen, entsteht ein Ablauf mit Folgen für mehrere Beteiligte. Customize kann passende Verbindungen schneller sichtbar machen. Es übernimmt nicht die Kontrolle über ihre Ergebnisse. Das wäre ein schlechter Deal, selbst wenn die Kachel sehr überzeugend aussieht.

Canvases bringen Kontext neben die Aufgabe

GitHub beschreibt Featured Canvases als Hilfe, relevanten Kontext sichtbar zu halten, während Nutzer von der Einordnung einer Aufgabe zur Handlung wechseln. Das ist mehr als eine Ablageformulierung. GitHub stellt sich eine Fläche vor, auf der Informationen und nächste Schritte zusammenbleiben, statt sich über Tabs und Notizen zu verteilen.

Als Beispiel nennt GitHub Azure DevOps. Nutzer können dort Issues sichten, Backlogs priorisieren, Follow-ups zuweisen und Arbeit an Copilot übergeben, damit es untersucht, implementiert oder für ein Review vorbereitet. Das sind konkrete Verben mit unterschiedlicher Tragweite. Eine vorbereitete Review-Aufgabe ist etwas anderes als eine automatische Entscheidung über Priorität. Der Kontext kann sichtbar sein und das Ergebnis trotzdem danebenliegen.

Für einen ersten Versuch genügt eine wiederkehrende Aufgabe mit klarer Eingabe und prüfbarem Ergebnis. Ein Ticket lässt sich etwa zusammenfassen oder für ein Review vorbereiten, ohne dass Copilot den Status endgültig ändert. Beobachten Sie dann, ob das Canvas tatsächlich die nötigen Informationen zusammenhält oder nur eine zweite Arbeitsfläche neben dem Tracker erzeugt. Beides ist möglich.

Ein kleiner Katalog braucht klare Besitzer

GitHub bietet neben dem Featured-Bereich eigene Bereiche für jede Anpassungsart. Diese Kombination ist sinnvoll: Ein Einstieg für Unentschlossene, eine präzisere Navigation für Leute mit einem konkreten Ziel. Der Haken liegt nicht im Layout. Er beginnt, wenn niemand mehr weiß, wer eine sichtbare Erweiterung bewertet, betreut oder bei Problemen abschaltet.

Legen Sie für jede freigegebene Anpassung eine zuständige Person oder ein kleines Team fest. Das muss kein Gremium mit Formularfetisch sein. Ein kurzer Eintrag zu Zweck, Zugriffsrahmen und Rückbau reicht für viele Fälle. Er verhindert, dass ein Test still zur Gewohnheit wird und später niemand erklären kann, warum er weiterläuft. Bei Copilot-Integrationen ist diese Klarheit angenehmer als ein langer Policy-Text, den niemand öffnet.

Der Eintrag darf knapp sein, er muss nur auffindbar bleiben. Eine Person, die eine Erweiterung testet, ist nicht automatisch für ihren dauerhaften Betrieb zuständig. Diese kleine Unterscheidung verhindert, dass Verantwortung mit der Zeit verdunstet. Sie macht auch spätere Entscheidungen leichter: behalten, ändern oder entfernen, statt erst eine digitale Archäologie zu beginnen.

GitHub verspricht neue Möglichkeiten, Copilot an die Arbeitsweise eines Teams anzupassen. Ob das gelingt, hängt von der konkreten Kombination ab. Ein Skill kann eine hilfreiche Arbeitsroutine festhalten; ein alter Skill kann Unsinn konservieren. Ein Plugin kann einen Schritt sparen; es kann auch eine weitere Stelle schaffen, an der etwas kaputtgeht. Der Customize-Tab kann diese Fälle nebeneinanderlegen. Entscheiden muss Ihr Team.

Fünf Minuten Test statt Feature-Hopping

GitHub beschreibt den Einstieg schlicht: Copilot-App öffnen, Customize auswählen, Featured-Angebote ansehen oder nach Typ suchen. Für einen ersten Test ist das ausreichend. Nehmen Sie trotzdem nicht automatisch die auffälligste Karte. Wählen Sie eine Aufgabe, bei der Sie vorher wissen, was als brauchbares Ergebnis gilt und bei welchem Fehler Sie abbrechen. Das spart später viel Deutungskunst.

Starten Sie mit einem begrenzten Umfang. Notieren Sie den Zweck der Anpassung, das angebundene System und die erwartete Ausgabe. Sehen Sie sich danach Rechte und Rückbau an, bevor der Test zur Gewohnheit wird. Das ist keine glamouröse Routine. Gerade deshalb funktioniert sie. Ein Tool darf hilfreich sein und trotzdem eine Prüfung brauchen; diese beiden Sätze widersprechen sich nicht.

GitHub hat die Auffindbarkeit von MCP-Servern, Plugins, Skills und Canvases neu organisiert. Der Tab kann die Suche verkürzen und Kontext besser bündeln. Er nimmt Teams aber nicht die Arbeit ab, Grenzen zu setzen und Ergebnisse zu lesen. Wenn eine Anpassung eine klar beschriebene Aufgabe sauber unterstützt, bleibt sie. Wenn sie nur eine weitere hübsche Karte produziert, darf sie wieder verschwinden. Ein kurzer Rückblick nach dem Test sorgt dafür, dass die Entscheidung nicht in einem Chatverlauf oder einem vergessenen Browser-Tab verschwindet. Das klingt unspektakulär. Es ist die Stelle, an der aus einer Empfehlung eine nachvollziehbare Werkzeugwahl wird.