GitHub standardisiert 'Agent Skills', um wiederverwendbare Anweisungen für jeden KI-Agenten bereitzustellen
Das neue Format auf Basis versionierter SKILL.md-Dateien ermöglicht es, wiederholbare Aufgaben zu erfassen und zwischen Agenten zu teilen, während Tools und Berechtigungen unter der Kontrolle jeder Umgebung bleiben
GitHub hat ein standardisiertes Format vorgestellt, um wiederholbare Engineering-Arbeit in Dateien zu erfassen, die Teams überprüfen und zwischen verschiedenen KI-Agenten wiederverwenden können. Der auf dem Blog des Unternehmens detailliert beschriebene Vorschlag dreht sich um ein versioniertes Verzeichnis, dessen Kern die Datei SKILL.md ist, die beschreibt, wann und wie eine Aufgabe ausgeführt wird.
Die Diskussion fand live während der GitHub Universe 2026 in einer Session mit Shishir Tewari, Senior Data Engineering Manager bei Procore, mit dem Titel „Build once, run on any agent: a practical guide to agent skills" statt.
Was die Anweisung von der Ausführung trennt
Die zentrale Prämisse ist, dass die Skill das Wissen über das Verfahren trägt, aber nicht die Mittel zu dessen Ausführung. Eine Skill kann beispielsweise beschreiben, wie eine Datenbank abgefragt wird, gewährt aber keinen Zugriff auf diese Datenbank — Tools, Zugangsdaten und Berechtigungen bleiben spezifisch für die Umgebung, die den Agenten hostet.
Dieses Design löst ein wiederkehrendes Problem: den Kontext, der heute in Chats verloren geht oder im Kopf eines einzelnen Spezialisten gefangen bleibt. Indem dieses Wissen in eine versionierte Datei überführt wird, wird die Anweisung wie jedes andere Code-Artefakt überprüfbar.
Adversariale Verifikation als Prinzip
Der Text verwendet das Beispiel des Proof Agent, der darauf abzielt, von KI generierte Änderungen gegen die ursprüngliche Anfrage zu prüfen. Die Regel, die die Skill leitet, ist direkt: Selbstverifikation ist keine Verifikation. Deshalb untersucht ein unabhängiger Verifizierer die Änderungen und legt Belege für seine Schlussfolgerungen vor.
Das Frontmatter der Skill benennt die Aufgabe und beschreibt ihren Zweck, während der Abschnitt „When to Verify" definiert, wann das Verfahren ausgelöst wird, und der Rest der Anweisungen detailliert, was der Verifizierer prüft und welche Belege beizufügen sind.
Datenpipeline als Anwendungsfall
Das Beispiel Data Forge zeigt, wie mehrere Skills zusammenarbeiten können. In einer Support-Pipeline ermittelt die Skill forge-init Details wie Quelltabellen und Namenskonventionen und schreibt sie in ein aufgelöstes Manifest, das die anderen Skills lesen, um Projektkontext zu erhalten.
Anschließend koordiniert forge-builder die Arbeit von der Issue bis zum Pull Request, wobei forge-dbx zur Abfrage der Datenplattform und forge-lint zur Anwendung der Teamstandards verwendet wird. Eine Person überprüft die vorgeschlagenen Entscheidungen entlang des Weges, und der resultierende Pull Request bündelt Pipeline-Code, Schemaänderungen und Tests.
Jede Skill hat eine definierte Verantwortung und teilt den Projektkontext, anstatt ihn unabhängig neu zu gestalten. Wenn sich ein Schritt ändert, wird eine einzige Skill geändert — und das Wissen hängt nicht mehr von der Verfügbarkeit der Person ab, die es besaß.