Claude-Code-Plugins bauen: Die Schritt-für-Schritt-Anleitung

Claude Code erledigt die meisten Entwicklungsaufgaben direkt out of the box, aber jedes Team hat eigene Workflows, die Standardfunktionen nicht abdecken. Vielleicht willst du einen individuellen Befehl, der Komponenten in der bevorzugten Struktur deines Unternehmens anlegt, automatisches Linting vor jedem Commit oder einen Schnellzugriff auf die Doku eines Frameworks, mit dem du ständig arbeitest.

Mit Claude-Code-Plugins fügst du diese Features selbst hinzu. Du kannst Community-Plugins installieren oder eigene erstellen.

Wenn du neu bei Anthropic’s agentischem Coding-Tool bist, empfehle ich dir den Guide zu Claude Code oder den Kurs Introduction to Claude Models. Dieses Tutorial setzt voraus, dass du Claude Code installiert hast und für grundlegende Aufgaben nutzt.

Am Ende weißt du, wie du:

• Plugins aus dem Anthropic-Verzeichnis und aus Community-Quellen findest und installierst
• Die drei Komponententypen in Plugins verstehst
• Für unterschiedliche Use Cases den passenden Typ auswählst
• Eigene Plugins baust und teilst

Für einen Überblick über die Fähigkeiten des neuesten Modells von Anthropic lies unseren Guide zu Claude Sonnet 5.

TL;DR

• Claude-Code-Plugins bündeln Skills, MCP-Server und Hooks in teilbare Pakete, die du mit claude plugin add installierst

• Skills werden bei Bedarf geladen (~100 Tokens pro Skill); MCP-Server laden Tool-Definitionen vor (reduziert durch Tool Search); Hooks laufen als Shell-Skripte ohne Tokenkosten

• Nutze Skills für Wissen und Workflows, MCP-Server für Zugriff auf externe APIs und Hooks für Regeln, die ausnahmslos immer greifen müssen

• Bau ein Plugin mit drei Dateien: ein .claude-plugin/plugin.json-Manifest, ein skills/-Verzeichnis und eine SKILL.md-Anleitungsdatei

Was sind Claude-Code-Plugins?

Ein Plugin ist ein Paket, das eine oder mehrere Claude-Code-Erweiterungen für einfaches Teilen und Installieren bündelt. Statt Konfigurationsdateien manuell zwischen Rechnern oder Teammitgliedern zu kopieren, packst du alles in ein Plugin und verteilst es als eine Einheit.

Plugins können drei Arten von Komponenten enthalten:

• Skills: Eigene Befehle, die du mit /skill-name aufrufst, oder kontextabhängige Prompts, die Claude automatisch nutzt, wenn sie passen

• MCP-Server: Verbindungen zu externen Services und APIs, die Claude Zugriff auf Daten geben, die sonst nicht verfügbar wären

• Hooks: Shell-Skripte, die automatisch bei bestimmten Ereignissen laufen, etwa vor dem Bearbeiten einer Datei oder nach einem Commit

Ein Plugin kann nur eine dieser Komponenten enthalten oder mehrere kombinieren, die zusammenarbeiten. Ein „Deployment“-Plugin könnte zum Beispiel einen /deploy-Skill für manuelle Deployments, einen MCP-Server zum Prüfen des Staging-Status und einen Hook, der Tests vor jedem Deployment-Befehl ausführt, bündeln.

Die plugin.json-Manifestdatei definiert, was ein Plugin enthält. Sie legt fest, welche Skills, MCP-Server und Hooks installiert werden, sowie Metadaten wie Name, Version und Autor. Bei der Installation liest Claude Code dieses Manifest und legt jede Komponente am richtigen Ort ab.

Dank dieses Paketformats musst du die interne Dateistruktur von Claude-Code-Erweiterungen nicht kennen. Du installierst das Plugin und alles landet dort, wo es hingehört.

Claude-Code-Plugins finden und installieren

Die meisten Plugins findest du an zwei Orten. Das offizielle Verzeichnis von Anthropic unter claude.com/plugins enthält von Anthropic gebaute Plugins, verifizierte Community-Beiträge und beliebte Drittanbieter-Erweiterungen. Jede Detailseite zeigt die enthaltenen Komponenten, die Kompatibilität und Installationshinweise.

Die zweite Quelle ist GitHub:

