Claude Code Plugins: Was sie sind & wie man sie nutzt

Ein Claude Code Plugin ist ein Ordner, der mehr als eine Art von Erweiterung auf einmal liefert. Während ein Skill eine einzelne SKILL.md-Datei ist, die Claude ein Verhalten beibringt, kann ein Plugin Skills, Sub-Agents, Hooks, Slash-Befehle und sogar einen MCP-Server bündeln und alles mit einem einzigen Befehl installieren. Es ist der Unterschied zwischen dem Überreichen einer Rezeptkarte und dem Überreichen einer voll ausgestatteten Küche.

Anthropic fügte Plugins Ende 2025 zu Claude Code hinzu, und sie lösten ein echtes Problem: Teams installierten nicht einen Skill nach dem anderen, sondern stellten Setups zusammen. Eine "Backend-Entwickler"-Konfiguration könnte einen Debugging-Skill, einen Code-Review-Sub-Agent, einen Pre-Commit-Hook und eine MCP-Datenbankverbindung benötigen. Vor Plugins bedeutete dies vier separate Installationen und vier Orte, an denen das Setup aus dem Takt geraten konnte. Ein Plugin macht daraus eins.

Wir testen und katalogisieren Claude-Skills bei SkillProof, und Plugins sind die nächste Ebene über dem, was wir normalerweise überprüfen: ein Verpackungsformat, kein Verhalten. Diese Anleitung behandelt, was tatsächlich in einem Plugin enthalten ist, wie das Marktplatzsystem funktioniert und dieselbe Vertrauensfrage, die wir seit Beginn bei Skills stellen, jetzt angewendet auf etwas mit einer viel größeren Angriffsfläche.

Was Plugins tatsächlich verpacken

Vier Zutatenarten können in einem einzigen Plugin vorkommen, und die meisten echten Plugins verwenden mehr als eine:

• Skills — Markdown-Anweisungen, die geladen werden, wenn eine Aufgabe übereinstimmt, dasselbe Format, das in Was Claude Skills sind behandelt wird.
• Subagents — Separate Claude-Instanzen mit eigenem System-Prompt und Kontextfenster, nützlich für die Delegation einer lauten oder parallelen Aufgabe.
• Hooks — Shell-Befehle, die automatisch bei Ereignissen wie einem Dateispeichern, einem Commit oder dem Abschluss eines Tool-Aufrufs ausgelöst werden. Ein Lint-on-save-Hook ist das klassische Beispiel.
• Slash-Befehle — Benutzerdefinierte Befehle wie /deploy oder /standup, die einen vordefinierten Prompt oder ein Skript ausführen, wenn ein Teammitglied sie eingibt.
• MCP-Server — Eine Verbindung zu einem externen Tool oder einer Datenquelle, die einmal innerhalb des Plugins konfiguriert wird, anstatt von Hand in jedem Projekt.

Ein Plugin benötigt nicht alle fünf. Viele liefern nur ein paar Skills oder einen einzelnen Hook plus den Befehl, der ihn auslöst. Was es zu einem Plugin macht und nicht zu einer losen Sammlung von Dateien, ist, dass es als eine Einheit installiert wird, mit einem Manifest, das beschreibt, was sich darin befindet.

Plugins vs. Skills: Die npm-Paket-Analogie

Der sauberste Weg, darüber nachzudenken: Ein Skill ist eine Funktion, ein Plugin ist ein Paket.

Ein einzelner Skill lehrt Claude ein Verhalten, sei es die Formatierung von Besprechungsnotizen oder die Überprüfung einer SEO-Seite. Er hat keine Abhängigkeiten und keine Konfiguration über sein eigenes Markdown hinaus. Das ist beabsichtigt: Ein Skill, der geschrieben wurde, um mehrere unabhängige Aufgaben abzudecken, löst tendenziell unzuverlässig bei allen aus, da seine Beschreibung für keine einzelne spezifisch sein kann.

Ein Plugin ist die Distributionseinheit um dieses Verhalten herum. In der npm-Welt wird eine Funktion nicht allein ausgeliefert; sie wird innerhalb eines Pakets mit einer package.json, einer Versionsnummer und vielleicht ein paar anderen Funktionen, die zusammengehören, ausgeliefert. Ein Plugin spielt dieselbe Rolle für Claude Code: Es ist das Ding mit einem Namen, einer Version, einem Autor und einem Manifest, und die Skills, Hooks und Befehle darin sind die Exporte.

Diese Unterscheidung ist aus praktischen Gründen wichtig. Wenn etwas schiefgeht, sind "der Trigger des Skills ist zu vage" und "der Hook des Plugins führt den falschen Shell-Befehl aus" unterschiedliche Fehler mit unterschiedlichen Lösungen. Dem gesamten Plugin die Schuld für einen schlechten Skill darin zu geben oder umgekehrt, verschwendet Zeit. Lesen Sie zuerst das Manifest, um zu sehen, was tatsächlich ausgeliefert wurde, bevor Sie etwas diagnostizieren.

