Agent Skills geht an die Agentic AI Foundation: Was sich für die SKILL.md ändert, die du installierst, und was bis zur Versionierung zu tun ist

Anthropic hat Agent Skills an die Agentic AI Foundation übergeben, das Linux-Foundation-Projekt, das Anthropic im vergangenen Dezember zusammen mit Block und OpenAI gegründet hat. Die Ankündigung kam am 22. Oktober. Übergeben werden Name und Logo, die GitHub-Organisation und die Domain agentskills.io. Die Foundation beherbergt bereits MCP, Blocks Agent goose und OpenAIs AGENTS.md-Konvention. Lead Maintainer sind David Soria Parra und Mahesh Murag; dazu pflegen Engineers von Anthropic, Google, OpenAI und anderen den Standard als Einzelpersonen. Der Post zählt mehr als 70 Plattformen, die Skills laden.

Vor zwei Wochen endete der Supply-Chain-Post bei der fehlenden Registry und den fehlenden Versionen. An beidem ändert die Übergabe bisher wenig. Unten steht, was sie tatsächlich ändert und was du als Installierender in der Zwischenzeit tun kannst. Die Checks und Ausgaben stammen von meinem eigenen Rechner: Claude Code 2.1.309, codex-cli 0.163.0, Python 3.12.3.

Was ändert sich für eine SKILL.md nach der Übergabe von Agent Skills?

An der Datei nichts. Ein Skill ist weiterhin ein Ordner mit einer SKILL.md darin, oben YAML-Frontmatter, darunter die Anweisungen, daneben optional scripts/, references/ und assets/. Kein Feld kam hinzu oder fiel weg, und nichts von dem, was du installiert hast, musst du anfassen.

Geändert hat sich, wer über die nächste Version entscheidet. Bis diese Woche war die Spec ein von Anthropic geführtes Repository mit externen Beitragenden. Jetzt ist sie ein Foundation-Projekt mit einer Maintainer-Gruppe aus mehreren Firmen. Ein Format, das 70 Clients laden, ändert sich also nicht mehr nach dem Zeitplan eines Herstellers. Auf deiner Platte ist das heute nichts wert.

Hat die Agent-Skills-Spec Versionen, die du pinnen kannst?

Noch nicht. Laut Ankündigung hat Anthropic vorgeschlagen, mit einer Roadmap zu beginnen: versionierte Releases, ein formaler Proposal-Prozess und Security-Leitlinien für alle, die Skills schreiben und installieren. Das entscheidende Wort ist „vorgeschlagen“.

Das Repository bestätigt das. agentskills/agentskills hat keine Tags und keine Releases, und der letzte Commit ist zum Zeitpunkt des Schreibens vom 9. August. Es gibt keine „Spec 1.0“, zu der dein Skill konform sein könnte. Auch die Version eines einzelnen Skills ist nicht definiert: Die Spec kennt kein Feld version, nur metadata, eine freie Map von String-Schlüsseln auf String-Werte, mit version: "1.0" als Beispiel. Kein Client, den ich geprüft habe, macht damit etwas. Das eigene Tooling eines Skill-Autors kann es nutzen, aber dann sorgt nur der Autor dafür, dass seine Labels konsistent bleiben. Ein Pin, auf den du dich verlassen kannst, ist das nicht.

Selbst der Referenz-Validator stellt in seiner README klar, dass er nicht für den Produktivbetrieb gedacht ist:

This library is intended for demonstration purposes only. It is not meant to be used in production.

Hier heißen also drei verschiedene Dinge „Version“. Die Spec hat keine. Ein Skill kann ein Label in metadata tragen. Und der Inhalt, den du tatsächlich ausführst, ist durch einen Git-Commit bestimmt, falls er überhaupt aus Git kam.

Wie weit kann sich eine kopierte SKILL.md von ihrer Quelle entfernen?

Weit, und ganz unbemerkt. Ein fremder Skill in meinem ~/.claude/skills ist ein schlichter Git-Clone vom April und steht auf dem Commit seines Autors vom 31. März. Heute habe ich gefetcht:

SK=~/.claude/skills/<the-skill>
git -C "$SK" fetch -q origin
git -C "$SK" log --oneline HEAD..origin/main | wc -l
# 76
git -C "$SK" diff --stat HEAD origin/main | tail -1
# 14 files changed, 828 insertions(+), 558 deletions(-)

