Skills, Subagents, MCP und Plugins in Claude Code: Was soll man wählen
MarkdownEntscheidungsmatrix und Projektbeispiele für Skills, Subagents, MCP und Plugins in Claude Code: die passende Ebene wählen, Plugins installieren und fünf Fehler vermeiden.
Vollständigen Artikel lesen
Derzeit gibt es in Claude Code fünf Möglichkeiten, dieselbe Code-Review durchzuführen: einen Slash-Befehl, einen Skill, einen Subagent, ein Plugin oder einfach einen Prompt im Chat. Und keine dieser Möglichkeiten ist standardmäßig besser als eine andere – die Wahl hängt von der Aufgabe, dem Token-Budget und davon ab, wer außer dir sie nutzen wird.
Diese Anleitung hätte ich mir vor einem Jahr selbst gegeben. Ein Entscheidungsbaum mit 4 Fragen, eine fertige Matrix „Aufgabe → Ebene“ und 5 häufige Fehler, die bei allen Vibe-Codern, mit denen ich arbeite, Tokens verbrauchen.
Zur Arbeit mit dem Dienst siehe die Ailoot-Dokumentation.
Was sind Skills, Subagents, MCP und Plugins in einem Satz?
Das Wichtigste
Ein Skill ist eine verpackte Methodik, die Claude lädt, wenn sie ausgelöst wird. Ein Subagent ist ein isolierter „Kollege“ mit eigenem Kontext für eine lange Aufgabe. MCP ist eine Brücke zu einem externen System (einer Datenbank, GitHub, Notion). Ein Plugin ist ein fertiges Paket aus all dem von jemand anderem, das mit einer einzigen Zeile installiert wird.
Bevor wir auswählen, sollten wir die Begriffe unterscheiden. Alle vier Ebenen verfolgen ein Ziel: die Möglichkeiten von Claude über die Standardfunktionen hinaus zu erweitern. Doch jede Ebene hat ihre eigene Natur.
Skill ist ein Verzeichnis mit einer Datei SKILL.md, in der beschrieben wird, wann und wie eine bestimmte Methodik anzuwenden ist. Anthropic vergleicht einen Skill mit Anweisungen für einen neuen Mitarbeiter: Man diktiert ihm nicht jeden Tag jeden Schritt, sondern gibt ihm ein Verfahren an die Hand.
Subagent ist eine separate Claude-Sitzung mit eigenem Kontext, die aus der Hauptkonversation gestartet wird. Sie hat ein entscheidendes Merkmal: Isolation. Ein Subagent kann 30 Dateien lesen, eine Zusammenfassung erstellen und nur diese an den Hauptchat zurückgeben. Der Kontext der Hauptkonversation bleibt sauber.
MCP (Model Context Protocol) ist ein offener Standard von Anthropic, um Claude mit externen Systemen zu verbinden. In einem Blogbeitrag vom 13. November 2025 erklärte Anthropic den Unterschied so klar wie möglich:
MCP verbindet Claude mit Daten; Skills bringen Claude bei, was es mit diesen Daten tun soll. Wenn du erklärst, wie man ein Tool verwendet oder Verfahren befolgt – zum Beispiel „bei Datenbankabfragen immer zuerst nach Datumsbereich filtern“ –, ist das ein Skill. Wenn Claude überhaupt erst Zugriff auf die Datenbank oder Excel-Dateien haben soll, ist das MCP.
Plugin ist ein fertiges Paket aus Skills, Subagents, Hooks und Befehlen von jemand anderem, verpackt in einem Marketplace. Installiere es mit einer einzigen Zeile über /plugin install, und du erhältst alles auf einmal. Wenn ein Skill dein eigenes Verfahren ist, ist ein Plugin ein Verfahren, das du von einem anderen Unternehmen gekauft hast.
Kurz gesagt: Skills sind Rezepte, Subagents sind spezialisierte Kollegen, und MCP stellt externe Tools bereit, über die Claude auf Dienste und Daten zugreifen kann. Die Token-Kosten unterscheiden sich: Ein Skill ist am günstigsten (er wird bei Auslösung geladen), während MCP deutlich teurer ist (jeder verbundene Server belegt ständig Platz im Kontextfenster).
Warum 4 Ebenen, wenn man auch eine einzige CLAUDE.md verwenden kann?
Das Wichtigste
CLAUDE.md ist eine Bitte: Claude liest die Datei zu Beginn einer Sitzung und kann sie nach 20 Nachrichten ignorieren. Skills, Subagents, MCP und Plugins lösen, was CLAUDE.md nicht kann: Skalierung, Kontextisolation, Zugriff auf die Außenwelt und das Teilen von Methodik mit einem Team.
Im beschriebenen Projekt ist CLAUDE.md eine große Regelübersicht: Wo Dinge hingehören, wie veröffentlicht wird und welche Vereinbarungen gelten. Ohne diese Datei würde Claude jede neue Sitzung wieder ganz von vorn beginnen.
Aber CLAUDE.md hat eine Obergrenze. Ich erkläre es anhand von drei Situationen, in denen die Datei nicht mehr funktioniert.
Situation 1: Eine Regel funktioniert nur manchmal. In CLAUDE.md steht: „Vor git push immer npm run build ausführen.“ Claude liest die Datei zu Beginn der Sitzung, nickt, schreibt nach 25 Nachrichten Code und vergisst es. Ich habe mich schon dreimal dabei erwischt, ohne Build zu pushen; diese Pushes scheiterten in der Produktion. Ein richtig eingerichteter und getesteter Hook kann deterministisch den Build prüfen und die abgedeckte Operation ablehnen. Seine Reichweite hängt von Ereignis und Toolpfad ab. Ein Claude-Code-Hook erfasst nicht automatisch jeden Push eines anderen Terminals oder einer Anwendung. Prüfe, dass ein absichtlich fehlschlagender Build deinen tatsächlich genutzten Weg blockiert.
Situation 2: Ein 15-stufiger Prozess, der sich wiederholt. Im beschriebenen Beispiel durchläuft jede Anleitung 14 Phasen: Recherche → Struktur → MDX → 7 parallele QA-Prüfungen → Veröffentlichung in der Produktion → IndexNow. Wenn ich jedes Mal einen Prompt schreibe wie „Führe Phase 1 aus, dann 2, dann 3“, verbrauche ich Tokens, bevor ich überhaupt angefangen habe. Deshalb ist der gesamte Workflow im Skill build-masterskaya-guide verpackt – ein 34 KB großer Satz von Anweisungen, der mit dem Satz „Lass uns eine neue Anleitung für das Projekt erstellen“ gestartet wird.
Situation 3: Eine Aufgabe verschlingt den Kontext. Um eine bereits veröffentlichte Anleitung auf Aktualität zu prüfen, muss Claude ein 30 KB großes Livestream-Transkript und 20 Retrospektiven von je 5 KB lesen und mit der aktuellen Website vergleichen. Wenn ich das im Hauptchat mache, habe ich am Ende der Prüfung 200K Tokens Ballast im Kontext. Ein Subagent erledigt dieselbe Arbeit, gibt eine Zusammenfassung mit nur 300 Wörtern an die Hauptkonversation zurück und wird beendet.
Situation 4: Ich möchte, dass das Team dieselben Vorlagen wie ich erhält. Ein fertiger Regelsatz für Frontend-Design, Hooks für die Veröffentlichung über Coolify, MCP für Playwright-Prüfungen. Das ist ein Plugin: Ich verpacke mein Setup, veröffentliche es im Marketplace, und ein Kollege installiert es mit einer einzigen Zeile.
CLAUDE.md deckt die Grundlagen ab: „So machen wir das hier.“ Die 4 zusätzlichen Ebenen decken ab, was CLAUDE.md physisch nicht leisten kann: Wiederholungen über Trigger, Kontextisolation, Zugriff auf die Außenwelt und gemeinsames Nutzen.
Wann braucht man einen Skill statt CLAUDE.md?
Das Wichtigste
Ein Skill ist die richtige Wahl, wenn es einen wiederholbaren Prozess mit einem klaren Auslöser gibt und du ihn mehr als einmal am Tag ausführst. Anders als CLAUDE.md wird ein Skill nur bei Bedarf geladen und verbraucht nicht in jeder Sitzung grundlegende Kontext-Tokens.
Der Test für einen Skill ist einfach: Du ertappst dich dabei, denselben langen Prompt aus deinen Notizen in den Chat zu kopieren. Das dritte Mal ist bereits ein Signal.
Derzeit habe ich 7 Verzeichnisse in ~/.claude/skills/: build-masterskaya-guide, build-vc-spoke, build-reel-script, build-practicum-instruction, update-config, simplify und keybindings-help. Am häufigsten verwende ich build-masterskaya-guide (diese Anleitung wurde damit geschrieben). Darin stecken 34 KB Methodik: welche Phasen durchlaufen werden, welche Multi-Agent-QA-Prüfungen ausgeführt werden, welche Gate-Bedingungen den Prozess anhalten sollten und welche Artefakte in /tmp/ gespeichert werden sollen.
Wann man keinen Skill erstellen sollte.
- Eine Regel wie „Antworte in der vom Nutzer bevorzugten Sprache“ gehört in CLAUDE.md, nicht in einen Skill. Ein Skill wird bei Auslösung geladen, aber diese Regel sollte immer gelten.
- Eine einmalige Anweisung wie „Führe das Refactoring jetzt aus“ gehört in den Chat, nicht in einen Skill.
- Eine Aufgabe mit eigenem Kontext kann einen Subagenten nutzen. Folgt sie zugleich einem wiederkehrenden Verfahren, bewahre dieses als Skill auf.
Das wichtigste Anti-Pattern. Der häufigste Fehler von Vibe-Codern ist, ein Verfahren in einen Subagent zu stopfen, obwohl es ein Skill sein sollte. Ein Subagent kostet mehr Tokens (er hat einen eigenen Kontext), startet langsamer und ist oft überdimensioniert. Wenn die Aufgabe in 1.500–2.000 Wörter Methodik passt, ohne externe Dateien zu lesen, ist sie ein Skill.
Wie man einen Skill strukturiert, was in die Frontmatter gehört und welche Trigger-Phrasen funktionieren, steht in der Anleitung Claude-Code-Skills 2026: So baust du eine persönliche Skills-Bibliothek.
Wann braucht man einen Subagent statt eines Skills?
Das Wichtigste
Ein Subagent verlagert umfangreiche Arbeit in seinen eigenen Kontext und gibt nur eine Zusammenfassung an den Hauptchat zurück. Verwende ihn, wenn die Aufgabe das Lesen vieler Dateien, eine lange Analyse oder 5 identische parallele Prüfungen erfordert – und du nicht den ganzen Zwischenstand im Hauptchat sehen musst.
Ein Skill speichert die Methodik; ein Subagent erledigt die Arbeit. Es sind unterschiedliche Ebenen, die oft verwechselt werden, weil beide „aus dem Chat“ gestartet werden.
Ein Subagent ist nur für Kontextisolation sinnvoll. Die Hauptsitzung von Claude hat ein Budget von 200.000 Tokens (oder 1 Million in der Beta). Wenn du den Hauptchat bittest, 30 Dateien zu lesen und jede zu analysieren, verbrauchst du die Hälfte des Kontextfensters mit Zwischenlektüre. Ein Subagent erledigt dieselbe Arbeit in einer separaten Sitzung und gibt nur das Ergebnis an den Hauptchat zurück.
Ein konkretes Projektbeispiel. Jede Anleitung durchläuft mehrere parallele QA-Prüfungen: Stil, Zitate und Fakten anhand von Primärquellen, Struktur für Suchmaschinen sowie Integrität interner und externer Links. Jede Prüfung braucht ihren eigenen Kontext: ein Regelglossar, WebFetch für Dutzende von URLs und Greps im Text.
Wenn ich all diese Prüfungen in einem Chat ausführen würde, wäre der Kontext schon erschöpft, bevor die erste Prüfung abgeschlossen ist. Subagents parallel mit run_in_background: true zu starten, löst das: Sie arbeiten im Hintergrund, der Hauptchat macht weiter, und nach 4–6 Minuten erhalte ich kompakte Berichte und setze die Änderungen um.
Ein zweites Beispiel – umfangreiche Recherche. Wenn ich ein Thema für eine neue Anleitung auswähle, sammeln 4 Subagents parallel Signale:
- V1 - Foren und Communities über 14 Tage
- V2 - soziale Netzwerke
- V3 - Videoplattformen + Anthropic-Blog
- V4 - SEO-Lücken
Jeder liefert 30–40 Elemente mit Viralitätsbewertungen zurück. Ich fasse sie in einem Pool zusammen, gewichte sie anhand von 9 Dimensionen und wähle einen Gewinner aus. Ohne Subagents würde sich diese Phase auf 2–3 Stunden ausdehnen und den Hauptkontext verbrauchen.
Wann man keinen Subagent erstellen sollte.
- Eine Aufgabe, die weder das Lesen von Dateien noch WebFetch erfordert, gehört in den Hauptchat.
- Ein wiederkehrendes Verfahren gehört in einen Skill, kann bei nützlicher Isolation aber in einem Subagenten laufen.
- Externer Zugriff braucht ein genehmigtes Tool wie MCP oder CLI. Ein Subagent kann dieses bei delegierter Arbeit nutzen.
Das wichtigste Anti-Pattern. Einen Subagent namens backend-engineer oder qa erstellen und hoffen, dass Claude selbst herausfindet, wann er ihn verwenden soll. Spezifische Subagents (zum Beispiel migration-test-writer oder api-route-reviewer) liefern deutlich bessere Qualität als allgemeine. Je genauer Name und Anweisungen des Subagents sind, desto präziser wählt Claude den passenden aus.
Wie man Subagents für bestimmte Aufgaben erstellt, Syntax der Frontmatter und 5 fertige Beispiele stehen in der Anleitung Claude-Code-Subagents 2026: Eine Schritt-für-Schritt-Anleitung.
Wann braucht man MCP statt eines Skills oder Subagents?
Das Wichtigste
MCP liefert Tools und Datenzugang für Systeme wie Datenbanken, GitHub, Sentry oder Browser. Nutze es für benötigten Zugriff. Ein Skill kann die Methodik für dieselben Tools liefern; beide Ebenen ergänzen sich.
Anthropic gab die kürzeste Formel für den Unterschied in einem Blogbeitrag: MCP verbindet Claude mit Daten; Skills bringen Claude bei, was es mit diesen Daten tun soll.
Ein Skill zur GitHub-Issue-Prüfung braucht den Issueinhalt. Liefere ihn über genehmigtes MCP, CLI oder bereitgestellten Text. Der Skill definiert Prüfung und Ergebnisstruktur. MCP-Zugriff allein schreibt dieses Verfahren nicht vor.
Mein konkreter MCP-Stack.
- Playwright MCP - visuelle QA für jede Anleitung. Seite auf Desktop und Mobilgerät öffnen, Containerbreite und Darstellung der Blöcke prüfen.
- Stitch MCP - Zugriff auf das Designsystem, Komponenten im Markenstil generieren.
- vidIQ MCP - Trendanalyse und Ideen auf Viralität prüfen.
- Railway MCP - Bereitstellungsinfrastruktur verwalten.
Jeder dieser 4 Server ist eine Brücke zu einem externen System. Ohne MCP müsste ich entweder meinen eigenen Wrapper-Code schreiben oder zu einem Browser wechseln. Mit MCP passiert alles innerhalb der Claude-Sitzung.
Token-Kosten. MCP ist die teuerste Ebene. Jeder verbundene Server belegt ständig Platz im Kontextfenster: Tool-Deklarationen, Argument-Schemas und Beschreibungen. Ich habe 4 MCP-Server – das sind etwa 8–12K Tokens in jeder neuen Sitzung, bevor ich überhaupt etwas gefragt habe.
Das bedeutet: Wir verbinden MCP nur, wenn es in den meisten Sitzungen tatsächlich gebraucht wird. Wenn du Sentry MCP einmal pro Woche verwendest, ist es besser, es bei Bedarf mit dem Flag --mcp sentry zu aktivieren, statt es dauerhaft in der Liste zu behalten.
Wann man MCP nicht verwenden sollte.
- Methodik zum Thema „wie man mit Daten arbeitet“ gehört in einen Skill, nicht zu MCP.
- Eine lange Leseaufgabe kann von einem Subagenten profitieren. Liegen Dateien oder Datensätze extern, kann er zusätzlich MCP-Zugriff benötigen.
- Eine Veröffentlichung mit einem einzigen Befehl erfordert einen Hook oder ein Plugin, nicht MCP.
Das wichtigste Anti-Pattern. Einen MCP-Server für etwas bauen, das sich besser mit einem Skill erledigen lässt. In einer HN-Diskussion habe ich ein Beispiel gesehen (genau jener Thread mit 422 Punkten am 27. Mai): Der Autor schrieb einen MCP-Server, der „Code-Review-Anweisungen“ bereitstellt. Doch das ist kein Zugriff auf die Außenwelt, sondern ein Verfahren. Ein Skill erledigt dasselbe mit 10-mal weniger Tokens.
Ein Vorfall mit konkurrierenden Ressourcen. Einmal hing Playwright MCP mit dem Fehler „Browser is already in use“ fest – gleichzeitig war ein Chrome-Fenster geöffnet, und MCP konnte den Browser nicht übernehmen. Das ist eine wichtige Lektion: Ein MCP-Server verwendet gemeinsam genutzte Systemressourcen. Wenn eine Ressource umkämpft ist (ein Browser, Port oder eine Datei), sollte man von Anfang an an Isolation denken.
Eine fertige Anleitung zum Verbinden von 7 funktionierenden MCPs findest du unter Claude-Code-MCP-Server 2026: 7 einsatzbereite Setups.
Wann braucht man ein Plugin statt eines Skills oder Subagents?
Das Wichtigste
Ein Plugin ist ein verpacktes Paket aus Skills, Subagents, Hooks und Befehlen von jemand anderem, das mit einer einzigen Zeile über den Marketplace installiert wird. Verwende es, wenn du nicht alles von Grund auf selbst bauen möchtest und dem Autor des Pakets vertraust – zum Beispiel für Frontend-Design, Tests mit Playwright oder eine Telegram-Integration.
Skills, Subagents und MCP betreffen deine Methodik. Ein Plugin ist die fertige Methodik von jemand anderem, die du in dein Setup importierst.
Im Oktober 2025 startete Anthropic Claude Code Plugins als offiziellen Vertriebsweg. Ein Plugin ist ein Verzeichnis, das Folgendes enthalten kann:
- eigene Slash-Befehle
- eigene Skills
- eigene Subagents
- eigene Hooks
- eigene MCP-Konfigurationen
- eigene Ausgabestile
All das wird mit plugin.json in einem Paket gebündelt. Die Installation erfolgt mit einer einzigen Zeile in ~/.claude/settings.json oder über den Befehl /plugin install <name>.
Mein konkreter Plugin-Stack.
frontend-designaus dem offiziellenclaude-plugins-official– 67 Stile, 96 Paletten, 57 Schriftpaare, 13 Frameworks. Wenn ich einen neuen Block für die Website oder eine E-Mail-Vorlage erstelle, lade ich dieses Plugin und erhalte die ganze Bibliothek auf einmal.playwrightaus demselben offiziellen Marketplace – ein Paket aus Skills und MCP-Konfigurationen für Browser-Tests.telegram– ein fertiges Paket zur Verwaltung eines Telegram-Kontos über Claude Code (Richtlinie, Allowlist, Kopplung).trailofbits/skills– ein Paket mit Sicherheits-Skills von Trail of Bits, einem Unternehmen, dem ich in Sicherheitsfragen vertraue.
Alle 4 stehen in drei Zeilen in settings.json. Ohne Plugins würde ich Stunden damit verbringen, dieselbe Bibliothek von Hand aufzubauen.
Wann man kein Plugin verwenden sollte.
- Wenn die Methodik vollständig deine eigene ist und sich nicht auf andere übertragen lässt, behalte sie als Skill.
- Wenn du noch nicht weißt, wer sie verwenden wird, probiere sie zuerst selbst als Skill aus.
- Wenn du schnell drei Dateien auf einen neuen Rechner übertragen musst, reicht
cp ~/.claude/skills/X /new/machine/.claude/skills/.
Das wichtigste Anti-Pattern. Ein Plugin als Ersatz für CLAUDE.md verwenden – zum Beispiel ein Plugin mit Regeln dazu, „wie wir in diesem Projekt arbeiten“. Ein Plugin dient der Verteilung und Wiederverwendung. Wenn Regeln für ein einzelnes Repository gelten, gehören sie in CLAUDE.md, nicht in ein Plugin.
Mit Blick auf 2026: Anthropic bewegt sich klar auf einen Team-Marketplace für Plugins zu. Das bedeutet, dass Unternehmen ihre internen Methodiken als Plugins veröffentlichen, versionieren und mit einem Befehl für alle Mitarbeitenden aktualisieren können. Für Einzelunternehmer bedeutet das: Installiere, was fertig ist, und erfinde das Rad nicht neu.
Entscheidungsbaum: 4 Fragen, die du dir vor jeder Aufgabe stellen solltest
Stelle alle vier Fragen unabhängig. Jedes „Ja“ benennt einen Bedarf. Prüfe die übrigen Fragen weiter, weil ein Ablauf mehrere Ebenen kombinieren kann. Bei viermal „Nein“ genügen möglicherweise normaler Prompt und Projektanweisungen.
Frage 1: Gibt es ein aufbewahrenswertes wiederkehrendes Verfahren?
Verpacke es dann als Skill in SKILL.md mit klarer Einsatzbeschreibung. Er liefert das Verfahren, allein aber weder externen Zugriff noch eigenen Kontext.
Frage 2: Braucht die Arbeit eigenen Kontext oder eine fokussierte delegierte Rolle?
Nutze dann einen Subagenten mit präziser Aufgabe und passenden Tools. Er kann im isolierten Kontext der Methodik eines Skills folgen.
Frage 3: Braucht die Aufgabe ein Tool oder externe Daten?
Stelle genehmigten Zugriff durch MCP oder ein anderes passendes Tool bereit, etwa eine bereits eingerichtete CLI. Ein Skill beschreibt dessen Nutzung; ein Subagent kann es als delegierter Akteur verwenden.
Frage 4: Soll diese Einrichtung als Paket verteilt und gepflegt werden?
Nutze ein Plugin zur Verteilung von Skills, Agentendefinitionen, Hooks oder MCP-Konfiguration. Das Paket kann von dir oder einem anderen Autor stammen.
Kombiniertes Beispiel: regelmäßige GitHub-Issue-Prüfung. Ein Skill definiert Verfahren und Ergebnisformat. Eingerichtetes GitHub-MCP oder CLI liefert genehmigten Issuezugriff. Ein Subagent liest einen langen Thread im eigenen Kontext und liefert Funde. Ein Plugin verteilt das Paket im Team. Alle vier Antworten dürfen „Ja“ sein; keine hebt die andere auf.
5 Fehler bei der Wahl der Ebene, die Vibe-Codern häufig unterlaufen
Das Wichtigste
Zu den teuersten Fehlern gehören: einen Subagent statt eines Skills zu verwenden, MCP statt eines Skills, ein Plugin statt CLAUDE.md und einen Skill über einen Hook. All das verbraucht Tokens oder führt zu fehlerhaftem Verhalten. Ich zeige anhand konkreter Beispiele, was passiert ist und was hätte passieren sollen.
Diese 5 Muster sehe ich bei den Vibe-Codern, mit denen ich arbeite, jede Woche. Jeder Zweite macht mindestens einen davon in seiner ersten Woche.
Fehler 1: Subagent statt Skill.
Symptom: Jemand hat einen Subagent zum „Schreiben eines neuen Blogbeitrags“ erstellt. Bei jedem Start lädt er, liest 2 KB Methodik, generiert einen Beitrag und wird beendet. Nach einer Woche bemerkt die Person, dass jeder Durchlauf zusätzlich 5K Tokens für das Laden des Subagents verbraucht.
Was passieren sollte: „Wie man einen Beitrag schreibt“ ist eine Methodik – also ein Skill. Der Auslöser ist der Satz „neuer Blogbeitrag“. Der Skill wird in den Hauptchat geladen und öffnet keine separate Sitzung. Das ist 3–5-mal günstiger.
Fehler 2: MCP-Server statt Skill.
Symptom: Jemand hat einen MCP-Server geschrieben, der Anweisungen dazu bereitstellt, „wie man eine Code-Review durchführt“. Tool-Deklarationen, Beschreibungen des Argument-Schemas und Dokumentation belegen ständig Kontext. Jede Anfrage verschwendet 2–3K Tokens für nichts.
Was passieren sollte: „Wie man eine Code-Review durchführt“ ist ein Verfahren, kein Zugriff auf ein externes System. Verwende einen Skill. MCP ist nur gerechtfertigt, wenn du Live-Zugriff brauchst – zum Beispiel auf Sentry, um die neuesten Fehler abzurufen.
Fehler 3: Plugin statt CLAUDE.md.
Symptom: Jemand hat Projektregeln („immer den strikten TypeScript-Modus verwenden“, „keine Gedankenstriche verwenden“, „nur pnpm, nicht npm verwenden“) in ein Plugin verpackt und installiert. Jede neue Sitzung lädt nun ein Plugin, das dupliziert, was in CLAUDE.md stehen sollte.
Was passieren sollte: Regeln für ein einzelnes Projekt gehören in dessen CLAUDE.md. Ein Plugin ist für eine Methodik gedacht, die sich auf mehrere Personen oder Repositories übertragen lässt.
Fehler 4: Einen Skill über einen Hook erstellen wollen.
Symptom: Jemand hat gesehen, dass ein Hook bei einem Ereignis automatisch ausgeführt wird (zum Beispiel vor dem Speichern einer Datei). Die Person beschloss, einen „Skill über einen Hook“ zu erstellen, damit Claude die Methodik bei jeder Bearbeitung automatisch anwendet. Das führte zu einer endlosen Trigger-Schleife, verbrauchte Kontext und verursachte unvorhersehbares Verhalten.
Was passieren sollte: Ein Hook ist deterministischer Code, der einen Befehl ausführt, das Ergebnis formatiert oder einen Vorgang blockiert. Ein Hook lädt keinen Skill und ruft Claude nicht auf. Wenn du „Methodik X immer anwenden“ möchtest, verwende entweder einen Skill mit einem Trigger oder einen Eintrag in CLAUDE.md.
Fehler 5: Eine zusätzliche Ebene, obwohl gar keine nötig ist.
Symptom: Jemand hört von Skills, liest Anleitungen, beschließt „Ich muss diese Methodik verpacken“ und verbringt einen Abend damit, einen Skill für eine Aufgabe zu erstellen, die einmal im Monat anfällt.
Was passieren sollte: Eine einmalige Aufgabe gehört spontan in den Chat. Ein Skill ist nur gerechtfertigt, wenn du das mehr als einmal am Tag tust. Andernfalls ist es Overengineering, das anschließend gepflegt werden muss.
Prüfe die Bedürfnisse in diesen Beispielen unabhängig: Verfahren, Kontext- oder Rollenisolierung, Toolzugriff und Verteilung. Ergänze jede Ebene mit konkretem Zweck und kombiniere sie bei mehreren Anforderungen.
Was Anthropic über die Fragmentierung sagt: Wohin sich Claude Code 2026 entwickelt
Das Wichtigste
Claude Code führt die fünf Möglichkeiten für Code-Review (Befehl, Skill, Subagent, Plugin oder Chat) in einem integrierten Skill /code-review zusammen. Das bedeutet: Keine Panik wegen „zu vieler Ebenen“ – 2026 verschwimmen die Grenzen und die Dinge werden einfacher.
Was das in den nächsten sechs Monaten bis zu einem Jahr bedeutet.
Erstens: Skills werden zur wichtigsten Ebene für prozedurale Aufgaben. Anthropic setzt eindeutig auf diese Ebene, weil sie am günstigsten und vorhersehbarsten ist. Wenn du 2026 nicht verstehst, wofür du einen Skill brauchst, solltest du ihn zuerst kennenlernen. Alle anderen Ebenen werden sich um ihn drehen.
Zweitens: Subagents werden spezialisiert. Die Hauptaufgabe von Subagents ist die Kontextisolation für umfangreiche Aufgaben. Allgemeine Subagents wie qa-engineer werden verschwinden; spezifische wie migration-test-writer und api-route-reviewer werden bleiben.
Drittens: Die neuen Ankündigungen von Anthropic innerhalb von 14 Tagen – der Befehl /workflows (28. Mai 2026) zur Orchestrierung Dutzender Subagents und die Aufteilung der Agent-SDK-Abrechnung ab dem 15. Juni – bedeuten, dass die programmatische Nutzung in einen separaten Pool verschoben wird. Das ist ein Zeichen dafür, dass Anthropic eine Infrastruktur für automatisierte Systeme mit 10+ Agents statt für einzelne Sitzungen aufbaut.
Für Vibe-Coder im Jahr 2026 bedeutet das etwas Einfaches: Die vier Ebenen werden mindestens weitere sechs Monate bestehen, danach werden einige zusammengeführt. Der Entscheidungsbaum mit vier Fragen funktioniert auch nach der Zusammenführung weiter – es geht um die Art der Aufgabe, nicht um den konkreten Namen der Ebene.
Fertige Matrix: 10 typische Aufgaben → die richtige Ebene
Das Wichtigste
Die Tabelle benennt den primären Bedarf einer Situation. Zeilen ergänzen sich: Eine Aufgabe kann zu mehreren passen und die aufgeführten Ebenen kombinieren.
| # | Auslösende Situation | Richtige Ebene | Warum diese Ebene |
|---|---|---|---|
| 1 | Claude übersieht dieselbe Regel 2–3-mal in einer Sitzung | CLAUDE.md | Reaktiv, immer im Kontext, erfordert keinen Trigger |
| 2 | Ich tippe denselben langen Prompt mehr als einmal am Tag | Skill | Wird bei Bedarf geladen und verbraucht keine grundlegenden Kontext-Tokens |
| 3 | Ich füge zum dritten Mal ein 1.500-Wörter-Playbook in den Chat ein | Skill | Prozedurale Methodik, geladen durch eine Trigger-Phrase |
| 4 | Eine Aufgabe überlastet den Hauptchat mit mehr als 20 zu lesenden Dateien | Subagent | Kontextisolation; nur eine Zusammenfassung kehrt in den Hauptchat zurück |
| 5 | Ich brauche 5 identische parallele Prüfungen (QA, Review, Lint) | Subagents | Mit run_in_background gestartet; die Gesamtdauer sinkt auf ein Fünftel |
| 6 | Ich möchte GitHub-Issues oder die neuesten Fehler von Sentry lesen | MCP | Direkter Zugriff auf ein externes System über ein Standardprotokoll |
| 7 | Ich möchte eine abgedeckte Push-Operation automatisch prüfen | Getesteter Hook | Deterministische Prüfung; tatsächlichen Auslöser und Blockade testen |
| 8 | Ich möchte mein Setup in ein zweites Repository oder auf einen neuen Rechner übertragen | Plugin | Verteilung über einen Marketplace plus Namespace |
| 9 | Ein Team aus 10 Personen muss dieselben Regeln befolgen | Plugin im Team-Marketplace | Versioniert, einmal installieren, zentral aktualisieren |
| 10 | Auf einen Webhook eines externen Dienstes antworten (Telegram, GitHub Actions) | MCP-Kanal oder Agent SDK | Nachrichten von außen in die Sitzung übertragen |
Die wichtigste Regel für die Verwendung dieser Tabelle lautet: Versuche nicht, „alle 10 Dinge auf einmal zu erledigen“. Die meisten Vibe-Coder, die allein arbeiten, kommen mit CLAUDE.md + 5–7 Skills + 2–4 MCP-Servern aus. Subagents und Plugins kommen hinzu, wenn das Projekt wächst.
Wie es weitergeht: So baust du deinen Workspace in Claude Code auf
Das Wichtigste
CLAUDE.md enthält die grundlegenden Projektregeln, Skills verpacken Methodik, Subagents verteilen umfangreichen Kontext, MCP verbindet mit der Außenwelt und Plugins verteilen fertige Pakete von anderen. Das sind die fünf Bausteine deines Claude-Code-Setups im Jahr 2026.
Diese fünf Ebenen folgen nicht nacheinander, sondern greifen ineinander. CLAUDE.md ist das Fundament des Projekts; die anderen vier werden mit wachsenden Aufgaben verbunden.
Quellen
- Anthropic Engineering: Skills erklärt (13. November 2025)
- Claude-Code-Dokumentation: Überblick über Skills
- Claude-Code-Dokumentation: Subagents
- Claude-Code-Dokumentation: Überblick über MCP
- Claude-Code-Dokumentation: Plugins
- Claude-Code-Releases auf GitHub
- Anthropic News: Blog-Updates 2026
- Sentry-MCP-Kochbuch
- Trail-of-Bits-Skills-Repository
- Offizieller Claude-Plugins-Marketplace
Lerne Ailoot kennen.
Weitere Details
Fragen und Antworten
Kann eine GitHub-Prüfung Skill, Subagent und MCP zugleich benötigen?
Ja. Ein Skill definiert das Verfahren, MCP oder genehmigtes CLI liefert Issuedaten und ein Subagent kann einen langen Review im eigenen Kontext erledigen. Ein Plugin kann die Kombination verteilen.
Wie verwende ich die Vier-Fragen-Checkliste?
Beantworte jede Frage unabhängig: Brauche ich Verfahren, Kontextisolierung, Toolzugriff oder Verteilung? Jedes Ja ergänzt eine konkrete Anforderung. Das erste Ja beendet die Entscheidung nicht.