Eine SKILL.md, drei Plattformen

Der wertvollste Teil eines Agents ist nicht das Modell. Modelle tauschst du in einem Dropdown. Es sind auch nicht die Connectoren, die gibt es von der Stange. Wertvoll ist die Anleitung: das mühsam erarbeitete Wissen darüber, wie eine bestimmte Aufgabe in deinem Unternehmen richtig erledigt wird.

Und genau die war bisher in der Plattform eingesperrt, in der du sie geschrieben hast. Das ändert sich gerade.

Was in einer SKILL.md steht

Ein Skill in Copilot Studio ist eine Datei. Sie hat ein YAML front matter mit Name und Beschreibung, darunter steht die Anweisung in Markdown. Das war es.

Ein Skill-Paket ist eine ZIP-Datei mit dieser SKILL.md und optionalen Beidateien: Skripte, Vorlagen, Referenzdokumente. Du kannst den Skill in Copilot Studio schreiben oder in deinem Editor und ihn dann hochladen.

Warum das Format wichtiger ist als es aussieht

Der entscheidende Mechanismus steckt in der Beschreibung im front matter. Die Runtime lädt einen Skill erst, wenn die Anfrage dazu passt. Vorher steht er nicht im Kontext.

Das löst ein Problem, an dem große Agents regelmäßig ersticken. Wenn alles, was ein Agent können soll, in die Systeminstruktion wandert, wird die Instruktion irgendwann so lang, dass das Modell die wichtigen Teile übersieht. Ich habe Instruktionen gesehen, die auf drei Bildschirmseiten angewachsen waren, weil jede Anforderung als weiterer Absatz hinten angehängt wurde. Das Ergebnis ist ein Agent, der zwanzig Dinge halb kann.

Mit Skills bleibt die Systeminstruktion das, was sie sein sollte: Rolle, Tonfall, Grenzen. Alles Aufgabenspezifische lebt in Modulen, die situativ dazugeladen werden.

Die praktische Konsequenz: Die Beschreibung ist die wichtigste Zeile der Datei. Sie ist kein Kommentar, sie ist die Schnittstelle. Eine unpräzise Beschreibung führt dazu, dass der Skill nie gezogen wird oder ständig, und beides ist schwer zu debuggen, weil der Fehler nicht in der Logik steckt, sondern in einem Satz Prosa.

Der Teil, der mich wirklich interessiert

Das Format ist nicht Microsoft-eigen. Skills, die für GitHub Copilot oder für Claude Code geschrieben wurden, lassen sich in Copilot Studio importieren, ohne sie umzuschreiben.

Das ist neu und es ist mehr als eine Bequemlichkeit.

Bisher war jede Investition in Agent-Anleitungen plattformgebunden. Prompt-Bibliotheken, Topic-Bäume, Instruktionssätze: alles proprietär, alles verloren, wenn die Plattformentscheidung gekippt wird. Wer Copilot Studio gegen etwas anderes tauschte, fing bei null an.

Eine SKILL.md ist eine Textdatei. Sie liegt in git, sie wird im Pull Request reviewt, sie hat eine Historie, und sie läuft in mehreren Runtimes. Zum ersten Mal ist der teuerste Teil der Agent-Arbeit ein Artefakt, das dir gehört, und nicht ein Zustand in einer fremden Datenbank.

Für mich als DIE TECHNIKERIN ist das der eigentliche Fortschritt des Jahres. Nicht ein besseres Modell. Ein portables Format für das, was wir über unsere eigenen Prozesse wissen.

Wo Skills hingehören

Meine Empfehlung, und die ist deutlich: nicht in die Plattform, sondern ins Repository.

Ein Skill hat alle Eigenschaften von Code. Er wird versioniert, er wird reviewt, er hat Regressionen, er braucht Tests. Wenn er nur im Copilot Studio Designer existiert, hast du keine dieser Eigenschaften. Du hast einen Stand, den zuletzt jemand geändert hat, von dem niemand weiß, was vorher drinstand.

Ein tragfähiges Setup sieht so aus:

• Ein Verzeichnis skills/ im Repository, ein Unterordner pro Skill mit SKILL.md und Beidateien.
• Änderungen laufen über Pull Requests. Der Review prüft die Beschreibung genauso streng wie die Anweisung, weil das Routing daran hängt.
• Ein Testfall pro Skill in der Evaluation des Agents. Copilot Studio hat dafür seit März GA-Werkzeuge inklusive Multi-Turn-Tests. Ein Skill ohne Testfall ist eine Vermutung.
• Der Upload in die Plattform ist ein Deployment-Schritt, nicht die Quelle der Wahrheit.

Das ist derselbe Weg, den Infrastructure as Code vor zehn Jahren gegangen ist. Erst klickt man es zusammen, dann merkt man, dass niemand mehr weiß, warum etwas so eingestellt ist, dann schreibt man es auf.

Wo ich vorsichtig bin

Portabel heißt nicht identisch. Dieselbe SKILL.md in zwei Runtimes gibt dir kein identisches Verhalten. Der Orchestrator entscheidet, wann er einen Skill lädt, und diese Entscheidung fällt in jeder Plattform anders aus, mit jedem Modell anders und mit jeder Modellversion wieder anders. Das Format ist portabel, das Ergebnis ist es nicht. Wer über Plattformgrenzen hinweg dieselbe Anleitung nutzt, braucht auf jeder Seite eigene Evaluations.

Dazu ein handfester Punkt: In Copilot Studio hängen Skills am GitHub Copilot harness, und der rechnet über Copilot Credits ab dem Moment ab, in dem du baust. Das Ausprobieren von Skill-Varianten ist damit kein kostenloses Nachmittagsprojekt mehr.

Und ein Hinweis, der in der Begeisterung untergeht: Ein Skill ist eine Anweisung, keine Absicherung. Was ein Agent nicht tun darf, gehört nicht nur in eine Markdown-Datei, sondern in Berechtigungen, in DLP-Richtlinien und in die Identität, mit der er unterwegs ist. Anweisungen werden mit einer gewissen Wahrscheinlichkeit befolgt. Berechtigungen nicht.

Das Kurzfazit

Skills sind der erste Baustein der Agent-Ära, der sich wie ordentliche Software anfühlt: eine Datei, ein Format, ein Review, eine Historie. Behandle sie entsprechend, dann überlebt deine Arbeit die nächste Plattformentscheidung.

Behandle sie wie Klickarbeit im Designer, dann eben nicht.

Quellen

• Skills overview for agents, Microsoft Learn, Stand 3. August 2026
• Choose a harness, Microsoft Learn, Stand 3. August 2026
• What's new in Copilot Studio, Microsoft Learn
• Copilot Studio's New Harness, Power Plat Stack, August 2026, zur Importierbarkeit von Skills aus GitHub Copilot und Claude Code