Agent-Skills ohne Drift über Repositories teilen

So teilen Sie Agent-Skills über mehrere Repositories hinweg

Um Agent-Skills über mehrere Repositories hinweg zu teilen, kopieren Sie die Datei nicht weiter, sondern machen Sie sie zu einer Abhängigkeit. Führen Sie ein zentrales Skills-Repository, versehen Sie es mit Tags und lassen Sie jedes Projekt einen Tag festlegen. Ergänzen Sie anschließend für jeden Skill einen Smoke-Test und prüfen Sie jede Aktualisierung genauso wie die Aktualisierung einer Abhängigkeit.

Das besteht aus vier Teilen: einer zentralen Quelle, einer festgelegten Version pro Repository, einem Smoke-Test pro Skill und einem Prüfprozess. Im Folgenden wird erklärt, warum jeder Teil erforderlich ist, wie die im Jahr 2026 verfügbaren Tools damit umgehen und wie Sie die gesamte Lösung auf einem selbst gehosteten Git-Remote ohne externe Dienste aufbauen.

Ein Agent-Skill ist ein Verzeichnis mit einer SKILL.md-Datei sowie allen benötigten Skripten und Referenzdateien. Wenn diese Einheit für Sie neu ist, lesen Sie zuerst was ein Agent-Skill ist und wie SKILL.md funktioniert. Diese Seite behandelt die Lieferkette rund um diese Einheit.

Wo ein Skill liegt und warum das Teilen schwierig ist

Claude Code lädt Skills aus drei Verzeichnissen. Die Skill-Dokumentation nennt jeden dieser Pfade.

• ~/.claude/skills/<skill-name>/SKILL.md ist persönlich. Der Skill wird in all Ihren Projekten geladen, aber in keinem Projekt anderer Benutzer.
• .claude/skills/<skill-name>/SKILL.md gilt auf Projektebene. Der Skill wird für jeden geladen, der dieses Repository auscheckt.
• <plugin>/skills/<skill-name>/SKILL.md wird mit einem Plugin ausgeliefert. Der Skill wird überall geladen, wo dieses Plugin aktiviert ist.

Das zweite Verzeichnis ist für ein Team nützlich, weil es versioniert wird und jeder, der das Repository klont, den Skill erhält. Dort beginnen jedoch auch die Probleme. Ein Skill in .claude/skills/ gehört zu genau einem Repository. Sie haben acht Repositories. Der Skill wird daher achtmal kopiert.

Das Frontmatter hilft dabei nicht. Die Agent-Skills-Spezifikation erlaubt sechs Schlüssel. Die Distributionspfade, die diese Vorgabe durchsetzen, geben die Liste aus, wenn Sie einen anderen Schlüssel verwenden:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

Beachten Sie, was fehlt: Es gibt keinen Schlüssel version. In der Datei ist nicht vermerkt, welche Kopie neuer ist. Das ist sinnvoll, weil ein Skill ein Dokument und kein Paket ist. Die Versionierung muss daher von der Ebene um die Datei übernommen werden. Diese Ebene müssen Sie selbst verwalten.

Problem eins: Acht Kopien driften unbemerkt auseinander

Copy-and-paste funktioniert am ersten Tag. Am sechzigsten Tag versagt es. Jemand korrigiert eine falsche Anweisung im payments-Repository und ändert die anderen sieben nicht. Eine andere Person ergänzt in orders eine Regel zur Seitennavigation. Nun führt derselbe Skill-Name zu zwei unterschiedlichen Reviews, abhängig davon, in welchem Verzeichnis der Agent gestartet wurde. Keiner der Entwickler bemerkt den Unterschied.

Der Fehler bleibt unbemerkt, weil kein Fehlerstatus vorhanden ist. Ein Skill besteht aus Prosa. Eine veraltete Anweisung erzeugt eine selbstsichere, falsche Antwort. Das ist die kostspielige Fehlerart. Der Agent vergleicht Ihre Kopie nicht mit den Kopien anderer Personen. Das einzige Signal ist daher, dass jemand bemerkt, dass zwei Repositories voneinander abweichen.

