Claude Code Plugins & Marketplace: Dein Setup als Paket

Du hast dir über Wochen ein richtig gutes Claude-Code-Setup gebaut: ein paar handgeschriebene Slash-Commands, einen Subagenten fürs Code-Review, ein, zwei Hooks und vielleicht einen MCP-Server. Alles liegt verstreut in deinem Projekt. Und dann kommt das nächste Projekt – und du fängst von vorne an zu kopieren. Klingt vertraut? Genau hier kommen Claude Code Plugins ins Spiel: Sie bündeln dein komplettes Setup in ein installierbares, versioniertes Paket, das du in jedem Projekt mit einem einzigen Befehl wieder reinholst. In diesem Artikel zeige ich dir, was ein Plugin wirklich ist, wie du es über einen Marketplace installierst, wie du dein eigenes baust – und worauf du bei der Sicherheit achten musst. Wenn du ganz am Anfang stehst, führt dich die Claude Code Anleitung durch Installation und erste Schritte.

Was ist ein Plugin in Claude Code?

Ein Plugin ist ein Container. Es ist die offizielle Antwort auf die Frage „Wie teile ich meine Claude-Code-Konfiguration?“ Statt einzelner Dateien, die du manuell hin- und herschiebst, packst du alles in eine definierte Ordnerstruktur – und Claude Code lädt es als Einheit.

Wichtig zu verstehen: Ein Plugin ist kein Ersatz für deinen .claude/-Ordner. Es ist eine Verteilungsschicht darüber. Deine lokalen Skills und Hooks funktionieren weiter wie bisher. Das Plugin ist einfach die Verpackung, mit der du sie transportierst – vom Laptop ins Team, vom Team in die Community.

Diese Bausteine kann ein Plugin bündeln

• Skills – Fähigkeitspakete mit Anleitungen und Ressourcen. Sie liegen unter skills/<name>/SKILL.md und bekommen automatisch ein Namespace-Präfix: /mein-plugin:review. Damit ist Namenskollisionen ein für alle Mal der Riegel vorgeschoben.
• Subagenten – spezialisierte Agenten mit eigenem System-Prompt und eigenem Modell. Liegen als Markdown in agents/, aufgerufen mit @mein-plugin:security-reviewer. Im Frontmatter legst du Name, Beschreibung, Modell, maxTurns oder erlaubte Tools fest.
• Hooks – Skripte, die automatisch bei Events laufen. Rund 25 Events stehen zur Verfügung, von SessionStart über PreToolUse und PostToolUse bis FileChanged. Der Linter nach jedem Edit? Genau das.
• MCP-Server – Anbindungen an externe Tools über eine .mcp.json im Plugin-Root. Die starten automatisch, sobald du das Plugin aktivierst.
• LSP-Server – über eine .lsp.json holst du dir echte Code-Intelligenz in Echtzeit. Anthropic liefert im offiziellen Marketplace fertige LSP-Plugins für TypeScript, Python, Rust, Go, PHP, Java und mehr.
• Background Monitors und Themes – noch experimentell, aber charmant: Monitore beobachten Logs oder Dateien im Hintergrund, Themes bringen eigene Farbschemata für /theme mit.

Der große Vorteil: Ein Kollege oder ein Kunde installiert dein Plugin und hat sofort dasselbe Setup wie du – ohne lange README abzuarbeiten. Du versionierst es über Git, pushst ein Update, und alle ziehen nach. Das ist der Unterschied zwischen „ich hab da mal was gebastelt“ und einem teilbaren Produkt.

Plugin oder doch lieber Standalone?

Diese Frage kommt sofort, und die Antwort ist erfrischend unkompliziert. Für ein schnelles Experiment ist ein Plugin wie mit Kanonen auf Spatzen zu schießen. Ein Skill in deinem .claude/-Ordner reicht völlig. Sobald du das Ding aber zum zweiten Mal kopierst, ist der Punkt erreicht.

• Verfügbarkeit: Standalone nur im aktuellen Projekt – Plugin projektübergreifend und über Marketplace.
• Aufruf: Standalone kurz mit /hello – Plugin namespaced mit /mein-plugin:hello.
• Versionierung: Standalone gar keine – Plugin semantisch versioniert (ohne version-Feld nimmt Claude Code den Git-SHA).
• Updates: Standalone manuell kopieren – Plugin per /plugin marketplace update.

Der eigentliche Zauber entsteht sowieso erst im Bündel – ein MCP-Server plus die passenden Skills plus der dazugehörige Agent plus die Hooks. Einzeln käme das nie so sauber zusammen.

Was sich seit dem Launch getan hat