Der letzte Upstream-Commit ist vom 16. Oktober. Vier Dinge in diesem Diff solltest du kennen, bevor du irgendeinen Skill pullst.

Die description wurde neu geschrieben. In Claude Code wie in Codex liest das Modell die Description, um zu entscheiden, wann ein Skill passt. Ein Update kann also ändern, wann ein Skill auslöst, nicht nur, was er danach tut.

Das Versionslabel ist umgezogen. Meine Kopie deklariert version: 2.5.1 auf der obersten Ebene der Frontmatter, wo die Spec kein solches Feld hat. Upstream schreibt jetzt version: "3.1.0" unter metadata, wie die Spec es nahelegt. Zwei Kopien desselben Skills führen das Label an zwei verschiedenen Stellen.

Der Ordner ist gewachsen. Upstream liefert jetzt .claude-plugin/plugin.json und eine marketplace.json, eine .cursor-plugin/plugin.json, eine agents/openai.yaml für Codex, eine AGENTS.md und ein Python-Skript, das das Paket prüft. Aus einem Skill, der eine einzige Markdown-Datei war, wurde Packaging für drei Clients plus Code.

Und eine dieser Dateien ändert, wie Claude Code den Ordner behandelt. Laut Doku lässt eine .claude-plugin/plugin.json in einem persönlichen oder Projekt-Skill-Ordner Claude Code diesen Ordner als Plugin laden, unter dem Namen <name>@skills-dir, „with its own agents, hooks, and MCP servers“. Ein git pull in ~/.claude/skills kann also aus einem reinen Text-Skill ein Plugin machen, das Hooks registrieren darf. Das Manifest dieses Upstreams listet nur seinen Skill, und das Repository hat weder Hooks noch MCP-Konfiguration; das habe ich geprüft. Das nächste Update könnte welche haben.

Lies zuerst die vollständige Liste der geänderten Dateien, dann den Diff von allem, was ausgeführt wird oder das Verhalten des Skills steuert:

git -C "$SK" diff --name-status HEAD origin/main
git -C "$SK" diff HEAD origin/main -- SKILL.md scripts/ agents/ .claude-plugin/ AGENTS.md

Wie pinnst du heute einen fremden Agent Skill in Claude Code?

Per Commit. Es gibt zwei Wege, die halten, und einen dritten, der nur so aussieht.

Der einfache Weg ist ein Git-Clone, ausgecheckt auf einem bekannten Commit. Klone außerhalb jedes Ordners, den ein Agent durchsucht, checke den Commit aus, lies den Inhalt und verlinke den Ordner erst dann. Claude Code beobachtet nämlich seine Skill-Ordner und nimmt einen neuen Skill auch mitten in der Session auf:

git clone https://github.com/<owner>/<skill> ~/src/skills/<skill>
git -C ~/src/skills/<skill> checkout --detach <40-character-commit>
# read it, then:
ln -s ~/src/skills/<skill> ~/.claude/skills/<skill>

Ein Pin ist das nur, wenn du dir den Commit notierst und bewusst aktualisierst.

Der stärkere Weg in Claude Code ist ein eigener Plugin-Marketplace, der mit einem sha auf das Repository des Skills zeigt. Die Marketplace-Referenz erwartet einen vollständigen 40-stelligen Commit, und wenn ref und sha beide gesetzt sind, checkt Claude Code den sha aus. Mit einem echten Repository und Commit statt der Platzhalter bestand diese Datei auf meinem Rechner claude plugin validate (eine Warnung, wegen der fehlenden Marketplace-Beschreibung):

{
  "name": "pinned-skills",
  "owner": { "name": "me" },
  "plugins": [
    {
      "name": "<skill>",
      "source": {
        "source": "github",
        "repo": "<owner>/<skill>",
        "sha": "<40-character-commit>"
      }
    }
  ]
}

Leg sie als .claude-plugin/marketplace.json in einen Ordner oder ein Repository, das du kontrollierst, und führe dann claude plugin marketplace add ./my-skills und claude plugin install <skill>@pinned-skills aus. Die Datei habe ich validiert, die Installation nicht ausgeführt. Als Quelle geht auch ein git-subdir (ein Ordner eines größeren Repositorys, mit denselben Feldern ref und sha) oder ein archive, ein Zip mit einem sha256-Wert, gegen den Claude Code laut Referenz den Download prüft.

