Claude Skills: Format, Lizenzen und Zugriffsrechte

Claude Skills bündeln Anweisungen und gegebenenfalls Skripte, Referenzen oder Vorlagen für eine wiederkehrende Aufgabe. Ein solches Paket kann beispielsweise beschreiben, wie ein freigegebener Bericht aufgebaut wird oder welche Angaben vor einer Auswertung benötigt werden. Ob es Dateien verändern oder Programme ausführen kann, hängt vom verwendeten Client und seinen Zugriffsregeln ab. Für die Auswahl zählen deshalb folgende Fragen: Passt die Aufgabe, sind die enthaltenen Dateien nachvollziehbar und erlaubt die Lizenz den geplanten Einsatz?

Die Agent-Skills-Spezifikation beschreibt das allgemeine Dateiformat. Claude Code ergänzt eigene Felder und Regeln. Die Claude-Code-Felder gelten für die Einrichtung dieses Clients.

Name und Beschreibung bestimmen die Auffindbarkeit#

Ein Skill besteht laut Agent-Skills-Spezifikation (Stand 3. Oktober 2026) mindestens aus einem Verzeichnis mit einer Datei SKILL.md. Diese Datei beginnt mit YAML-Metadaten und enthält danach die Anweisungen als Markdown. name und description sind Pflichtfelder. Schon diese kleine Struktur erklärt, warum ein heruntergeladenes Verzeichnis ohne Anleitung oder ohne passende Metadaten nicht einfach ein vollständig beschriebenes Skill-Paket ist.

Für den Namen gelten ein bis 64 Zeichen, Kleinbuchstaben, Ziffern und Bindestriche. Er muss dem Namen des übergeordneten Verzeichnisses entsprechen und darf weder mit einem Bindestrich beginnen oder enden noch doppelte Bindestriche enthalten. Die Beschreibung hat ein bis 1.024 Zeichen. Sie soll erklären, was der Skill tut und wann er gebraucht wird. Eine Beschreibung wie „Hilft im Büro“ lässt offen, für welche konkrete Anfrage der Client das Paket auswählen soll.

Ein eigenes Beispiel für ein eng umrissenes Paket könnte so beginnen:

---
name: bericht-pruefen
description: Prüft einen vorhandenen Bericht auf fehlende Quellen und uneinheitliche Datumsangaben. Verwenden, wenn ein Bericht zur redaktionellen Abnahme vorliegt.
---

Das Beispiel legt keine Dateien fest und erteilt keine Ausführungserlaubnis. Erst der anschließende Inhalt müsste erläutern, welche Angaben geprüft werden und welche Änderungen erlaubt sind. Der Name dient der Zuordnung, die Beschreibung der Auswahl. Die tatsächliche Arbeitsanweisung gehört in den folgenden Text.

Bei vielen Skills entscheidet diese Beschreibung auch über den verfügbaren Kontext. Die Anleitung zur Client-Integration (Stand 3. Oktober 2026) beschreibt ein stufenweises Laden: zuerst die Metadaten, bei Aktivierung den vollständigen Anweisungstext und bei Bedarf weitere Ressourcen. Ein verständliches Aufgabenprofil hilft damit auch einem Team, seine Pakete voneinander abzugrenzen. Fast gleich beschriebene Pakete können unterschiedliche Vorgaben enthalten, ohne dass dieser Unterschied bei der Auswahl erkennbar ist.

Skripte und Referenzen gehören zum Paket#

Neben SKILL.md kann ein Skill weitere Dateien enthalten. Die Spezifikation nennt scripts/ für ausführbaren Code, references/ für ergänzende Dokumente und assets/ für Vorlagen oder andere Ressourcen. Diese Namen sind Konventionen für die Organisation, keine Aussage darüber, dass alle enthaltenen Dateien automatisch ausgeführt werden. Eine Referenzdatei kann beispielsweise nur einen zusätzlichen Prüfmaßstab liefern; ein Skript kann dagegen auf Dateien oder externe Systeme zugreifen.

Für den Haupttext empfiehlt die Spezifikation weniger als 500 Zeilen. Das ist eine Empfehlung zur Aufteilung, keine harte Grenze, an der ein sonst korrektes Paket ungültig wird. Detailwissen kann in referenzierte Dateien ausgelagert werden. Auch bei einem kurzen Haupttext lohnt sich daher der Blick auf die gesamten mitgelieferten Ressourcen: Seine Länge beschreibt nicht den gesamten Umfang des Pakets.

Ein übersichtlicher eigener Aufbau wäre etwa:

bericht-pruefen/
  SKILL.md
  references/datumsregeln.md
  assets/pruefprotokoll.md

Das Beispiel verwendet eine Anleitung ohne ausführbares Skript. Der Skill könnte die Prüfung beschreiben und ein Protokoll anbieten, während der Client die vorhandenen Dateien liest. Wird später ein Skript ergänzt, verändert sich der zu prüfende Umfang. Dann zählen neben seiner Aufgabe auch Abhängigkeiten, Netzwerkverbindungen und Schreibzugriffe. Aktualisiere bei einer Erweiterung auch die Beschreibung, damit die neuen Schreib- oder Netzwerkzugriffe sichtbar sind.