Plugins gibt es seit dem 9. Oktober 2025, eingeführt mit Claude Code v2.0.12. Anthropic hat sie damals selbst als „App Store ohne Gatekeeper“ positioniert: Jedes Git-Repo mit der richtigen Manifest-Datei ist ein Marktplatz. Kein Review, keine zentrale Qualitätskontrolle – dazu unten mehr.

Seitdem ist verdammt viel passiert. Plugin-Dependencies kamen dazu, die LSP-Plugins, Themes und Background Monitors. Später konntest du Plugins als ZIP testen (--plugin-dir ./x.zip), es kam ein displayName-Feld samt Anzeige der Context-Kosten, ein defaultEnabled-Flag und mit claude plugin init ein echter Schnellstart. Und die Ökosystem-Zahlen? Über 4.600 indexierte Plugin-Repos und zwei offizielle Anthropic-Marketplaces. Das Ding ist längst kein Nischenfeature mehr.

Plugins verwalten mit /plugin

Die zentrale Schaltstelle für alles ist der Slash-Command /plugin. Tippst du ihn ohne Argumente in Claude Code ein, öffnet sich ein interaktives Menü mit vier Tabs: Discover zum Stöbern, Installed für alles, was schon da ist, Marketplaces für deine Quellen und Errors, wenn mal was klemmt. Letzteres ist Gold wert, wenn ein Hook nicht zündet und du nicht weißt, warum.

Für den schnellen Weg gibt es Unterbefehle, die du direkt absetzt, ohne durchs Menü zu klicken:

/plugin list
/plugin enable code-review@dein-team
/plugin disable code-review@dein-team
/plugin uninstall code-review@dein-team
/reload-plugins

/reload-plugins ist übrigens der Befehl, den du dir merken solltest. Änderst du während der Entwicklung einen Skill, lädt Claude Code ihn nicht automatisch neu – du arbeitest dann fröhlich gegen die alte Version und wunderst dich. Ein Reload, und alles ist gut.

Einen Marketplace hinzufügen und ein Plugin installieren

Plugins kommen aus einem Marketplace. Das klingt nach App Store, ist in der Praxis aber meistens einfach ein Git-Repository (ein Online-Speicherort für Code, etwa auf GitHub), in dem ein oder mehrere Plugins liegen plus eine Manifest-Datei, die sie auflistet. Schöner Nebeneffekt: Jeder kann einen Marketplace betreiben – du, dein Team, die Open-Source-Community.

Bevor du installieren kannst, musst du Claude Code sagen, woher das Plugin kommt. Du fügst also zuerst die Quelle hinzu. Das geht über die GitHub-Kurzschreibweise, eine volle Git-URL, einen lokalen Pfad oder eine remote gehostete marketplace.json:

/plugin marketplace add dein-team/claude-plugins
/plugin marketplace add https://github.com/dein-team/claude-plugins.git
/plugin marketplace add ./lokaler-marketplace

Danach kennt Claude Code die Quelle und zeigt dir, welche Plugins darin angeboten werden. Installiert wird gezielt nach Name in der Schreibweise plugin-name@marketplace-name, damit eindeutig ist, woher das Ding stammt:

/plugin install code-review@dein-team

Scopes: Wer bekommt das Plugin?

Ein Detail, das viele überlesen – und das im Team den Unterschied macht. Claude Code kennt vier Scopes:

• user – landet in ~/.claude/settings.json, gilt für dich überall. Das ist der Standard.
• project – landet in .claude/settings.json und wandert per Git ins Team. Damit hat jeder im Projekt automatisch dieselben Plugins.
• local – in .claude/settings.local.json, gitignored. Deine private Spielwiese im Projekt.
• managed – read-only, von der Admin-Seite gesetzt. Enterprise-Terrain.

claude plugin install wp-quality@kus --scope project

Der offizielle Marketplace

Den musst du nicht mal hinzufügen: claude-plugins-official ist automatisch registriert. Drin findest du die erwähnten LSP-Plugins, fertige Integrationen für GitHub, GitLab, Figma, Vercel, Firebase, Supabase, Slack, Sentry und Jira sowie Workflow-Plugins wie commit-commands, pr-review-toolkit und plugin-dev. Dazu ein security-guidance-Plugin und ein paar Output Styles.

Willst du breiter stöbern, holst du dir den Community-Marktplatz dazu:

/plugin marketplace add anthropics/claude-plugins-community

Ein Wort der Warnung schon hier: Anthropic prüft Community-Plugins nicht. Der Name im Repo ist keine Qualitätsgarantie.

Ein eigenes Claude Code Plugin bauen

Jetzt der spannende Teil: dein eigenes Plugin. Das ist weniger Magie, als du denkst. Im Kern brauchst du einen Ordner mit einem Manifest und darunter die Bausteine, die du teilen willst. Das Herzstück ist die Datei .claude-plugin/plugin.json – sie macht aus einem beliebigen Ordner ein erkennbares Plugin.