Es bedeutet auch, dass die beiden Einheiten unterschiedlich bewertet werden. Ein Skill lebt oder stirbt von der Trigger-Qualität und ob seine Ausgabe Claudes Standard übertrifft. Ein Plugin lebt oder stirbt davon, ob seine Teile zusammenarbeiten: Löst der Hook vor oder nach der Ausgabe aus, die der Skill benötigt, ruft der Befehl einen MCP-Server auf, der tatsächlich konfiguriert ist, kollidiert die Installation mit etwas, das Sie bereits haben.

Anatomie eines Plugins

Jedes Plugin benötigt ein .claude-plugin-Verzeichnis in seinem Stammverzeichnis, das plugin.json, das Manifest, enthält. Alles andere (skills/, agents/, hooks/, commands/, .mcp.json) liegt daneben als einfache Ordner, nach denen Claude Code per Konvention sucht.

Hier ist ein kleines, aber vollständiges Plugin, kommentiert:

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Unser Lint-Hook, Review-Skill und Deploy-Befehl in einer Installation.",
  "author": "platform-team"
}

Das Manifest ist bewusst schlank gehalten. Es identifiziert das Plugin und seine Version; es listet nicht jede Datei darin auf, da Claude Code skills/, hooks/ und commands/ automatisch nach ihren Ordnernamen erkennt.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

Dieser Hook wird vor jedem Bash-Tool-Aufruf ausgelöst und kann ihn blockieren, so erzwingt ein Plugin beispielsweise "niemals destruktive Git-Befehle auf main ausführen", ohne darauf angewiesen zu sein, dass Claude sich daran erinnert zu prüfen.

<!-- commands/deploy.md -->
---
description: Führe unsere Deploy-Checkliste gegen Staging aus
---

Verifiziere, dass der Branch nicht main ist, bestätige, dass Migrationen angewendet wurden,
und führe dann `./deploy.sh staging` aus. Berichte die Zusammenfassung des Deploy-Logs.

Die Eingabe von /deploy führt genau dies aus, jedes Mal, identisch formuliert für jeden Teamkollegen, der das Plugin installiert. Diese Konsistenz ist das gesamte Verkaufsargument: drei Komponenten, eine Versionsnummer, ein Installationsbefehl, und niemand hat ein lokales Setup, das von dem eines anderen abweicht.

Eine separate Datei, marketplace.json, ist nicht Teil des Plugins selbst. Es ist der Index, den ein Marktplatz-Repository veröffentlicht, damit Claude Code weiß, welche Plugins dort leben und wo jedes einzelne abgerufen werden kann. Die marketplace.json eines Repos kann Dutzende von nicht verwandten Plugins auflisten; betrachten Sie es als das Verzeichnis, mit plugin.json als dem einzelnen Paket darin.

Installation von Marktplätzen

Ein Plugin auf Ihren Rechner zu bekommen, erfordert zwei Befehle. Zeigen Sie Claude Code zuerst auf einen Marktplatz:

/plugin marketplace add anthropic/plugins

Dies liest die marketplace.json dieses Repositorys und fügt jedes darin aufgeführte Plugin zu dem hinzu, was Sie durchsuchen können. Installieren Sie dann eines:

/plugin install code-standards@anthropic

Der Teil @anthropic gibt an, von welchem Marktplatz bezogen werden soll, da Sie mehrere gleichzeitig hinzugefügt haben können und derselbe Plugin-Name theoretisch in mehr als einem existieren könnte. Claude Code ruft die Dateien des Plugins ab, registriert seine Skills und Befehle und verdrahtet alle Hooks oder MCP-Server, die es deklariert.

Hier ist der Teil, der Ihnen vertraut klingen sollte, wenn Sie alles andere gelesen haben, was wir geschrieben haben: Niemand überprüft diese. Das Hinzufügen eines Marktplatzes bedeutet, demjenigen zu vertrauen, der dieses Repository pflegt, und die Installation eines Plugins von dort bedeutet, jeder Datei zu vertrauen, die das Plugin mitbringt, einschließlich Hooks, die Shell-Befehle ausführen, und MCP-Servern, die Netzwerkzugriff erhalten. Dies ist genau das Vertrauensproblem, das wir für Skills dokumentiert haben, nur dass ein Plugin mehr bewegliche Teile hat, was mehr Stellen bedeutet, an denen etwas Schlechtes versteckt sein könnte. Ein Skill kann nur überzeugender Text sein, der in den Kontext geladen wird. Ein Plugin kann auch ein Hook sein, der bei jedem Commit ausgeführt wird, unabhängig davon, ob Sie zuschauen oder nicht.