Problem zwei: Keine Version wird festgeschrieben

Selbst wenn ein Team seine Skills an einer Stelle verwaltet, erfolgt die Weitergabe üblicherweise über einen Kopierschritt: ein Setup-Skript, eine curl-Zeile in der Onboarding-Dokumentation oder ein Shell-Alias, das ein Verzeichnis synchronisiert. All diese Methoden installieren den Stand, der gerade an der Spitze des Branches liegt.

Dadurch können zwei Entwickler mit demselben Commit derselben Anwendung unterschiedliche Anweisungen verwenden, weil sie die Synchronisierung an unterschiedlichen Tagen ausgeführt haben. Nach einem fehlerhaften Agent-Lauf lässt sich außerdem die entscheidende Frage nicht beantworten: Welche Version des Skills hat diesen Lauf erzeugt? Ohne aufgezeichnete Revision ist der Lauf nicht reproduzierbar. Der Fehlerbericht lässt sich dann nicht sinnvoll bearbeiten.

Problem drei: Niemand weiß, ob der Skill noch funktioniert

Ein Skill hat keinen Compiler. Er enthält Anweisungen für ein Modell und kann daher ausfallen, obwohl die Datei Byte für Byte unverändert bleibt. Ein Modell-Upgrade verändert, wie genau ein Modell lange Anweisungen befolgt. Ein Kommandozeilentool, das der Skill aufruft, benennt ein Flag um. Eine URL in einer Referenzdatei liefert plötzlich den Statuscode 404, und der Agent arbeitet mit der Fehlerseite.

In keinem dieser Fälle tritt der Fehler offensichtlich auf. Der Agent antwortet weiterhin. Die Antwort ist lediglich schlechter als im letzten Monat. Das ist nur schwer zu bemerken, wenn die Änderung jeweils mit einem einzelnen Pull Request eingeführt wird.

Was die Tools im Jahr 2026 lösen

Mehrere Antworten entstehen derzeit, und sie unterscheiden sich darin, wo die Version hinterlegt werden soll.

Lockfiles. Das skills-Befehlszeilentool von Vercel Labs (vercel-labs/skills, MIT-lizenziert, v1.5.22 am 5. August 2026) installiert Skills aus einem Git-Repository in dem Verzeichnis, das Ihr Agent erwartet. Es kennt die Verzeichnisstruktur von mehr als siebzig Agents. npx skills add <repo> installiert Skills, npx skills update aktualisiert sie und npx skills list zeigt an, welche Skills vorhanden sind. Die Aufzeichnung der installierten Skills wird einmal pro Benutzer und nicht einmal pro Repository gespeichert. Eine offene Anfrage in diesem Projekt (Issue 283) fordert einen skills install-Befehl an, der alle erfassten Skills aus der Lock-Datei erneut installiert, damit auf einem zweiten Rechner dieselbe Menge vorhanden ist. Betrachten Sie diese Anfrage als Statusbericht. Das Konzept einer Lock-Datei ist festgelegt. Die Umsetzung für einzelne Projekte wird noch entwickelt.

Spezifikationen und Tests. SkillSpec verfolgt den anderen Ansatz. Es behandelt einen SKILL.md als zu prüfenden Vertrag und nicht als Text, dem man vertrauen muss. Das erklärte Ziel ist, Skills "befolgbar, testbar und beweisbar" zu machen. skillspec doctor <path> meldet, an welchen Stellen ein Agent den Zusammenhang wahrscheinlich verliert. skillspec boundary map <path> meldet, worauf der Skill zugreifen kann, und skillspec boundary assess <path> stuft diese Ergebnisse nach Risiko ein. Es handelt sich um ein Rust-Crate mit dualer MIT- oder Apache-2.0-Lizenz, in Version 0.2.2 am 29. Juli 2026. Installieren Sie die festgelegte Version und nicht die neueste:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