Sobald du ein passendes Plugin gefunden hast, hängt der Installationsbefehl vom Speicherort ab:

# Aus dem offiziellen Verzeichnis
claude plugin add @anthropic/deploy-helper
 
# Aus einem GitHub-Repository
claude plugin add github:username/repo-name
 
# Aus einem lokalen Verzeichnis (praktisch während der Entwicklung)
claude plugin add ./my-plugin

Nach ein paar Installationen willst du den Überblick behalten. Der Befehl plugin hilft beim Auflisten, Aktualisieren und Entfernen:

# Alle installierten Plugins anzeigen
claude plugin list
 
# Ein bestimmtes Plugin auf die neueste Version aktualisieren
claude plugin update @anthropic/deploy-helper
 
# Alle Plugins aktualisieren
claude plugin update --all
 
# Ein Plugin entfernen
claude plugin remove @anthropic/deploy-helper

Bei der Installation triffst du auch die Entscheidung zum Geltungsbereich. Plugins können an zwei Orten leben: Im User-Scope werden sie nach ~/.claude/plugins/ installiert und funktionieren in all deinen Projekten, im Projekt-Scope nach .claude/plugins/ innerhalb eines konkreten Repositories.

Standard ist der User-Scope. Um ein Plugin nur für das aktuelle Projekt zu installieren, ergänze das --project-Flag:

claude plugin add @anthropic/deploy-helper --project

Projektbezogene Plugins sind sinnvoll, wenn die Erweiterung an eine bestimmte Codebasis gebunden ist. 

Ein Plugin, das deinen firmeninternen Deployment-Prozess kennt, gehört ins Projekt. Ein Plugin, das Code nach deinen persönlichen Präferenzen formatiert, gehört auf die User-Ebene. Existiert ein Plugin in beiden Scopes, hat die Projektversion Vorrang. So können Teams projektspezifische Konfigurationen durchsetzen, während Entwickler ihre persönlichen Plugins anderswo aktiv lassen.

Den richtigen Claude-Code-Plugin-Typ wählen

Die drei Komponententypen dienen unterschiedlichen Zwecken und verbrauchen Kontextfenster-Tokens unterschiedlich. Wenn du diese Trade-offs verstehst, triffst du für jede Aufgabe die richtige Wahl.

Skills vs. MCP-Server: Der Token-Trade-off

MCP-Server laden zu Beginn jeder Session alle Tool-Definitionen in dein Kontextfenster. Jedes Tool benötigt Name, Beschreibung und vollständiges Parameterschema, typischerweise 100–300 Tokens pro Tool. Ein Setup mit fünf Servern verbraucht rund 55.000 Tokens, bevor du ein Zeichen tippst:

• GitHub: 35 Tools
•  Slack: 11 Tools
• Sentry: 5 Tools
• Grafana: 5 Tools
• Splunk: 2 Tools

Eine Analyse fand Setups mit 7+ Servern und über 67.000 Tokens, also ein Drittel deines 200K-Kontextfensters, weg noch bevor das Gespräch startet.

Skills gehen über progressive Offenlegung anders vor. Zum Session-Start sieht Claude nur den Namen und eine Einzeilenbeschreibung aus dem YAML-Frontmatter, etwa 100 Tokens pro Skill. 

Die vollständigen Anweisungen werden erst geladen, wenn Claude feststellt, dass der Skill für die aktuelle Aufgabe relevant ist. Referenzdateien werden nur bei Bedarf geladen. Und Skripte landen nie im Kontextfenster; Claude führt sie extern aus und nur die Ausgabe kommt zurück.

Anthropic hat dieses Ungleichgewicht Ende 2025 mit Tool Search adressiert, einer Funktion, die Lazy Loading zu MCP-Servern bringt. 

Statt jede Tool-Definition vorzuladen, erkennt Claude Code nun, wenn Toolbeschreibungen mehr als 10% des verfügbaren Kontexts verbrauchen würden, und wechselt auf On-Demand-Laden. 

Interne Tests zeigten, dass der Kontextverbrauch bei großen Tool-Bibliotheken von ~134.000 Tokens auf ~5.000 Tokens fiel. Auch die Tool-Auswahl wurde treffsicherer: Opus 4 stieg von 49% auf 74%, Opus 4.5 von 79,5% auf 88,1% in MCP-Evaluierungen.

So triffst du die Entscheidung.

