Plugins

Was ein Plugin ist

Ein Plugin ist eine installierbare Einheit. Es bündelt alles, was du sonst von Hand teilen würdest: Skills, Subagenten, Hooks und MCP-Server-Konfigurationen, plus den längeren Schwanz an Dingen wie Language-Server-Protocol-Server, Hintergrundmonitore, Themes und einen Ausschnitt von settings.json. Eine Version, eine Installation.

Wo das Plugin liegt, entscheidet, wie du es installierst. Innerhalb einer Sitzung kannst du eines direkt über den Namen installieren:

Der Befehl öffnet zuerst die Details des Plugins, sodass du es prüfen und einen Geltungsbereich wählen kannst. Dann installiert Claude Code es und gibt eine kurze Zusammenfassung aus. Entweder heißt es, dass das Plugin in dieser Sitzung bereits aktiv ist, oder es erwähnt /reload-plugins, und Claude Code führt dieses Neuladen für dich aus. Du musst nur eingreifen, wenn das Neuladen warnt, dass deine nächste Nachricht das gesamte Gespräch erneut einlesen würde: Führe /reload-plugins --force aus, um das Plugin trotzdem zu aktivieren.

Einen Marketplace für dein Team hinzufügen

Für ein Team ist es der bessere Schritt, einmal einen privaten Marketplace hinzuzufügen. Ein Marketplace ist eine gemeinsame Quelle, über die Plugins aufgelöst werden:

Nenne ihn, wie du willst. Sobald er hinzugefügt ist, wird jede Installation danach darüber aufgelöst. Du bekommst zentralisierte Auffindbarkeit, Versionsverfolgung und Updates an einem Ort, statt über die Laptops aller verstreut.

Du kannst im Discover-Tab durchsuchen, was verfügbar ist. Es listet die Plugins auf deinen Marketplaces auf, sodass du suchen und auswählen kannst.

Lies, bevor du installierst

Hier kommt der wichtigste Teil. Ein Plugin führt Code auf deinem Rechner aus, mit deinen Rechten. Seine Hooks feuern bei jedem passenden Tool-Aufruf. Wenn du also ein Plugin wegen seiner Skills installierst, bekommst du auch seine PreToolUse- und Stop-Hooks, ob du sie gelesen hast oder nicht.

Denk darüber nach, was das bedeutet. Ein Community-Plugin könnte einen Stop-Hook mitliefern, der jedes Mal einen Netzwerk-Endpunkt aufruft, und nichts in deiner Konfiguration würde dich davor warnen. Das ist kein Grund, Plugins zu meiden. Es ist ein Grund, zuerst hinzuschauen.

Bevor du installierst, prüfe die Details des Plugins. Claude Code zeigt dir, was installiert wird, schätzt die Kontextkosten und gibt eine klare Warnung, dass Anthropic nicht kontrolliert, was in Plugins von Drittanbietern steckt.

Zwei Dinge, die es wert sind zu wissen, woher Plugins kommen:

• Ein Plugin gelangt auf den Community-Marketplace, weil die Person, die es geschrieben hat, es an Anthropic geschickt hat.
• Der offizielle Marketplace wird auf einem eigenen, separaten Weg kuratiert.

Aber gelistet ist nicht dasselbe wie vertrauenswürdig. Die Regel bleibt also: Installiere Plugins und füge Marketplaces nur aus Quellen hinzu, denen du wirklich vertraust, und prüfe, was ein Plugin tatsächlich tut, bevor du es aktivierst.

Komponenten laufen neben deinen eigenen

Ein Plugin überschreibt nicht deine Konfiguration. Seine Komponenten laufen neben deinen eigenen. Das ist größtenteils gut, hat aber Konsequenzen, die du verstehen solltest.

Hooks stapeln sich. Der PreToolUse-Hook eines Plugins und dein eigener PreToolUse-Hook feuern beide bei jedem Tool-Aufruf. Keiner ersetzt den anderen. Genau deshalb liest du die Details zuerst.

Skills, Agenten und Befehle sind unter dem Plugin-Namen namensräumlich getrennt, sodass sie nie mit deinen eigenen kollidieren. Ein Plugin kann auch eine settings.json-Datei mitliefern, aber nur eine eingeschränkte. Claude Code berücksichtigt daraus nur zwei Schlüssel: die Agent- und Subagent-Statuszeilen-Schlüssel.

Dieser Agent-Schlüssel ist eine Pause wert. Ihn zu setzen, befördert einen der Subagenten des Plugins in den Hauptthread, zusammen mit seinem System-Prompt, seinen Tool-Einschränkungen und seinem Modell. Mit anderen Worten: Das Aktivieren des Plugins kann ändern, wie sich Claude Code standardmäßig verhält. Das ist einer der Hauptgründe, hinzuschauen, bevor du es überhaupt aktivierst.

Sobald ein Plugin installiert ist, kannst du alles sehen, was es hinzugefügt hat, es verwalten und es über das Plugin-Panel deinstallieren.

Dein eigenes Plugin verpacken

Jetzt die andere Seite. Sobald du ein .claude-Verzeichnis gebaut hast, das funktioniert, lass dein Team es nicht zwischen Rechnern kopieren und einfügen. Verpacke es stattdessen.

Die gute Nachricht ist, dass du nichts umstrukturieren musst. Ein Plugin verwendet dieselbe .claude-Form, die du bereits nutzt:

• Ein Ordner pro Skill.
• Eine Markdown-Datei pro Subagent unter agents.
• hooks/hooks.json und .mcp.json, im Plugin-Root.

Die Verzeichnisstruktur erledigt den Großteil der Arbeit. Claude Code entdeckt Komponenten per Konvention.

Das Manifest

Zusätzlich dazu gibt es ein optionales Manifest. Es liegt unter .claude-plugin/plugin.json und enthält Name, Version, Beschreibung und Autor:

{
  "name": "svg-splitter-review",
  "version": "0.1.0",
  "description": "Reviews the SVG Splitter repo",
  "author": {
    "name": "Lewis Menelaws"
  }
}

Das Manifest ist optional. Lass es weg, und Claude Code entdeckt deine Komponenten trotzdem per Verzeichniskonvention. Aber ein paar Details sind es wert zu wissen:

• Name ist das einzige Pflichtfeld. Es setzt deine Skills in einen Namensraum als /plugin-name:skill-name, sodass ein Skill in diesem Plugin als /svg-splitter-review:<skill-name> läuft. Das verhindert, dass deine Skills mit denen anderer kollidieren.
• Versioniere es wie jede andere Abhängigkeit. Das ist es, was Updates und Versionsverfolgung über dein Team hinweg funktionieren lässt.

Das Fazit

Zwei einfache Regeln decken das meiste davon ab:

• Wenn du Plugins nutzt, lies, bevor du installierst. Ein Plugin führt Code mit deinen Rechten aus, also schau dir zuerst seine Hooks, Agenten und MCP-Server an.
• Wenn du eines baust, verpacke dein .claude in dem Moment, in dem es funktioniert. Ein Manifest, eine Installation.

Das ist der ganze Punkt. Eine installierbare Einheit, und das Setup, dem du vertraust, erreicht dein gesamtes Team.