Unsere Sicherheitscheckliste für Skills gilt hier mit einer Ergänzung. Bevor Sie ein Plugin installieren:

1. Lesen Sie das Manifest und jede referenzierte Datei, bevor Sie den Installationsbefehl ausführen, nicht danach. Eine plugin.json, die behauptet, ein "Deploy-Helfer" zu sein, aber auch einen MCP-Server deklariert, der auf eine unbekannte Domain zeigt, ist ein Signal, auf dem man anhalten sollte.
2. Fixieren Sie die Version. Installieren Sie code-standards@1.2.0, nicht was auch immer latest nächste Woche auflöst. Ein Plugin, das sein Hook-Verhalten ändert, nachdem Sie es bereits vertraut haben, ist schlimmer als eines, das von Anfang an schlecht war, weil Sie nicht darauf achten werden.
3. Prüfen Sie genau, welche Hooks und Befehle ausgeliefert werden. Hooks laufen automatisch, ohne dass Sie etwas eingeben, bei Ereignissen wie Tool-Aufrufen und Dateispeichern. Das ist die Komponente, die am meisten wert ist, vollständig gelesen zu werden, da sie diejenige ist, die im Moment ohne Aufforderung von Ihnen handelt.
4. Behandeln Sie einen MCP-Server, der in einem Plugin gebündelt ist, wie jeden anderen MCP-Server: Er erhält echten Netzwerkzugriff und oft echte Anmeldeinformationen. Das Bündeln in einem Plugin macht es nicht sicherer, es macht es nur einfacher zu installieren, ohne zu bemerken, dass es da ist.

Wir behandeln das vollständige Bedrohungsmodell, einschließlich dessen, wie ein bösartiger Hook oder Skill in der Praxis aussieht, in unserem Sicherheitsleitfaden für Skills. Alles dort über die Behandlung von Anweisungen Dritter wie einer nicht auditierten Abhängigkeit gilt für Plugins, nur mit einem größeren Wirkungsbereich.

Wann Sie das Setup Ihres Teams als Plugin verpacken sollten

Das klarste Signal, dass Sie bereit für ein Plugin sind: Sie haben dieselben Setup-Anweisungen in einem README, einem Slack-Pin und einem Onboarding-Dokument geschrieben, und sie sind bereits in zwei der drei Orte veraltet.

Nehmen wir einen konkreten Fall. Ein Plattformteam möchte, dass jede Claude Code-Sitzung eines Ingenieurs dieselben Standards erzwingt: keine direkten Commits an main, ein konsistenter Code-Review-Pass vor dem Merge und ein Ein-Befehls-Deploy nach Staging. Getrennt gebündelt ist das ein Hook, den jemand zu settings.json hinzufügen muss, ein Skill, den jemand installieren muss, und ein Befehl, von dem jemand wissen muss, dass er existiert. Gebündelt als team-standards-Plugin ist es eine Zeile:

/plugin install team-standards@our-org

und jeder neue Mitarbeiter erhält den Branch-Schutz-Hook, den Code-Review-Checklisten-Skill und den /deploy-Befehl in einem Schritt, versioniert zusammen, sodass ein Update des Deploy-Skripts und ein Update der Review-Kriterien in derselben Version ausgeliefert werden, anstatt auseinanderzudriften.

Das umgekehrte Signal ist ebenfalls wichtig: Wenn Ihr Setup ein einzelner Skill ohne Hooks, Befehle oder MCP-Abhängigkeit ist, fügt das Verpacken als Plugin ein Manifest und eine Marktplatzliste ohne Nutzen hinzu. Veröffentlichen Sie es als Skill für sich, wie wir in Was Claude Skills sind behandeln, und greifen Sie nur dann zu einem Plugin, wenn mehr als ein bewegliches Teil synchron gehalten werden muss. Wenn der MCP-Server der komplizierte Teil Ihres Setups ist, leben unsere Notizen zum Erstellen eines solchen in MCP Builder, was einen Blick wert ist, bevor Sie entscheiden, ob ein Plugin einen eigenen Server benötigt oder auf einen bereits existierenden verweist.

Unser eigener 30-minütiger Claude Code Setup-Leitfaden führt durch den schrittweisen Aufbau dieser Ebene für einen Einzelnen; ein Team-Plugin ist dieselbe Schichtungsübung, nur versioniert und geteilt, anstatt auf jedem Laptop von Hand zusammengestellt zu werden.

Das Ökosystem im Jahr 2026, ehrlich gesagt

Plugins sind jung, und das merkt man. Das Marktplatzformat wurde erst vor wenigen Monaten stabilisiert, was bedeutet, dass die meisten marketplace.json-Dateien da draußen gegen einen frühen Entwurf der Spezifikation geschrieben wurden und seitdem nicht mehr angefasst wurden. Die Dokumentationsqualität variiert enorm: Einige Plugin-Repos haben ein klares README mit einer Versionshistorie, andere sind ein einzelner Commit ohne Erklärung, was der gebündelte Hook tatsächlich tut.