Skills passen am besten, wenn Claude Zugang zu Wissen oder Workflows haben soll, die es situationsgerecht anwenden kann. Ein Skill mit der Code-Review-Checkliste deines Teams wird beim Review geladen, aber Claude entscheidet anhand des Kontexts, wie jeder Punkt anzuwenden ist. 

Skills sind auch sinnvoll für Operationen, die Skripte für rechenintensive Aufgaben benötigen, weil der Skriptcode außerhalb des Kontextfensters bleibt.

MCP-Server sind ideal, wenn Claude Echtzeitdaten aus externen Services wie Slack-Nachrichten, GitHub-PRs oder Datenbankabfragen braucht. Sie sind auch die richtige Wahl, wenn mehrere KI-Agenten dieselben Tools nutzen sollen oder wenn du Enterprise-Features wie Audit-Logs und explizite Berechtigungen benötigst.

Viele Setups kombinieren beides: Skills liefern das „Wie“ und „Wann“ über Anweisungen in natürlicher Sprache, während MCP-Server die eigentlichen API-Aufrufe übernehmen.

Beliebte Claude-Code-Skills, die sich lohnen

• Superpowers (unser Tutorial): 20+ produktionsbewährte Workflows für TDD, Debugging und strukturierte Planung
• frontend-design: Weist Claude an, generische Ästhetik zu vermeiden und mutige Designentscheidungen zu treffen
• mcp-builder: Leitfaden zum Erstellen von MCP-Servern zur Integration externer APIs
•  webapp-testing: Lokale Webanwendungen mit Playwright für UI-Checks testen
•  skill-creator: Interaktives Tool, das dich Schritt für Schritt beim Bauen neuer Skills begleitet

Beliebte MCP-Server, die sich lohnen

• Context7: Echtzeit-Dokusuche mit Versionsbezug
• GitHub: Repository-Suche, PR-Management, Issue-Tracking
• Playwright: Browserautomation über Accessibility-Trees statt Screenshots
• Supabase: Datenbankabfragen mit Row-Level-Security-Verständnis
• Sentry: Error-Tracking und Performance-Monitoring direkt im Editor

Außerdem findest du in unserem Guide die Top Remote-MCP-Server.

Hooks: Die deterministische Ebene

Hooks stehen außerhalb der Skills-vs.-MCP-Diskussion. Während Skills und MCP-Server Claude-seitig sind (Claude entscheidet, wann sie genutzt werden), sind Hooks systemseitig. Sie feuern bei Events wie PreToolUse oder PostToolUse und führen Shell-Skripte vor oder nach bestimmten Aktionen von Claude aus. Claude hat keinen Einfluss darauf, ob ein Hook läuft.

Damit sind Hooks die richtige Wahl, wenn etwas ohne Ausnahme passieren muss: Linting vor jedem Commit, Schreibschutz für sensible Verzeichnisse, Logging jedes Bash-Befehls oder Tests vor jedem Deployment.

Diese Entwicklerin empfiehlt „block-at-submit“-Hooks statt „block-at-write“-Hooks. Claude mitten in der Aufgabe zu blockieren, verwirrt den Agenten und verschlechtert die Ergebnisse. Ihr Team nutzt einen PreToolUse-Hook, der Bash(git commit) umschließt und auf eine temporäre Datei prüft, die nur existiert, wenn Tests bestanden sind. Keine Datei, kein Commit. Der Agent schließt seine Arbeit ab, die Validierung passiert am Ende.

Hooks verursachen keinerlei Token-Overhead, weil sie als Shell-Skripte außerhalb des Kontextfensters laufen.

Nützliche Claude-Hooks zum Einrichten

• ESLint/Prettier beim Editieren: Dateien automatisch formatieren, nachdem Claude sie geschrieben hat
• Test-Gate beim Commit: Commits blockieren, sofern Tests nicht bestehen
• Geschützte Pfade: Schreibzugriffe auf Migrations-, Config- oder Vendor-Verzeichnisse verhindern
• Benachrichtigung bei Abschluss: Slack- oder Desktop-Alerts senden, wenn lange Tasks fertig sind
• Transkript-Backup: Gesprächsverlauf sichern, bevor Komprimierung greift

Eigene Claude-Code-Plugins bauen

Liegt ein Skill in deinem persönlichen .claude/-Verzeichnis, kannst nur du ihn nutzen. Verpackst du ihn als Plugin, kannst du ihn mit deinem Team teilen oder in mehreren Projekten wiederverwenden.

