Claude Code: Plugins vs Skills vs Subagents — Praxis-Sicht

TL;DR

Claude Code hat fünf Extension-Points: Plugins, Skills, Subagents, Commands, MCP-Server. Die Verwirrung kommt daher, dass sie auf den ersten Blick alle “Claude-Code-erweitern” tun, aber jeweils ein anderes Problem lösen. Hier ist die Entscheidungs-Matrix aus 2 Jahren Conductor-Praxis mit 8 parallelen Projekten:

Wenn du diese fünf Slots im Kopf hast, sind 90% der “Was soll ich nehmen?”-Fragen sofort entschieden.

Featured-Image-Platzhalter: stilisierte Architektur-Übersicht der 5 Extension-Points. Asset folgt — Prompt am Ende des Posts.

Inhaltsverzeichnis

• Die 5 Extension-Points in einem Satz
• Wann nutzt man welchen? Entscheidungs-Matrix
• Plugins: Der Distribution-Layer
• Skills: Pull statt Push
• Subagents: Frischer Kontext für schwere Arbeit
• Commands: Die trockenste Lösung
• MCP-Server: Externe Dienste
• Drei häufige Fehler aus Conductor v1–v8
• Wann gar nichts hinzufügen
• FAQ

Die 5 Extension-Points in einem Satz

Aus der offiziellen Anthropic-Dokumentation zu Claude Code Plugins:

• Custom Command — ein einzelner Slash-Befehl in einer Markdown-Datei. Du tippst /deploy, Claude führt aus, was in /deploy.md steht.
• Skill — ein deklaratives Bündel aus Knowledge + Workflow. Wird von Claude automatisch geladen, wenn der Kontext passt. Du musst es nicht aufrufen.
• Subagent — ein isolierter Sub-Prozess mit eigenem Kontext, eigenen Tools, eigener Aufgabe. Kommt mit einem Ergebnis zurück, danach weg.
• MCP-Server — eine externe Schnittstelle (Datenbank, API, Custom-Tool) die Claude via Model Context Protocol ansprechen kann.
• Plugin — kein eigenständiger Mechanismus, sondern ein Paket das Skills + Subagents + Hooks + MCP-Server in einer installierbaren Einheit bündelt.

Die Verwirrung in den meisten Erklär-Artikeln entsteht daher, dass die ersten vier was sind und das fünfte (Plugin) wie geliefert. Vermische die Frage “was tut es?” nicht mit “wie ist es paketiert?”.

Wann nutzt man welchen? Entscheidungs-Matrix

Aus der Praxis: ich entscheide pro neuer Erweiterung nach genau zwei Fragen.

Inline-Image-Platzhalter: 2x2-Matrix-Diagramm. Asset folgt.

Frage 1: Wer triggert es?

• Ich, explizit per Befehl → Custom Command oder Subagent (je nach Frage 2)
• Claude, automatisch wenn passend → Skill

Frage 2: Wie schwer ist die Arbeit?

• Leicht (Sekunden, einfache Aktion) → Command oder Skill
• Schwer (mehrere Tools, Kontext-isolation nötig) → Subagent

Wenn die Erweiterung einen externen Dienst braucht (z.B. Postgres-DB, Slack-API, GitHub-API über die Standard-Tools hinaus) → MCP-Server, unabhängig vom Rest.

Wenn du mehrere dieser Bausteine zusammen verteilen willst — an Kolleg:innen, an dich-selbst auf einem anderen Rechner, oder an die Community — wickle sie in ein Plugin.

Plugins: Der Distribution-Layer

Plugins wurden in Claude Code 1.0.107 eingeführt (Oktober 2025). Sie sind keine neue Funktion — sie sind die Verpackung für die anderen vier.

Ein Plugin enthält typischerweise:

• 1-20 Skills
• 0-5 Subagent-Definitionen
• 0-3 MCP-Server-Konfigurationen
• 0-N Hooks (PreToolUse, PostToolUse, Stop)
• Eine plugin.json als Manifest

In Conductor v8.1.0 sind 13 Plugins installiert. Jedes ist im Schnitt ~4 Skills + 1-2 Subagents + 1 MCP-Server. Das macht Verteilung trivial:

claude plugin add github:moinsen-dev/claude_code_conductor

Ein einziger Befehl installiert das gesamte Plugin samt aller Sub-Bausteine. Ohne Plugin-Mechanik müsstest du jeden Skill, jeden Subagent, jede MCP-Konfiguration einzeln pflegen.

Wann KEIN Plugin bauen: wenn du nur einen einzelnen Skill oder Command teilst. Plugin-Manifest-Overhead lohnt sich erst ab ~3 zusammengehörigen Bausteinen.

Skills: Pull statt Push

Skills sind die meistunterschätzten der fünf. Sie funktionieren invers zu Commands: bei Skills entscheidet Claude, wann sie geladen werden — nicht du.

