Am 24. Februar 2026 kündigte Anthropic private Plugin-Marktplätze für Claude Code an, die Admins eine Möglichkeit geben, Plugins zu bauen, zu hosten und zu kontrollieren, ohne Anthropics öffentliche Registries zu berühren. Was Sie aus diesem Beitrag erhalten: die genauen Schritte zum Bündeln eines Skills und zum Integrieren in ein verteilbares Plugin, zum Hosten in einem privaten GitHub-Repo, zum Fixieren von Versionen und zur Diagnose der häufigsten Fehler, wenn eine zweite Maschine sich weigert, sauber zu installieren.
Wenn ein Team ein Plugin benötigt
Der öffentliche Marktplatz ist in Ordnung für individuelles Experimentieren. Sobald mehr als eine Person auf denselben Slash-Befehl oder dasselbe Hook-Skript angewiesen ist, bricht die ad-hoc-Verteilung schnell zusammen. Jemand kopiert eine Datei manuell, verwendet einen leicht anderen Pfad, und Claude Code ignoriert den Hook stillschweigend, weil der Name nicht dem entspricht, was die Registry erwartet.
Das ist der eigentliche Auslöser für einen privaten Marktplatz: Konsistenz über Maschinen hinweg, nicht die Kopfzahl. Wenn Sie zwei Entwickler haben und beide den gleichen Deployment-Hook benötigen, lohnt sich ein privater Marktplatz für eine Stunde Einrichtung. Wenn Sie zwanzig haben, ist es nicht optional.
Der andere Auslöser ist Vertraulichkeit. Anthropics Plugin-Erstellungsdokumentation ist explizit: Um ein Plugin intern für Ihr Team zu halten, hosten Sie den Marktplatz in einem privaten Repository. Wenn Sie an claude-community übermitteln, wird Ihr Plugin für jeden sichtbar und installierbar. Ein privates Repo vermeidet das ganz. Wenn Ihr Plugin interne API-Muster, proprietäre Slash-Befehle oder etwas enthält, das Sie lieber nicht indexiert hätten, ist die private Route die richtige.
Erwähnenswert: Wenn Ihr Team bereits MCP-Server in der Produktion ausführt, überprüfen Sie, wie die private Plugin-Verteilung in diesen Stack passt, bevor Sie sich auf eine Struktur festlegen, da die beiden Ansätze überlappende, aber unterschiedliche Anwendungsfälle haben.
Bundeln Sie einen bestehenden Skill und Hook
Ein Plugin ist ein Ordner. Das ist die ehrliche Zusammenfassung. Nach der offiziellen Plugin-Dokumentation sieht die minimal lebensfähige Struktur so aus:
my-plugin/
plugin.json
README.md
skills/
my-skill.md
hooks/
hooks.json
guard.sh
Die plugin.json ist das Manifest. Sie benennt das Plugin, deklariert eine Version und verweist auf die Subdirektories Skills und Hooks. Ein gekürztes illustratives Beispiel:
{
"name": "deployment-tools",
"version": "1.2.0",
"description": "Deployment workflow helpers for the platform team",
"skills": ["skills/"],
"hooks": "hooks/hooks.json"
}
Skills sind Markdown-Dateien, die definieren, was Claude tun kann, und Slash-Befehle befinden sich in ihnen. Hooks sind JSON-Deklarationen, die Shell-Skripte zu Triggerpunkten verdrahten (vor einem Tool-Aufruf, nach einer Sitzung und so weiter). Sie können jede Kombination der beiden in einen einzelnen Plugin-Ordner bündeln. Die Skills-Dokumentation vermerkt, dass benutzerdefinierte Befehle jetzt Teil des Skills-Modells sind, also versuchen Sie nicht, sie als separates paralleles System zu führen.
Eine Sache, die Menschen überrascht: Hook-Skripte müssen ausführbar sein. Führen Sie chmod +x hooks/guard.sh aus, bevor Sie committen. Claude Code überprüft das Berechtigungsbit und überspringt einen Hook stillschweigend, wenn es nicht gesetzt ist.
Erstellen und verteilen Sie einen privaten Marktplatz
Ein Marktplatz ist ein GitHub-Repository mit einer spezifischen Ordnerstruktur. Jedes Plugin befindet sich in seinem eigenen Unterverzeichnis. Im Repo-Root benötigen Sie eine registry.json, die katalogisiert, was verfügbar ist. Die Plugin-Marktplatz-Dokumentation beschreibt diese Struktur im Detail, und das Community-Demo bei mrlm-xyz/demo-claude-marketplace zeigt zwei funktionsfähige Beispiel-Plugins mit Agents, Befehlen und Skills, wenn Sie eine konkrete Referenz möchten, bevor Sie von Grund auf neu bauen.
Sobald das Repository existiert, teile Claude Code davon in .claude/settings.json im Repository-Root mit:
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
},
"enabledPlugins": {
"deployment-tools@company-tools": true,
"code-formatter@company-tools": true
}
}
Committed diese Datei. Nun erhält jedes Teamktiglied, das dem Projektordner vertraut, den Marketplace automatisch hinzugefügt – ohne zusätzliche Eingabeaufforderung und ohne manuelle CLI-Schritte. Der enabledPlugins-Block bedeutet, dass diese beiden Plugins standardmäßig aktiv sind. Wer sie nicht möchte, kann sie lokal deaktivieren; die Standardeinstellungen senken nur die Reibung für alle anderen.
Falls du einen Team- oder Enterprise-Plan nutzt und über Organisationseinstellungen verteilst, muss das Marketplace-Repository privat oder intern sein. Die Claude GitHub App liest es aus, deshalb musst du ihr Zugriff explizit gewähren. Ein öffentliches Repository schlägt in diesem Pfad stillschweigend fehl – einer der verwirrenderen Fehlermodi.
Für Teams, die Claude Code-Arbeiten für Clients im großen Maßstab verwalten, übernehmen Seahawks Claude Code Agency Services die Marketplace-Einrichtung und laufende Plugin-Verwaltung, falls du diese Infrastruktur nicht selbst betreiben möchtest.
Versionen kontrollieren und Updates prüfen
Hier machen die meisten privaten Marketplaces etwas falsch. Man pinnt eine Version in plugin.json, pushed eine Breaking Change unter dem gleichen Tag, und wundert sich, warum der Rollback nicht funktionierte. Git Tags sind hier die richtige Einheit der Versionswahrheit, nicht nur die Version-Zeichenkette im Manifest.
Der Workflow, der wirklich hält:
- Erhöhe das version-Feld in
plugin.json(folge semver:1.2.0zu1.3.0für abwärtskompatible Ergänzungen,2.0.0für Breaking Changes). - Commit und push.
- Erstelle einen Git Tag:
git tag v1.3.0 && git push origin v1.3.0. - Aktualisiere
registry.json, um den Plugin-Eintrag auf den neuen Tag zu verweisen.
Um eine bestimmte Version auf einer Maschine zu installieren:
/plugin install deployment-tools@company-tools --version 1.3.0
Zum Rollback auf den vorherigen Tag:
/plugin install deployment-tools@company-tools --version 1.2.0
Das --version-Flag wird gegen Git Tags im Quellrepo aufgelöst. Falls du nicht getaggt hast, fällt Claude Code auf HEAD des Standard-Branches zurück, was bedeutet, dass „Rollback" keinen Sinn macht. Tagge jeden Release. Es dauert zehn Sekunden und spart echte Probleme.
Für Update-Prüfung behandle das Marketplace-Repository wie jeden anderen Production-Codebase: verlange mindestens einen Pull Request, eine Genehmigung und einen Changelog-Eintrag in README.md vor dem Merge zu main. Anthropics eigene Docs weisen darauf hin, dass Plugins hochgradig vertraute Komponenten sind, die beliebigen Code ausführen können, deshalb ist eine „eine-Person-kann-mergen"-Politik auf einem Plugin-Repo unabhängig von der Teamgröße keine gute Idee.
Installation auf einer zweiten Maschine testen
Bevor du das neue Plugin der breiteren Gruppe mitteilst, installiere es auf einem vollständig frischen Profil. Nicht ein anderes Terminal-Fenster. Ein frisches Profil ohne eingebettete Geheimnisse, ohne existierenden Plugin-Status und ohne vorkonfigurierte Marketplace-Einträge über das hinaus, was im settings.json des Repos steht.
Nummerierte Checkliste für einen sauberen Test auf zweiter Maschine:
- Klone das Projekt-Repository.
- Öffne Claude Code und vertraue dem Ordner, wenn gefordert.
- Bestätige, dass der Marketplace mit
/plugin marketplace listangezeigt wird. - Installiere das Plugin explizit:
/plugin install deployment-tools@company-tools. - Führen Sie den Slash-Befehl aus, den das Plugin bereitstellt, und überprüfen Sie, dass er die erwartete Ausgabe zurückgibt.
- Überprüfen Sie, dass der Hook ausgelöst wird, indem Sie den relevanten Tool-Aufruf auslösen und die Ausgabe inspizieren.
- Überprüfen Sie, dass in der Antwort keine Anmeldedaten oder lokalen Pfade von Ihrem Entwicklungsrechner erscheinen.
Diese letzte Überprüfung ist wichtig. Hook-Skripte, die absolute Pfade referenzieren (/Users/yourname/scripts/...), funktionieren auf jedem anderen Rechner nicht. Verwenden Sie Pfade relativ zum Plugin-Verzeichnis oder Umgebungsvariablen, die Teams konsistent setzen können.
Beheben Sie Probleme mit Namen, Pfaden und Abhängigkeiten
Die meisten Installationsfehler sind eine von drei Sachen.
Namenskonflikte. Der Plugin-Name in plugin.json muss exakt mit dem Verzeichnisnamen im Marketplace-Repository und dem Namen in registry.json übereinstimmen. Beachten Sie Groß- und Kleinschreibung. Wenn plugin.json deployment-tools sagt und der Registry-Eintrag Deployment-Tools sagt, gibt der install-Befehl einen not-found-Fehler zurück, der nichts mit Großschreibung zu tun zu haben scheint.
Pfadprobleme in Hooks. Wie oben erwähnt, sind absolute Pfade die häufigste Quelle für „works on my machine"-Fehler. Überprüfen Sie jedes Hook-Skript vor einem Release auf hartcodierte Pfade. Ein schnelles grep -r "/Users" hooks/ findet die häufigsten.
Fehlende Abhängigkeiten. Wenn Ihr Hook-Skript eine externe Binärdatei aufruft (jq, gh, docker, eine benutzerdefinierte interne CLI), dokumentieren Sie diese Abhängigkeit in README.md mit der Mindestversion. Claude Code löst externe Binärabhängigkeiten nicht für Sie auf. Ein Hook, der stillschweigend beendet wird, weil jq nicht installiert ist, ist schwer zu diagnostizieren, besonders für ein Teammitglied, das weiß nicht, dass der Hook existiert.
Ein paar andere Dinge, die es wert sind, überprüft zu werden, wenn die Installation stecken bleibt:
- Die GitHub App benötigt Lesezugriff auf das private Marketplace-Repository. Überprüfen Sie die Organisationseinstellungen, wenn der Abruf nicht abgeschlossen wird.
- Wenn
extraKnownMarketplacesinsettings.jsonvorhanden ist, der Marketplace aber nach dem Vertrauenswürdigkeit der Ordner nicht angezeigt wird, bestätigen Sie, dass die Datei committed ist und dass die Vertrauensaufforderung akzeptiert, nicht abgelehnt wurde. - Plugin-Namen in
enabledPluginsmüssen genau das name@marketplace-Format verwenden.deployment-toolsallein wird ohne den Marketplace-Qualifizierer nicht aufgelöst.
Die dev.to-Serie von Nagell behandelt Auto-Versionierung und Release-CI ausführlicher, wenn Sie GitHub Actions in den Tagging-Workflow einbinden möchten. Lesenswert, bevor Sie den CI-Schritt manuell erstellen.
Für mehr Kontext darüber, wie Claude Code über nur Plugins hinaus in einen echten Entwicklungs-Workflow passt, ist diese Übersicht der Claude Code-Superkräfte eine nützliche Ergänzung.
FAQ
Kann ich den Marketplace woanders als auf GitHub hosten?
Das source-Feld in settings.json unterstützt github und local als Quellentypen gemäß der aktuellen Plugin-Marketplace-Dokumentation. Ein lokaler Pfad funktioniert für einen einzelnen Rechner oder eine bereitgestellte Netzwerkfreigabe, aktualisiert sich aber nicht wie eine git-gestützte Quelle. Für die Teamverteilung mit Versionsverfolgung ist ein privates GitHub-Repository derzeit die praktische Wahl.
Benötigen Teammitglieder ihren eigenen GitHub-Zugriff auf das private Marketplace-Repository?
Nicht direkt. Wenn Sie über die Organisationseinstellungen in einem Team- oder Enterprise-Plan verteilen, liest die Claude GitHub App das Repository in deren Namen. Wenn Sie extraKnownMarketplaces in settings.json ohne den Org-Synchronisierungspfad verwenden, benötigt jeder Benutzer Lesezugriff auf das Repository über seine eigenen GitHub-Anmeldedaten oder einen Deploy Key.
Was ist der Unterschied zwischen `enabledPlugins` und dem tatsächlichen Installieren eines Plugins?
enabledPlugins in settings.json aktiviert Plugins automatisch, wenn der Projektordner vertraut wird. Es ist ein Standard, keine erzwungene Installation. Ein Benutzer kann ein Plugin lokal immer noch deaktivieren. Das manuelle Installieren über /plugin install fügt das Plugin unabhängig davon hinzu, was settings.json sagt. Die beiden Mechanismen funktionieren zusammen: Standards für Bequemlichkeit, manuelle Installation für alles außerhalb des Projektkontexts.
Kann ich mehrere private Marketplaces in einer Organisation haben?
Ja. Das extraKnownMarketplaces-Objekt akzeptiert mehrere Schlüssel. Jeder Schlüssel ist ein lokaler Marketplace-Alias und jeder verweist auf ein separates Quell-Repository. Sie könnten company-tools, data-team-plugins und security-tools alle in derselben settings.json registriert haben. Stellen Sie nur sicher, dass die Aliase eindeutig sind und nicht mit claude-plugins-official oder claude-community kollidieren.
Wie interagiert dies mit Anthropics offiziellem Marketplace?
Sie koexistieren. Claude Code registriert claude-plugins-official automatisch beim ersten interaktiven Start. Dein privater Marketplace wird daneben hinzugefügt. Plugins aus deinem privaten Marketplace werden als plugin-name@your-alias referenziert; offizielle Plugins als plugin-name@claude-plugins-official. Es gibt keinen Konflikt, solange deine Plugin-Namen keine offiziellen duplizieren und Auflösungsmehrdeutigkeiten verursachen.
Die einzelne schärfste Einschränkung aus allem hier: Git-Tags sind der einzige zuverlässige Rollback-Mechanismus. Eine Versionsnummer in plugin.json ohne ein entsprechendes Tag ist Dekoration, keine Wiederherstellungsoption.