--locked erstellt den Build mit den Abhängigkeitsversionen, mit denen das Crate veröffentlicht wurde. Dadurch ändert sich der Build nicht unbemerkt. skillspec --version sollte 0.2.2 ausgeben. Eine andere Zahl bedeutet, dass in Ihrem PATH eine ältere Binärdatei Vorrang hat.

Praxis der Anbieter. Google hat in einem Beitrag zu wie Google Agent-Skills erstellt, testet und skaliert beschrieben, wie die Skills in google/skills erstellt werden. Wenn man die Größenordnung außer Acht lässt, handelt es sich um gewöhnliche kontinuierliche Integration (CI). Jeder Skill durchläuft vor dem Merge Linter-Prüfungen für Frontmatter-Metadaten, Zeilenanzahl, Verzeichnisstruktur und Benennung. Ein Linkprüfer lässt den Build bei jeder URL fehlschlagen, die 404 zurückgibt. Dadurch werden plausibel wirkende Links erkannt, die ein Agent erfunden hat. Autoren müssen zusammen mit dem Skill eine Suite von Evaluations-Prompts und ein Bewertungsraster bereitstellen. Geplante Evaluationsjobs werden anschließend wöchentlich für die gesamte Bibliothek ausgeführt, um Regressionen zu erkennen. Jeder Skill hat außerdem einen benannten Verantwortlichen, der ihn bei sinkender Qualität korrigieren soll.

Das Muster hinter allen drei Antworten

Sie müssen sich für keine dieser Optionen entscheiden. Darunter liegt eine einheitliche Struktur, und plain git stellt sie vollständig bereit.

1. Eine einzige Quelle der Wahrheit. Der Skill hat genau einen Speicherort, und jedes Repository verweist auf diesen Speicherort, statt eine Kopie zu enthalten.
2. Eine festgelegte Version pro Repository. Jedes Projekt speichert die exakte Revision, die es verwendet. Ein Upgrade ist dadurch ein Commit in diesem Projekt, mit Autor und Datum.
3. Ein Smoke-Test pro Skill. Eine ausführbare Prüfung belegt, dass der Skill weiterhin das zugesagte Ergebnis liefert.
4. Ein Review-Prozess. Eine Änderung an einem gemeinsam genutzten Skill wird geprüft, und jeder Verwender sieht vor der Übernahme ein Diff.

Das ist die Struktur einer Abhängigkeit. Skills wurden schneller zu gemeinsam genutzten Artefakten, als sich die entsprechenden Werkzeuge entwickeln konnten. Deshalb ist es am sichersten, auf die Werkzeuge zurückzugreifen, denen Sie bereits vertrauen.

Ein Aufbau für ein kleines Team mit einem selbst gehosteten Git-Remote

Ein Repository enthält die Skills. Es enthält nichts anderes. Daher liest sich seine Historie wie ein Änderungsprotokoll der Anweisungen.

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

Releases sind Tags. Verwenden Sie annotierte Tags, weil sie eine Nachricht und ein Datum enthalten. Formulieren Sie die Nachricht als Begründung, warum ein Benutzer die Aktualisierung verwenden möchte:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

Ob Ihr Remote Gitea, Forgejo oder GitLab ist oder ob Sie ein Bare-Repository über SSH auf Ihrem eigenen VPS verwenden, ändert am weiteren Vorgehen nichts. Hier kommen nur git und ein Symlink zum Einsatz.

Pinning mit einem git-Submodul

Ein Submodul speichert einen exakt bestimmten Commit eines anderen Repositorys in Ihrem Repository. Dieser Eintrag ist der Pin. In jedem Projekt, das das Submodul verwendet:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