Praktisches Beispiel aus Conductor: das auto-test-Plugin enthält einen Skill, der grob sagt “Wenn der Nutzer von Tests spricht, neue Test-Files braucht, oder eine Implementation ohne Tests einreicht — lade dieses Knowledge ein.” Ich rufe das nie explizit auf. Claude entscheidet.

Das hat zwei Konsequenzen:

1. Skill-Beschreibungen müssen präzise sein. Wenn die Beschreibung vage ist, lädt Claude den Skill entweder nie oder zu oft. Beide sind kaputt.
2. Skill-Inhalt sollte kompakt sein. Skills landen in Claude’s aktivem Kontext-Window, sobald sie geladen werden. Ein 5000-Wort-Skill frisst Token-Budget.

Die Anthropic-Doku zu Skills zeigt das Format. Aus meiner Erfahrung: Skills funktionieren nur, wenn die Description-Zeile so trennscharf ist wie ein gut geschriebener Test-Name.

Subagents: Frischer Kontext für schwere Arbeit

Subagents sind die mächtigste — und am häufigsten falsch eingesetzte — Extension. Sie funktionieren nach dem Prinzip aus Anthropics Engineering-Blog zu Context Engineering: “Sub-agents inherit fresh contexts and tools.”

Was das in Praxis heißt:

• Hauptkontext hat 800k Token verbraucht für die laufende Aufgabe
• Du brauchst eine separate Recherche über 50 Code-Files
• Wenn Hauptclaude das selbst macht, frisst die Recherche dein restliches Kontextbudget
• Wenn ein Subagent das macht, läuft die Recherche in einem isolierten Kontext, kommt mit einem 2-Absatz-Ergebnis zurück, und dein Hauptkontext bleibt sauber

In Conductor nutzt das conductor-Plugin Subagents für drei wiederkehrende Patterns:

1. Such-Recherche über viele Files (statt claude direkt zu lassen)
2. Test-Generation für einen ganzen Modul-Strang
3. Cross-Repo-Lookups wenn ich brauche, was in einem anderen Repo passierte

Anti-Pattern: ein Subagent, der eine Konversation führen soll. Subagents haben keine Persistenz zwischen Aufrufen. Sie sind one-shot. Wenn du iterieren willst, brauchst du Claude direkt.

Commands: Die trockenste Lösung

Custom Commands sind die unspektakulärste Option und meine erste Wahl wenn keine der anderen einen klaren Vorteil hat.

Format:

---
description: "Verifies the current build, runs tests, then commits with conventional-commit format"
---

Run the build, then the test suite. If both pass, stage all changes
and commit with a conventional-commit-style message based on the
diff. Don't push.

Speichern als .claude/commands/safe-commit.md. Aufruf: /safe-commit.

Das war’s. Keine plugin.json, kein Subagent-Lifecycle, kein MCP-Server. Eine Markdown-Datei pro Workflow.

Aus Conductor: die ersten zwei Major-Versionen waren nur Commands. v3.0 war der Moment, wo Commands zu eng wurden und Plugins+Skills nötig wurden. Die Regel die ich daraus mitgenommen habe: Starte immer mit Commands. Migriere erst, wenn der Schmerz konkret ist.

MCP-Server: Externe Dienste

MCP ist die einzige Extension-Klasse, die Code ist statt Konfiguration. Ein MCP-Server ist ein laufender Prozess (lokal oder remote), der dem Model Context Protocol folgt und Claude Tools, Resources oder Prompts zur Verfügung stellt.

In Conductor sind aktuell 3 MCP-Server angeschlossen:

1. postgres-mcp für die TimescaleDB des AI Traders
2. github-mcp für Cross-Repo-Operationen jenseits der Standard-gh-CLI
3. conductor-state — Custom-Server, der den gemeinsamen State zwischen den 13 Plugins hält

MCP-Latenz ist real. Pro Tool-Call ~200-500ms (per Beobachtung im Conductor-Setup mit lokalen Servern). Wenn dein Workflow 30 Tool-Calls hintereinander braucht, sind das 10-15 Sekunden Wartezeit zusätzlich. Plane Round-Trips bewusst.

Drei häufige Fehler aus Conductor v1–v8

Diese drei Anti-Patterns habe ich selbst gemacht und in jede Major-Version reinkorrigiert.

Fehler 1: Skill, der ein Subagent sein sollte

In Conductor v4 hatte ich einen “Recherche-Skill”, der Claude auf eine 50-File-Suche schickte. Das Token-Budget des Hauptkontexts wurde aufgefressen, antworten wurden schlechter, Ausgaben langsamer. Fix: in v5 wurde daraus ein Subagent. Token-Verbrauch im Hauptkontext: −60%.

Fehler 2: Command, der ein Skill sein sollte

In Conductor v2 hatte ich /check-tests als Custom Command. Ich tippte ihn 20-mal pro Tag. Fix: in v3 wurde daraus ein Skill mit Description “When user implements a feature without writing tests…”. Seitdem lädt Claude den Workflow automatisch wenn die Situation passt. Tipp-Overhead: −100%.