Die Ordnerstruktur

mein-plugin/
├── .claude-plugin/
│   └── plugin.json          # Manifest - EINZIGE Datei hier drin!
├── skills/
│   └── review/SKILL.md      # Skill, Aufruf: /mein-plugin:review
├── agents/
│   └── reviewer.md          # Subagent
├── hooks/
│   └── hooks.json           # Hook-Definitionen
├── .mcp.json                # MCP-Server
├── .lsp.json                # LSP-Server
├── bin/                     # Executables, landen im Bash-PATH
└── README.md

Merk dir bitte diesen einen Satz, er erspart dir eine Stunde Fluchen: In .claude-plugin/ gehört ausschließlich die plugin.json. Alle anderen Ordner – skills/, agents/, hooks/ – liegen im Plugin-Root. Packst du sie ins Manifest-Verzeichnis, werden sie schlicht nicht geladen. Kein Fehler, keine Warnung, einfach nichts. Das ist der Klassiker unter den Anfängerfehlern.

Das Manifest plugin.json

Das Manifest ist schlank. Pflicht ist eigentlich nur der Name (Kebab-case, er dient gleichzeitig als ID und Namespace). Alles andere sind Metadaten, die im Marketplace angezeigt werden:

{
  "name": "wp-quality",
  "displayName": "WordPress Quality Toolkit",
  "version": "1.2.0",
  "description": "Code-Review, Performance-Check und Deploy-Hooks für WordPress-Projekte.",
  "author": {
    "name": "Rafael Luge",
    "url": "https://kopfundstift.de"
  },
  "license": "MIT",
  "keywords": ["wordpress", "review", "performance"],
  "defaultEnabled": true
}

Ein Tipp aus der Praxis: Setz das version-Feld. Lässt du es weg, nimmt Claude Code den Git-SHA – und dann ist jeder Commit eine neue Version. Für dich als Entwickler egal, für dein Team ein Albtraum, weil niemand mehr sagen kann, welchen Stand er eigentlich fährt.

Übrigens: Streng genommen ist das Manifest sogar optional. Ein Ordner mit den Standardverzeichnissen wird auto-erkannt, der Name kommt dann vom Ordnernamen. Für alles, was du teilst, würde ich es trotzdem immer schreiben.

Schritt für Schritt zum ersten Plugin

So gehe ich selbst vor, wenn ich ein neues Plugin aufsetze:

1. Ordner anlegen, .claude-plugin/plugin.json mit Name, Beschreibung, Version und Author füllen.
2. Einen einzigen Skill bauen: skills/hello/SKILL.md mit einer klaren description im Frontmatter. Die Beschreibung ist wichtiger, als du denkst – daran erkennt Claude, wann der Skill überhaupt greifen soll.
3. Lokal testen mit claude --plugin-dir ./mein-plugin, dann /mein-plugin:hello Rafael aufrufen. Änderungen? /reload-plugins.
4. Hook ergänzen und in hooks/hooks.json definieren.
5. Validieren mit claude plugin validate ./mein-plugin. In der CI dann mit --strict.
6. README schreiben, Version taggen, ab ins Repo.

Noch schneller geht es mit claude plugin init mein-tool. Das legt dir das Gerüst unter ~/.claude/skills/mein-tool/ an und lädt es automatisch als mein-tool@skills-dir. Perfekt für den lokalen Prototypen, bevor du dich um Repo und Marketplace kümmerst.

Der wichtigste Kniff: ${CLAUDE_PLUGIN_ROOT}

Beim Installieren wird dein Plugin in einen Cache unter ~/.claude/plugins/cache kopiert. Heißt: Alle hartcodierten Pfade und alle ../-Konstrukte fliegen dir um die Ohren, weil das Plugin plötzlich woanders liegt. Sie zeigt immer auf das echte Plugin-Verzeichnis – egal, wo es gerade liegt. Damit habe ich die besten Erfahrungen gemacht, und es ist der Unterschied zwischen „läuft bei mir“ und „läuft überall“.

Deinen eigenen Marketplace bauen

Ein Marketplace ist ein Git-Repo mit einer .claude-plugin/marketplace.json. Mehr nicht. Ehrlich.

{
  "name": "kus",
  "owner": { "name": "Kopf und Stift" },
  "plugins": [
    {
      "name": "wp-quality",
      "source": "./plugins/wp-quality",
      "description": "WordPress Code-Review und Performance-Checks.",
      "version": "1.2.0"
    },
    {
      "name": "deploy-tools",
      "source": { "source": "github", "repo": "kopfundstift/deploy-tools" }
    }
  ]
}