Der Symlink macht dies möglich. Ein Skill-Eintrag auf Projektebene kann ein Symlink auf ein Verzeichnis an einer anderen Stelle auf dem Datenträger sein. Claude Code folgt diesem Symlink und liest SKILL.md aus dem Zielverzeichnis. Der Skill wird dadurch wie ein normaler Projekt-Skill geladen. Die Dateien liegen jedoch im Submodul bei dem von Ihnen festgelegten Commit.

Prüfen Sie den Pin:

git submodule status

Eine korrekte Zeile beginnt mit einem Leerzeichen. Danach folgen der Commit, der Pfad und das nächstgelegene Tag:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

Ein führendes - bedeutet, dass das Submodul noch nicht initialisiert wurde. .claude/skills/api-review verweist dann auf nichts, und der Skill wird stillschweigend nicht geladen. Beheben Sie dies mit git submodule update --init. Ein führendes + bedeutet, dass sich der ausgecheckte Commit vom gespeicherten Commit unterscheidet. Der betreffende Entwickler verwendet dann Anweisungen, die niemand sonst verwendet. Für neue Klone benötigen Sie git clone --recurse-submodules. Diese Zeile gehört in die README, weil ein normaler Klon vendor/agent-skills leer lässt und keinen Fehler ausgibt.

Ein Upgrade erfolgt bewusst. Genau das ist der Zweck:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

Die Zeile diff ist der Prüfpfad. Sie zeigt dieselbe Änderung, die jedes andere verwendende Repository sehen wird, und passt in einen Pull Request.

Stattdessen Pinning mit einem Plugin-Marktplatz

Wenn Sie nicht jeden Entwickler mit Submodulen vertraut machen möchten, übernimmt das Claude-Code-Plugin-System die Verteilung für Sie und funktioniert auch mit einem selbst gehosteten Remote-Repository. Legen Sie im Skills-Repository unter .claude-plugin/marketplace.json einen Katalog an:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

Hier sind zwei verschiedene Quellen beteiligt. Ihre Verwechslung ist der häufigste Fehler. Die Marketplace-Quelle gibt an, von wo der Katalog selbst abgerufen wird. Sie akzeptiert ref für einen Branch oder einen Tag, aber nicht sha. Eine Plugin-Quelle innerhalb des Katalogs akzeptiert beide Angaben. Wenn beide gesetzt sind, ist sha der tatsächlich verwendete Pin. Der Pin auf einen exakten Commit gehört daher in den Katalogeintrag.

Jedes Repository, das das Plugin verwendet, trägt den Marketplace anschließend in seiner versionierten .claude/settings.json ein:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

Ein Teammitglied, das dem Projektordner vertraut, wird zur Installation des Marketplaces aufgefordert. Das Plugin wird anschließend aktiviert, ohne dass eine Wiki-Seite die erforderlichen Schritte erklären muss. Die Skills sind dann unter /team-skills:api-review verfügbar. Plugin-Skills werden anhand des Plugin-Namens in Namespaces organisiert und können daher nicht mit einem gleichnamigen Projekt-Skill kollidieren. Nachdem Sie einen neuen Tag veröffentlicht haben, aktualisieren die Benutzer mit /plugin marketplace update acme-agents. Anschließend führen sie /reload-plugins aus, wenn die Installationszusammenfassung dazu auffordert.

Einen Smoke-Test für einen Skill schreiben

Ein Smoke-Test ist ein skriptgesteuerter Agent-Lauf gegen ein Fixture mit einem bekannten Fehler sowie einer Assertion. Claude Code läuft mit -p nicht interaktiv. Ein von einem Benutzer aufgerufener Skill funktioniert dort ebenfalls: Setzen Sie /skill-name in den Prompt-String ein. Der Ausdruck wird vor dem Start des Laufs erweitert.

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md ist eine kurze Datei mit einem absichtlich eingebauten Fehler. Die Assertion prüft, ob der Skill diesen Fehler nennt. jq -e beendet sich mit einem Fehlercode, wenn sein Filter null erzeugt. Ein Skill, der den vorbereiteten Fehler nicht mehr erkennt, lässt das Skript daher fehlschlagen. claude beendet sich selbst mit einem Fehlercode, wenn der Lauf fehlschlägt. set -euo pipefail macht aus beiden Fehlern einen fehlgeschlagenen Test.