Fehler 3: MCP-Server, der eine API-Library hätte sein sollen

In Conductor v6 baute ich einen “stocks-mcp” um Yahoo-Finance-Daten in Claude verfügbar zu machen. Aber die Aufrufe waren synchron und blockierten den Agent-Loop. Fix: in v7 ersetzt durch ein Python-Skript, das die Daten cacht; Claude greift via Standard-Bash-Tool darauf zu. Halbe MCP-Komplexität, gleiche Funktion.

Inline-Image-Platzhalter: Stack-Diagramm mit Token-Verbrauch pro Extension-Klasse. Asset folgt.

Wann gar nichts hinzufügen

Diese Sektion fehlt in praktisch allen 10 SERP-Artikeln, die ich für diesen Post durchgesehen habe (siehe Keyword-Recherche für Quellen). Aber sie ist die wichtigste.

Drei Indikatoren, dass dein nächster Plugin/Skill/Command-Reflex nicht der richtige Move ist:

1. Du machst die Aufgabe weniger als 5-mal pro Woche. Plugin-Overhead lohnt sich nicht unter ~250 Aufrufen pro Jahr.
2. Die Aufgabe ist instabil. Wenn der Workflow alle 2 Wochen neue Schritte bekommt, baust du den Skill schneller um als du ihn nutzt. Erst stabilisieren, dann codifizieren.
3. Es gibt schon eine Standard-Lösung. Wenn gh pr create reicht, brauchst du keinen Plugin der das wrapped.

Conductor v8.1.0 hat 13 Plugins — aber das ist über 24 Monate gewachsen. Die ersten 8 Monate liefen mit 2-3 Custom Commands und sonst nichts.

Wo das hingeht

Drei offene Punkte, an denen die aktuelle Extension-Welt von Claude Code knirscht:

1. Skills-Triggering ist undurchsichtig. Es gibt keinen Debug-Modus, der zeigt warum/wann ein Skill geladen wurde. Wenn ein Skill nicht greift, sitzt du im Dunkeln.
2. MCP-Server-Lifecycle. Ein Subagent kann keinen eigenen MCP-Server starten — er erbt nur die des Hauptkontexts. Das limitiert Subagent-Isolation.
3. Cross-Plugin-Dependencies. Wenn Plugin A einen Skill aus Plugin B nutzen will, gibt es kein offizielles Import-Pattern. Workarounds existieren, sind aber alle fragil.

Anthropic wird vermutlich in den nächsten Releases an Punkt 1 und 3 ran — Plugin-System ist sieben Monate alt, viel Iteration kommt noch.

Wenn du selbst mit Claude-Code-Extensions arbeitest oder eigene baust: schreib mir auf LinkedIn oder GitHub. Ich tausche Notes gerne.

FAQ

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

Ein Plugin ist ein Paket. Ein Skill ist ein Inhalt. Ein Plugin kann mehrere Skills enthalten (plus Subagents, Hooks, MCP-Server). Wenn du nur einen Skill teilen willst → kein Plugin nötig. Erst ab 3+ zusammengehörigen Bausteinen lohnt sich ein Plugin.

Wann sollte ich einen Subagent statt eines Skills nutzen?

Wenn die Aufgabe schwer ist (mehrere Tool-Calls, Kontext-isolation nötig) oder wenn sie den Hauptkontext nicht verschmutzen darf (z.B. eine 50-File-Suche, die nur ein 2-Absatz-Ergebnis braucht), nutze einen Subagent. Skills laden in den Hauptkontext; Subagents laufen separat.

Brauche ich für jede Erweiterung einen MCP-Server?

Nein. MCP-Server lohnen sich nur, wenn du einen externen Dienst (DB, API, Custom-Tool) nutzt, der nicht über Claudes Standard-Tools (Bash, Read, Write, etc.) erreichbar ist. Für Python-Skripte oder CLI-Tools reicht Bash. MCP fügt ~200-500ms Latenz pro Call hinzu.

Kann ein Plugin andere Plugins voraussetzen?

Offiziell aktuell nicht. Es gibt keinen dependencies-Schlüssel im Plugin-Manifest, der auf andere Plugins zeigt. Workarounds existieren (man kann Skills explizit aus anderen Plugins triggern), aber das ist fragil. Erwarte hier in den nächsten 6 Monaten eine offizielle Lösung.

Mit welchem Extension-Point sollte ich anfangen?

Custom Command. Eine Markdown-Datei, ein Slash-Befehl, fertig. Migriere erst zu Skill / Subagent / Plugin, wenn der Schmerz konkret ist. Conductors erste 8 Monate liefen mit nur 2-3 Commands.

Geschrieben am 17. Mai 2026 in Hamburg. Diese Matrix entstand aus 2 Jahren produktiver Conductor-Arbeit über 8 Major-Versionen. Wenn du diesen Post hilfreich findest, verlinke ihn — das hilft, dass auch andere ihn finden.