Wir bauen ein Plugin namens session-logger, das den Befehl /session-logger:summarize hinzufügt. Bei Aufruf analysiert Claude die Unterhaltung und hängt eine strukturierte Zusammenfassung an SESSION_LOG.md an.

Die Plugin-Struktur anlegen

Plugins können überall im Dateisystem liegen. Für dieses Tutorial erstellen wir eines im Home-Verzeichnis:

cd ~
mkdir -p session-logger/.claude-plugin
mkdir -p session-logger/skills/summarize

Das erzeugt:

~/session-logger/
├── .claude-plugin/
│   └── plugin.json  	# Manifest kommt hierhin, sonst nirgendwo
└── skills/
	└── summarize/   	# Ordnername wird zum Befehlsnamen
    	└── SKILL.md 	# muss exakt so heißen

Das Manifest schreiben

Erstelle ~/session-logger/.claude-plugin/plugin.json:

{
  "name": "session-logger",
  "description": "Log session summaries to a markdown file",
  "version": "1.0.0"
}

Das Feld name wird zum Namespace-Präfix. Alle Befehle in diesem Plugin beginnen mit /session-logger:.

Den Skill schreiben

Erstelle ~/session-logger/skills/summarize/SKILL.md:

---
description: Log a summary of the current session to SESSION_LOG.md
disable-model-invocation: true
---
 
When invoked, review the conversation and create a summary with these sections:
 
- **Date/time**: Current timestamp
- **Tasks completed**: What was accomplished
- **Files modified**: List of files created or changed
- **Decisions made**: Architectural or implementation choices
- **Open questions**: Unresolved items for future sessions
 
Append the summary to SESSION_LOG.md in the project root. Create the file if it doesn't exist.

Die Zeile disable-model-invocation: true sagt Claude, dass nur du diesen Skill auslösen kannst. Ohne dieses Flag könnte Claude den Befehl eigenständig starten, wenn es hilfreich erscheint. Für einen Logger oder ein Deployment-Tool willst du in der Regel manuelle Kontrolle.

Lokal testen

Wechsle in ein beliebiges Projekt, in dem du das Plugin nutzen willst, und starte Claude Code mit dem --plugin-dir-Flag auf dein Plugin verweisend:

cd ~/your-project
claude --plugin-dir ~/session-logger

Tippe /session-logger:summarize, um den Befehl aufzurufen. Beachte: Plugin-Befehle erscheinen erst in der Autovervollständigung, wenn du den vollständigen Namen tippst. Der Text wird blau, sobald Claude Code ihn als gültigen Befehl erkennt.

Nachdem du in der Session etwas gearbeitet hast, führe den Befehl aus. Claude prüft die Unterhaltung und hängt einen Eintrag an SESSION_LOG.md im aktuellen Projektverzeichnis an.

Mit anderen teilen

Push dein Plugin zu GitHub. Um es über manuelles Klonen hinaus zu verteilen, füge es einem Plugin-Marktplatz hinzu. Der Marketplace-Guide erklärt, wie du einen eigenen Marktplatz erstellst oder bei bestehenden einreichst.

Fazit

Plugins machen aus Claude Code einen Assistenten, der zu deinem Workflow passt. Der Session-Logger, den wir gebaut haben, war in rund fünf Minuten und drei Dateien fertig. Die meisten nützlichen Plugins sind nicht viel komplexer.

Wenn du mitgemacht hast, läuft jetzt ein funktionierendes Plugin auf deinem Rechner. Probier Anpassungen aus: Ändere das Zusammenfassungsformat, füge neue Abschnitte hinzu oder ersetze es durch etwas, das dein Team wirklich braucht. Die Struktur bleibt gleich – egal, ob du ein persönliches Helferlein oder etwas für Hunderte Entwickler baust.

Schau dir außerdem die Community-Repositories an, wenn du Zeit hast. Anhand echter Beispiele lernst du Muster, die keine Dokumentation so gut vermittelt.

Um tiefer in Claude Code einzusteigen, sieh dir unsere Tutorials zu Best Practices für Claude Code, dem Superpowers-Skill-Framework, Slash-Befehlen für längere Sessions und Security und Berechtigungen an. Wenn du mehr über Claude-Modelle lernen willst, empfehle ich den Kurs Introduction to Claude Models.