Die Claude-Code-Dokumentation zu Skills unterscheidet zudem Anleitungen, die Claude selbst bei einer passenden Aufgabe laden kann, und bewusst aufgerufene Arbeitsabläufe. Das Feld disable-model-invocation: true verhindert in Claude Code die automatische Aktivierung durch das Modell. Es beantwortet die Frage nach dem Aufruf, nicht die nach der Sicherheit aller späteren Schritte. Ein manuell aktivierter Skill kann weiterhin weitreichende Aktionen anweisen.

Die Metadaten beschreiben unterschiedliche Grenzen#

Die Tabelle zeigt die Formatfelder und ihre Bedeutung für die Auswahl. Die Vorgaben stehen in der Agent-Skills-Spezifikation. Zusätzliche Claude-Code-Felder gehören in eine gesonderte Bewertung des jeweiligen Clients.

compatibility kann zum Beispiel benötigte Programme oder Netzwerkzugang nennen. Fehlt das Feld, ist damit noch nicht nachgewiesen, dass ein beliebiger Rechner die Aufgabe ausführen kann. Ebenso kann ein Eintrag unter metadata eine Version nennen, ohne dass der Inhalt dadurch unabhängig kontrolliert wäre. Metadaten helfen beim Einordnen; sie ersetzen das Lesen der betreffenden Dateien nicht.

Bei einem Paket aus einem Repository sind außerdem seine Änderungen relevant. Ein nachvollziehbarer Stand lässt erkennen, welche Dateien tatsächlich geprüft wurden. Wer nur den Namen einer Sammlung festhält, kann eine spätere Änderung am Skript leicht übersehen. Für eine Freigabe ist daher ein konkreter Paketstand hilfreicher als die bloße Aussage, der Anbieter sei bekannt.

Ein öffentliches Repository ist keine Nutzungslizenz#

Das Feld license ist im Format optional. Entscheidend ist, ob die tatsächlichen Dateien und das Repository eine passende Lizenz enthalten. Die GitHub-Dokumentation zur Lizenzierung erläutert, dass ohne Lizenz die allgemeinen urheberrechtlichen Regeln gelten. Die Sichtbarkeit des Repositorys und die Möglichkeit, es auf GitHub anzusehen oder zu forken, ersetzen keine umfassende Erlaubnis zur Weiterverwendung.

Das betrifft auch mitgelieferte Vorlagen und andere Ressourcen. Eine Lizenzangabe muss das vorhandene Material abdecken; eine zusätzliche Datei kann eigene Bedingungen haben. Für ein Unternehmen ist deshalb die geplante Verwendung wichtig: Wird der Skill nur intern eingesetzt, verändert, in einem Kundenprojekt genutzt oder als Teil einer eigenen Sammlung weitergegeben? Aus einer Kurzangabe im Metadatenfeld lässt sich nicht jede dieser Fragen allein beantworten.

Bei unklaren Rechten oder einer geplanten Weitergabe braucht die konkrete Lizenz eine fachkundige Prüfung. Für die Vorauswahl hilft eine dokumentierte Angabe, wo die Lizenz steht und auf welche Dateien sie sich bezieht. Halte eine fehlende Lizenz als offene Frage im Auswahlprotokoll fest. Diese Darstellung ist keine Rechtsberatung.

Zugriffsrechte hängen vom ausführenden Client ab#

allowed-tools ist in der allgemeinen Spezifikation ausdrücklich experimentell. Es ist kein universelles Versprechen, dass andere Werkzeuge ausgeschlossen sind oder eine Ausführung in jedem Client ohne Rückfrage erlaubt wäre. Die Claude-Code-Dokumentation zu Berechtigungen beschreibt eigene Regeln, Modi und verwaltete Vorgaben. Diese Einstellungen bestimmen mit, welche Aktionen der Client ausführen kann.

Die aktuelle Skill-Dokumentation von Claude Code verweist zudem darauf, dass ein allowed-tools-Eintrag durch den normalen Berechtigungsablauf geht. Vorgaben einer Organisation können eine solche Freigabe begrenzen. Prüfe das Paket in dem Client und Konto, mit denen es tatsächlich eingesetzt wird. Eine reine Dateiprüfung benötigt einen anderen Zugriff als ein Skript, das Berichte schreibt oder Daten an eine API sendet.

Für den beschriebenen Berichtsskill wäre zunächst ein lesender Einsatz plausibel: vorhandenen Bericht öffnen, Quellen und Datumsangaben prüfen, ein Ergebnis anzeigen. Wenn er zusätzlich Dateien ändern soll, muss dieser Schritt aus der Aufgabe und den Clientrechten hervorgehen. Ein Text im Skill allein ist kein Ersatz für die Freigabe der betroffenen Datei oder eines externen Systems.

Eine Verbindung zu weiteren Diensten kann über separate Werkzeuge oder MCP entstehen. Welche Komponenten dort Zugriff und Verbindung übernehmen, erklärt der Ratgeber zu MCP. Für einen Ablauf, der nach einem Entwurf eine konkrete Werkzeugfreigabe verlangt, bietet der n8n-Ratgeber ein anderes Modell. In beiden Fällen bleibt der entscheidende Punkt derselbe: Die Paketbeschreibung, die enthaltenen Dateien und die tatsächlichen Zugriffsrechte müssen gemeinsam zur vorgesehenen Aufgabe passen.

Das Skill-Verzeichnis stellt Herkunft und Lizenzangabe der Pakete für die Vorauswahl bereit. Die tatsächlichen Lizenzbedingungen bleiben ein Auswahlkriterium auf Ebene der einzelnen Dateien.