Ein Modell formuliert seine Antworten zwischen den Läufen unterschiedlich. Prüfen Sie daher nie auf einen vollständigen Satz. Prüfen Sie stattdessen auf einen Bezeichner, den der Skill ausgeben soll, oder auf ein Feld eines von Ihnen vorgegebenen Schemas. Halten Sie das Fixture klein, damit der Lauf kostengünstig bleibt.

Fügen Sie in CI --bare hinzu. Ohne diese Option lädt claude -p denselben Kontext wie eine interaktive Sitzung. Dazu gehören Hooks, Plugins und CLAUDE.md vom System, auf dem der Lauf ausgeführt wird. Die persönliche Konfiguration eines Teammitglieds kann dadurch das Ergebnis verändern. Der Bare-Modus überspringt die automatische Ermittlung vollständig. Dadurch wird auch der getestete Skill übersprungen. Laden Sie diesen Skill daher explizit. Der Bare-Modus liest außerdem Ihre Subscription-Anmeldung nicht ein. Setzen Sie deshalb zuerst ANTHROPIC_API_KEY in der Umgebung:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

Mit --output-format stream-json meldet das erste Ereignis des Laufs, welche Plugins geladen wurden. Es enthält außerdem ein plugin_errors-Array für Plugins, die nicht geladen wurden. Lassen Sie den CI-Job bei einem nicht leeren plugin_errors fehlschlagen. Dadurch wird eine Pinning-Konfiguration erkannt, die auf eine nicht mehr vorhandene Revision verweist. Andernfalls wirkt es lediglich so, als würde der Agent Ihre projektspezifischen Regeln stillschweigend ignorieren.

Eine gemeinsam genutzte Fähigkeit ist eine ausführbare Anweisung

Zwei Funktionen machen das wörtlich möglich. Beide sind relevant, wenn die Datei von einem anderen Team stammt.

Erstens kann ein SKILL.md Shell-Befehle ausführen, bevor das Modell irgendetwas liest. Eine solche Zeile im Inhalt ist eine Vorverarbeitung:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

Der Befehl wird auf dem Rechner ausgeführt, der die Fähigkeit lädt. Seine Ausgabe ersetzt den Platzhalter im Text, den das Modell erhält. Ein Codeblock, der mit drei Backticks gefolgt von ! beginnt, führt mehrere Befehle auf dieselbe Weise aus. Zur Laufzeit bestätigt niemand diese Vorgänge. Eine gemeinsam genutzte Fähigkeit zu lesen bedeutet daher auch, ihre Befehlssubstitutionen zu lesen.

Zweitens kann das Frontmatter Tools vorab freigeben. allowed-tools gewährt die dort aufgeführten Tools für die Ausführung, durch die die Fähigkeit aufgerufen wurde, ohne Berechtigungsabfrage. Bei einer Projektfähigkeit wird diese Freigabe wirksam, sobald jemand den Dialog zur Vertrauensstellung des Arbeitsbereichs für den Ordner akzeptiert. In der Dokumentation von Claude Code wird die Folge ausdrücklich beschrieben: Prüfen Sie Projektfähigkeiten, bevor Sie einem Repository vertrauen, da eine Fähigkeit sich selbst weitreichenden Tool-Zugriff gewähren kann.

Behandeln Sie daher eine Aktualisierung einer Fähigkeit genau wie eine Aktualisierung einer Abhängigkeit. Verwenden Sie, sofern der Mechanismus dies zulässt, einen exakten Commit als Pinning, da ein Tag verschoben werden kann und sich ein Branch definitionsgemäß weiterbewegt. Auf einem abgeschotteten Rechner ersetzt "disableSkillShellExecution": true in den Einstellungen jede Befehlssubstitution durch den Literaltext [shell command execution disabled by policy], anstatt sie auszuführen. Wird diese Einstellung über verwaltete Einstellungen angewendet, kann ein Benutzer sie nicht überschreiben. Gebündelte und verwaltete Fähigkeiten sind von dieser Einstellung ausgenommen.