Der dritte Weg ist metadata.version. Sieht aus wie ein Pin und ist ein Label: Nichts gleicht es mit dem Inhalt ab.

Wie prüfst du eine SKILL.md gegen die Agent-Skills-Spec?

Mit skills-ref, der Referenzbibliothek im Spec-Repository. Sie liegt auch auf PyPI, aber ich habe sie aus einem Clone auf dem Commit installiert, den ich gelesen habe, damit die Regeln zum Spec-Text passen. Sie braucht Python 3.11 oder neuer:

git clone https://github.com/agentskills/agentskills
git -C agentskills checkout --detach 69ef37e9424c0a7ea9dd2293b559e43ec8176379
python3 -m venv .venv && .venv/bin/pip install ./agentskills/skills-ref
for d in ~/.claude/skills/*/; do .venv/bin/skills-ref validate "$d"; done

Die Schleife ist eine Auflistung, kein Gate: Lies die Ausgabe, nicht den Exit-Code. In meinem Ordner fiel ungefähr jeder vierte Skill durch, und die meisten Fehler steckten in Skills, die ich selbst geschrieben habe. Es gab drei Sorten.

Eine Description mit einem Doppelpunkt ohne Anführungszeichen. Eine Zeile wie description: ... sibling: same CLI ... ist kein gültiges YAML: Der Parser liest den zweiten Doppelpunkt als neuen Schlüssel und bricht mit mapping values are not allowed here ab. Setz die Description in Anführungszeichen oder nimm einen |-Block.

Ein version auf der obersten Ebene der Frontmatter. Der Validator erlaubt nur name, description, license, compatibility, metadata und allowed-tools und lehnt alles andere ab.

Eine Description über 1.024 Zeichen, also über dem Limit der Spec.

Ein weiterer Eintrag fiel durch, ohne ein Skill zu sein: der Ordner synced, in den Claude Code die auf einem claude.ai-Account aktivierten Skills legt. Er enthält Skills, ist aber selbst keiner. Die Doku warnt, dass lokale Änderungen darin beim nächsten Sync überschrieben werden können. Neben dir schreibt hier also noch jemand: der Sync.

Jeder meiner durchgefallenen Skills taucht in Claude Code trotzdem auf, und nichts in der Session weist darauf hin. Claude Code ignoriert ein Frontmatter-Feld, das es nicht kennt, ohne Fehlermeldung („without reporting an error“). Für YAML, das sich nicht parsen lässt, sagt die Doku, dass der Skill mit leeren Metadaten geladen wird: „with empty metadata, so /skill-name still works but Claude can’t match against your description“. Ein Skill, den du von Hand aufrufst, funktioniert weiter, und der automatische Trigger fällt stillschweigend aus. Die strengen Pfade liegen woanders: Ein Upload auf claude.ai, die Skills-API oder Anthropics package_skill.py brechen bei jedem Feld außerhalb der sechs mit einem harten Fehler ab. „Läuft in Claude Code“ ist also der schwächste Test, den ein Skill bestehen kann. Lass den Validator laufen, bevor du einen Skill an jemanden weitergibst, auch an dich selbst in einem anderen Tool.

Wo suchen Claude Code und Codex nach Agent Skills?

In verschiedenen Ordnern. Claude Code liest persönliche Skills aus ~/.claude/skills, Projekt-Skills aus .claude/skills im Startverzeichnis und jedem Elternverzeichnis bis zur Repository-Wurzel, dazu Plugins, Managed Settings und --add-dir-Verzeichnisse. Die Skills-Seite erwähnt .agents nicht. Codex liest ~/.agents/skills für den User und .agents/skills vom Arbeitsverzeichnis bis zur Repository-Wurzel, dazu /etc/codex/skills und seine mitgelieferten Skills. Der Client-Guide der Spec nennt .agents/skills „a widely-adopted convention for cross-client skill sharing“ und empfiehlt, den Ordner neben dem eigenen Ordner eines Clients zu durchsuchen. Claude Code tut das laut Doku nicht.

Beide Loader dokumentieren Symlinks. Halte den Skill also an einer Stelle und verlinke ihn in den anderen Ordner:

mkdir -p ~/.agents/skills
ln -s ~/src/skills/<skill> ~/.agents/skills/<skill>

Ein Symlink löst das Auffinden und sonst nichts. Felder, die nur ein Client versteht, bedeuten dem anderen nichts: Codex liest seine UI- und Aufruf-Einstellungen aus agents/openai.yaml, Claude Code seine Extras aus der Frontmatter. Der Skill von oben liefert am Ende pro Client ein eigenes Manifest, um die Lücke zu schließen. So viel zum gemeinsamen Format.

Was sollten Security-Leitlinien für Agent Skills zuerst regeln?

Die Vertrauensgrenze, denn da sind sich die Clients schon jetzt uneinig.

Der Client-Guide der Spec hat dazu einen Absatz: Projekt-Skills können aus einem nicht vertrauenswürdigen Repository stammen, also sollte ein Client sie erst laden, wenn der User den Ordner als vertrauenswürdig markiert hat, sonst kann ein frischer Clone dem Agenten unbemerkt Anweisungen unterschieben („silently inject instructions“). Die Claude-Code-Doku sagt zu allowed-tools Folgendes:

Workspace trust doesn't gate this field. Claude Code applies a project skill's
allowed-tools even in a -p run in a folder you've never trusted.

Die Freigabe gilt nur für den Turn, der den Skill aufruft, und sie ist keine Obergrenze: Tools, die nicht auf der Liste stehen, bleiben unter deinen normalen Berechtigungen aufrufbar. Die Doku rät, die allowed-tools von Skills, die in einem Repository eingecheckt sind, zu prüfen, bevor du dort Claude Code startest, und verweist auf ein Managed Setting, das Repository-Skills dieses Feld entzieht. Es ist dieselbe Form wie bei dem, was die Settings-Datei eines geklonten Repos ausführen kann: Die Datei kommt mit dem Clone, und ein Headless-Lauf fragt niemanden. Gleichzeitig markiert die Spec allowed-tools als experimentell, die Unterstützung könne variieren („may vary“), und die Skills-Seite von Codex erwähnt das Feld nicht.

Meine Lesart: Ein gemeinsames Format, dessen einziges Berechtigungsfeld in jedem Client etwas anderes bedeutet, ist das Erste, was Security-Leitlinien klären müssen. Signaturen und Hash-Pinning sind wichtig, aber sie beantworten „Ist das die Datei, die ich installieren wollte?“. Offen ist, was die Datei nach der Installation tun darf, und heute hängt die Antwort davon ab, welcher Agent den Ordner geöffnet hat.

Bis es diese Leitlinien gibt, sehen die ersten fünf Minuten mit einem Skill, den du nicht selbst geschrieben hast, so aus:

S=path/to/skill
sed -n '1,/^---$/{p}' "$S/SKILL.md" | sed -n '2,$p'   # the whole front matter, allowed-tools included
find -H "$S" ! -name '*.md' ! -path '*/.git/*' \( -type f -o -type l \)   # files and links that are not prose
find -H "$S" \( -name '__pycache__' -o -name '*.pyc' \)   # caches next to code
ls "$S/.claude-plugin" 2>/dev/null                       # does it load as a plugin?
git -C "$S" log -1 --format='%H %ad' && git -C "$S" status --short   # the commit, and anything not in it

Wenn du nur eine Zeile ausführst, dann die letzte. Wenn status irgendetwas ausgibt, ist das, was läuft, nicht der Commit, dem du zu vertrauen glaubst.

Wie verfolgst du Änderungen an der Agent-Skills-Spec?

Beobachte das Repository, nicht den Blog. Änderungen an der Spec landen als Pull Requests in agentskills/agentskills, und laut Ankündigung läuft Feedback zu vorgeschlagenen Änderungen über den Discord des Projekts. Das erste getaggte Release ist der Moment, in dem die Roadmap aufhört, ein Vorschlag zu sein.

Die Foundation hat schon zweimal ein Format übernommen. MCP kam als Protokoll mit datierten Spec-Versionen, AGENTS.md als Dateikonvention ganz ohne Versionen. Skills liegen dazwischen: mehr als eine Konvention, weil ein Skill Code mitbringen kann, und weniger als ein Protokoll, weil noch nichts festlegt, welche Version des Formats ein Client implementiert.