Fragmentierung ist das größere Problem. Da ein Plugin seine eigenen Skills deklarieren kann, anstatt auf bereits installierte zu verweisen, wird dasselbe Verhalten in einem Dutzend verschiedener Plugins mit einem Dutzend verschiedener Qualitätsstandards neu erfunden. Wir haben einen Code-Review-Skill gesehen, der in drei nicht verwandten Plugins gebündelt war, keines wusste von den anderen, jedes nach einem anderen Standard geschrieben.

Das führt zu derselben Qualitätslotterie, die wir bei Community-Skills im Allgemeinen dokumentiert haben: etwa die Hälfte dessen, was wir testen, schlägt beim ersten Versuch fehl, sei es durch ein Installationsskript, das eine Verzeichnisstruktur annimmt, die der Autor nie auf einer sauberen Maschine verifiziert hat, oder ein Hook, der stillschweigend keine Aktion ausführt, weil er gegen eine frühere Version der Hook-API geschrieben wurde. Ein Plugin behebt diese Fehlerrate nicht. Es bündelt nur mehr Komponenten, die jeweils unabhängig fehlschlagen können, und ein Plugin funktioniert nur, wenn jedes Teil darin dies tut.

Nichts davon bedeutet, dass Sie Plugins überspringen sollten. Es bedeutet, dieselbe Skepsis anzuwenden, die Sie bei jeder Abhängigkeit anwenden würden: Prüfen Sie, wer sie pflegt, prüfen Sie, wann sie zuletzt aktualisiert wurde, und installieren Sie nichts mit drei Komponenten, wenn Sie nur eine davon benötigen. Das Verpackungsformat ist wirklich nützlich, um ein Team synchron zu halten. Es ist kein Ersatz dafür, zu lesen, was Sie installieren.

FAQ

Was ist der Unterschied zwischen einem Claude Code Plugin und einem Skill?

Ein Skill ist ein Verhalten in einer Markdown-Datei. Ein Plugin ist eine Distributionseinheit, die mehrere Skills zusammen mit Sub-Agents, Hooks, Slash-Befehlen und einem MCP-Server bündeln kann, die alle zusammen mit einem Befehl und einer Versionsnummer installiert werden. Alle Skills eines Plugins sind im Grunde immer noch Skills; das Plugin ist nur die Verpackung darum.

Wie installiere ich ein Claude Code Plugin?

Fügen Sie zuerst den Marktplatz mit /plugin marketplace add <repo> hinzu, dann installieren Sie ein bestimmtes Plugin davon mit /plugin install <plugin-name>@<marketplace>. Fixieren Sie eine Version, anstatt das zu installieren, worauf latest derzeit verweist, damit eine Aktualisierung das von Ihnen bereits geprüfte Verhalten nicht stillschweigend ändert.

Sind Claude Code Plugins sicher zu installieren?

Behandeln Sie sie so, wie Sie jede Drittanbieterabhängigkeit behandeln würden, und vorsichtiger als einen einfachen Skill, da ein Plugin auch Hooks liefern kann, die automatisch Shell-Befehle ausführen, und MCP-Server mit echtem Netzwerkzugriff. Lesen Sie das Manifest und jede gebündelte Datei vor der Installation, nicht danach. Unser Sicherheitsleitfaden für Skills behandelt das zugrunde liegende Bedrohungsmodell im Detail.

Kann ich meinen eigenen MCP-Server in ein Plugin einfügen?

Ja. Ein Plugin kann eine .mcp.json deklarieren, die einen MCP-Server als Teil der Installation konfiguriert, sodass Teamkollegen die Verbindung automatisch eingerichtet bekommen, anstatt sie in jedem Projekt von Hand zu konfigurieren. Wenn Sie den Server selbst erstellen und nicht nur einen verdrahten, sehen Sie sich MCP Builder für die Erstellungsseite an, bevor Sie entscheiden, ob ein Plugin überhaupt einen eigenen Server benötigt, anstatt auf einen bereits existierenden zu verweisen.

Wo finde ich Claude Code Plugins zum Installieren?

Anthropic unterhält einen offiziellen Marktplatz, und Community-Marktplätze sind seit der Einführung des Formats schnell gewachsen. Die Qualität variiert so stark wie bei Community-Skills im Allgemeinen. Prüfen Sie daher das Manifest, prüfen Sie, wann es zuletzt aktualisiert wurde, und bevorzugen Sie Plugins von Maintainern, die dokumentieren, was tatsächlich enthalten ist, bevor Sie deren Marktplatz hinzufügen.