Dieselbe Sorgfalt gilt für die Daten, die eine Fähigkeit liest. Eine Fähigkeit, die env ausführt oder eine Konfigurationsdatei öffnet, übernimmt alle gefundenen Inhalte in den Kontext des Modells. Das ist der Fehler, der in Geheimnisse aus den von Ihnen ausgeführten Agenten heraushalten behandelt wird.

Was Sie bei einer Versionsanhebung lesen sollten

• Den Diff jedes SKILL.md-Rumpfs, weil dieser Text die Anweisungen enthält, die Ihr Agent befolgt.
• Jede Befehlssubstitution, weil diese beim Laden des Skills auf Ihrem Rechner ausgeführt wird.
• Jede Änderung an allowed-tools, weil diese Zeile ohne Rückfrage Zugriffsrechte auf Werkzeuge gewährt.
• Den Testlauf hinter dem Tag. Wenn das gemeinsame Repository eigene Smoke-Tests in CI ausführt, sollte der Tag, auf den Sie festlegen, einen erfolgreichen Lauf aufweisen.

Wenn ein Reviewer den vollständigen Diff nicht innerhalb von zehn Minuten lesen kann, ist der Skill zu groß geworden. Teilen Sie ihn auf. Dasselbe gilt für die Repository-Dokumente, die Ihre Agents lesen: Legen Sie dauerhafte Regeln in den Dateien aus der Aufteilung zwischen AGENTS.md und HUMAN.md ab, architektonische Begründungen dagegen in einer für Agents geschriebenen DESIGN.md, und halten Sie Skills auf eng gefasste Verfahren beschränkt.

Wenn eine Modell- oder Tooländerung einen Skill beschädigt

Unterhalb eines Skills können sich mehrere Dinge ändern, ohne dass jemand den Skill bearbeitet. Ein Modell-Upgrade verändert, wie zuverlässig eine lange Anweisung befolgt wird. Dadurch erreicht ein Skill, der darauf angewiesen war, dass das Modell Schritt neun ausführt, diesen Schritt möglicherweise nicht mehr. Ein Befehlszeilentool benennt ein Flag um. Der Agent verwendet dann das alte Flag, liest die Fehlermeldung und improvisiert. Eine referenzierte URL liefert plötzlich 404 zurück. Ein Agent-Harness ändert die Auswahl der Skills. Dadurch gewinnt ein description, das zuvor die Übereinstimmung gewonnen hat, möglicherweise nicht mehr.

Deshalb ist der Smoke-Test in diesem Aufbau besonders wichtig. Führen Sie den Test jedes Skills regelmäßig und zusätzlich bei jedem Push aus. Google führt seine Evaluierungsjobs aus diesem Grund wöchentlich für die gesamte Bibliothek aus. Für ein Team mit zehn Skills reicht ein wöchentlicher Cron-Job auf einem kleinen VPS aus. Nur so erfahren Sie von der Störung, bevor ein Entwickler sie bemerkt.

Auch Portabilität ist hilfreich. Die Agent Skills-Spezifikation beschränkt das Frontmatter auf sechs Schlüssel. Ein nach dieser Spezifikation geschriebener Skill kann daher in weiteren Tools geladen werden, nicht nur in dem Tool, für das er geschrieben wurde. Jeder zusätzliche, harness-spezifische Schlüssel ist dagegen eine Festlegung auf einen Anbieter. Skills zu schreiben, die einen Modellwechsel überstehen, ist eine eigene Disziplin. Sie wird unter einen Skill auf jedem Modell funktionsfähig machen behandelt.

FAQ

Wie kann ich eine Skill eines Agents in mehreren Repositorys gemeinsam verwenden?