Als Quelle kannst du einen relativen Pfad im selben Repo nutzen, ein GitHub-Repo, eine beliebige Git-URL, ein Unterverzeichnis eines Repos (git-subdir) oder sogar ein npm-Paket. Push zu GitHub, fertig – ab da bindet jeder deinen Marketplace mit /plugin marketplace add dein-team/claude-plugins ein. Bei privaten Repos brauchst du für automatische Updates einen GITHUB_TOKEN.

Zwei Dinge noch: Ein paar Namen sind reserviert und funktionieren nicht (claude-plugins-official, claude-plugins-community, alles mit anthropic- und einige mehr). Und im Team trägst du bekannte Marktplätze am besten direkt über extraKnownMarketplaces in die .claude/settings.json ein – dann muss niemand händisch etwas hinzufügen.

Diese Fehler kosten dich Nerven

• Ordner falsch platziert: skills, agents und commands in .claude-plugin/ → werden nicht geladen.
• Keine version: jeder Commit wird zur neuen Version.
• Pfade hartcodiert: ohne ${CLAUDE_PLUGIN_ROOT} bricht alles nach der Installation.
• Marketplace entfernt: /plugin marketplace remove deinstalliert auch alle zugehörigen Plugins. Kein Rückfrage-Popup rettet dich.
• Context-Kosten ignoriert: Jedes aktive Plugin frisst Tokens – bei jedem Turn. Schau regelmäßig mit /usage drauf und deaktiviere, was du gerade nicht brauchst.

Sicherheit: Was du vor der Installation wissen solltest

Ein Plugin ist mächtig – und genau deshalb ein potenzielles Einfallstor. Es kann Skills mitbringen, die Shell-Befehle ausführen, Hooks, die bei jedem Edit Code laufen lassen, und MCP-Server, die mit externen Systemen reden.

Dass das keine Theorie ist, zeigen zwei dokumentierte Schwachstellen, die Check Point Research öffentlich gemacht hat:

• CVE-2025-59536 (CVSS 8.7): Hooks aus einem geklonten Repo wurden schon beim Öffnen automatisch ausgeführt. Remote Code Execution, nur weil du ein Projekt aufmachst. Gefixt durch deutlich strengere Trust-Prompts.
• CVE-2026-21852 (CVSS 5.3): Eine .mcp.json konnte Init-Befehle noch vor dem Trust-Dialog ausführen – inklusive Umleitung von API-Traffic und potenziellem Diebstahl des API-Keys. Gefixt: Die API bleibt blockiert, bis du Vertrauen bestätigt hast.

Dazu kommen die üblichen Verdächtigen: Prompt-Injection über manipulierte MCP-Antworten und Supply-Chain-Angriffe über npm-Abhängigkeiten. Das muss dich aber nicht lähmen! Behandle Plugins einfach wie jede andere Dependency:

• Quelle prüfen. Installiere aus Marketplaces, die du kennst oder deren Repo du einsehen kannst. Lies die Hooks, bevor du auf Install gehst – das ist der sensibelste Teil.
• Auf Commit-SHAs pinnen. Dann bringt dir kein Auto-Update über Nacht fremden Code rein.
• settings.json inspizieren, bevor du ein unbekanntes Projekt öffnest.
• claude --safe-mode nutzen, wenn du in fremdem Terrain unterwegs bist.
• Im Team: privater, kuratierter Marketplace, Code-Review für jedes Plugin, strictKnownMarketplaces in den Managed Settings. So kontrolliert ihr zentral, was ins Setup darf.

Und wenn du selbst baust: Hooks in exec-Form schreiben statt als Shell-String (Shell-Injection lässt grüßen), sensible Werte über userConfig mit "sensitive": true in die Keychain legen – niemals im Klartext. Kurz: Vertrauen ist die Währung. Ein Plugin spart dir enorm viel Zeit, aber nur, wenn du weißt, was drinsteckt.

Fazit

Claude Code Plugins lösen das nervigste Problem fortgeschrittener Nutzer: Setups, die in einem einzelnen Projekt gefangen sind. Sobald du Skills, Subagenten, Hooks und MCP-Server in ein Plugin packst, wird aus deiner Bastelei ein wiederverwendbares, teilbares Paket. Über /plugin verwaltest du alles, über einen Marketplace verteilst du es, und mit einer schlanken plugin.json baust du in wenigen Minuten dein erstes eigenes.

Mein Rat: Geh deine letzten Projekte durch, sammel die zwei, drei Dinge ein, die du immer wieder kopierst, und gieß sie in dein erstes Plugin. Nimm dir das plugin-dev-Plugin aus dem offiziellen Marketplace dazu, das führt dich sauber durch den Prozess. Du wirst dich beim nächsten Projektstart bei dir selbst bedanken.

FAQ