Legen Sie die Skill in einem dedizierten git-Repository ab, versehen Sie dort die Releases mit Tags, und lassen Sie jedes nutzende Projekt auf ein Tag verweisen, statt die Datei zu kopieren. Dafür eignen sich zwei Mechanismen. Ein git-Submodul speichert einen exakten Commit. Ein Symlink von .claude/skills/<name> in das Submodul sorgt dafür, dass die Skill als normale Projekt-Skill geladen wird. Ein Plugin-Marktplatz erfüllt dieselbe Aufgabe über /plugin. Die Pinning-Angabe wird dabei im .claude/settings.json des nutzenden Repositorys definiert. Beide Varianten speichern die Version in der git-Historie. Dadurch können Sie nachvollziehen, welche Anweisungen einen bestimmten Agent-Lauf erzeugt haben.

Kann ich eine Skill eines Agents auf eine bestimmte Version festlegen?

Nicht innerhalb von SKILL.md, weil dieses Frontmatter keinen version-Schlüssel besitzt. Die Versionsfestlegung muss aus der übergeordneten Ebene um die Datei kommen. Ein git-Submodul pinnt konstruktionsbedingt einen exakten Commit. In einem Claude Code Plugin-Marktplatz akzeptiert eine Plugin-Quelle ref für einen Branch oder ein Tag und sha für einen exakten Commit. Wenn beide Angaben vorhanden sind, hat sha Vorrang. Die Marktplatzquelle selbst akzeptiert nur ref. Bevorzugen Sie die Pinning-Angabe für den Commit, weil ein Tag nach Ihrer Prüfung verschoben werden kann.

Was sollte ein Smoke-Test für eine Skill prüfen?

Prüfen Sie auf etwas Stabiles. Führen Sie die Skill nicht interaktiv mit einem Fixture aus, das einen bekannten Fehler enthält. Prüfen Sie anschließend, ob eine bestimmte Kennung in der Ausgabe erscheint, beispielsweise eine Regel-ID, die die Skill melden soll. Wenn Sie mit --output-format json und --json-schema eine strukturierte Ausgabe anfordern, wird die Prüfung exakt. jq -e lässt das Skript fehlschlagen, wenn der Wert fehlt. Prüfen Sie niemals einen vollständigen Satz. Ein Modell formuliert seine Antworten zwischen den Läufen unterschiedlich.

Ist es sicher, eine gemeinsame Skill aus dem Repository eines anderen Teams zu installieren?

Behandeln Sie sie wie eine Code-Abhängigkeit, weil sie ausführbare Anweisungen enthält. Eine SKILL.md kann beim Laden über die Befehlssubstitutionsform ! Shell-Befehle ausführen. Das Frontmatter-Feld allowed-tools kann Tools ohne Rückfrage vorab freigeben. Lesen Sie bei jeder Aktualisierung den Diff, pinnen Sie auf einen exakten Commit statt auf einen Branch, und bevorzugen Sie eine Quelle, die Ihr eigenes Team kontrolliert. Auf verwalteten Rechnern verhindert "disableSkillShellExecution": true in den Einstellungen, dass Befehlssubstitutionen überhaupt ausgeführt werden.

Funktioniert eine gemeinsame Skill auch in Agents außerhalb von Claude Code?

Das hängt davon ab, welches Frontmatter Sie verwenden. Die Agent-Skills-Spezifikation definiert sechs Schlüssel: name, description, license, compatibility, metadata und allowed-tools. Eine Skill, die auf diese Schlüssel beschränkt ist, wird in Tools geladen, die die Spezifikation implementieren. Sie wird außerdem ohne Änderungen in Claude Code geladen. Harness-spezifische Schlüssel und Body-Funktionen außerhalb der Spezifikation werden an anderer Stelle ignoriert oder abgelehnt. Lassen Sie diese daher aus jeder Skill heraus, die Sie umfassend gemeinsam verwenden möchten.