Claude Skills vs. Subagents: Ein empirischer Leitfaden

Die Unterscheidung zwischen einem Claude-Skill und einem Subagent führt häufig zu Verwirrung. Entwickler, die auf Claude Code aufbauen, fragen sich oft, ob sie eine Logik als wiederverwendbaren Skill oder als komplexeren, isolierten Subagent verpacken sollen. Die Dokumentation bietet theoretische Anleitungen, aber die Theorie scheitert oft an der Realität. Dieser Artikel gibt eine empirische Antwort auf die Frage claude skills vs subagents.

Bei SkillProof besteht unser gesamter Zweck darin, Claude Code-Skills bei realen Aufgaben zu testen. Um dies zuverlässig zu tun, führt unsere Testumgebung jeden Kandidaten-Skill in einem dedizierten Subagent aus, damit ein Durchlauf den nächsten nicht beeinflussen kann. Das verschafft uns einen praktischen Blickwinkel, obwohl es wichtig ist, genau zu sein, was unsere Daten beweisen und was nicht. Wir haben Ausführungsaufzeichnungen für 2090 Skills, was uns viel darüber verrät, wie Skills scheitern – es ist kein kontrollierter Vergleich derselben Aufgabe, die auf beide Weisen erstellt wurde. Der unten dargelegte Unterschied zwischen Skill und Agent bei Claude ist unsere Interpretation dieser Fehlschläge, und wir werden die Zahlen hinter jeder Behauptung aufzeigen, damit Sie die Argumentation selbst beurteilen können.

Begriffsdefinitionen: Skill vs. Subagent

Vor der Analyse der Daten ist es wichtig, klare Definitionen festzulegen. Obwohl sie ähnlich erscheinen mögen, dienen Skills und Subagents grundlegend unterschiedlichen Zwecken und operieren auf verschiedenen Abstraktionsebenen.

Ein Skill ist ein Rezept. Es ist ein Satz spezifischer, wiederverwendbarer Anweisungen und Werkzeuge, die die Fähigkeiten des Basismodells für eine klar definierte Aufgabe erweitern. Ein Skill wird in einer SKILL.md-Datei definiert und ist dafür konzipiert, vom Hauptagenten aufgerufen zu werden, um eine einzelne Aktion durchzuführen. Er operiert im Kontext des Hauptagenten und eignet sich am besten für atomare Operationen, wie das Formatieren von Code, das Erzeugen eines bestimmten Dateityps oder das Erzwingen eines Hausstils. Man kann es sich wie eine Rezeptkarte vorstellen, die man einem Koch gibt, der bereits kochen kann.

Ein Subagent ist ein vollständig separater Worker. Es ist eine unabhängige Instanz des Modells, die von einem primären Agenten gestartet wird, um eine große, komplexe oder spezialisierte Aufgabe zu bewältigen. Ein Subagent hat seinen eigenen Kontext, seinen eigenen System-Prompt und kann seinen eigenen Zustand über einen mehrstufigen Arbeitsablauf hinweg verwalten. Der primäre Agent delegiert ein übergeordnetes Ziel an den Subagent, der dann autonom arbeitet, um es zu erreichen. Man sollte es sich nicht als Funktion vorstellen, sondern als separaten Dienst, der über eine API aufgerufen wird.

Diese Tabelle fasst die Kernunterschiede zusammen:

Merkmal	Skill	Subagent
Analogie	Ein spezifisches Rezept	Ein spezialisierter Koch
Umfang	Atomare, zweckgebundene Aufgabe	Komplexer, mehrstufiger Arbeitsablauf
Zustand	Zustandslos	Eigenes Kontextfenster für die Ausführung; gibt eine Zusammenfassung zurück und behält danach nichts
Kontext	Teilt den Kontext mit dem Hauptagenten	Isolierter, unabhängiger Kontext
Komplexität	Ein Verzeichnis: SKILL.md plus optionale Skripte und Referenzdateien, die bei Bedarf geladen werden	Eine Markdown-Datei mit YAML-Frontmatter in .claude/agents/ – System-Prompt, Tool-Allowlist, Modell
Ideal für	Tooling, Format-Erzwingung	Autonome Aufgaben, spezialisierte Rollen

Wie unsere Testumgebung den Unterschied aufzeigt

Beachten Sie, dass die eigentliche Unterscheidungsachse in dieser Tabelle die Kontextisolation ist, nicht die Codegröße. Beide werden als reines Markdown verfasst; nur einer erhält sein eigenes Fenster.

Unsere Testmethodik stützt sich auf diese Unterscheidung. Wie auf unserer Methodik-Seite beschrieben, führt ein Agent den Test durch, nicht eine Person: Derselbe Agent erstellt eine Baseline ohne Skill und einen durch einen Skill geführten Versuch für dieselbe reale Aufgabe und bewertet dann, ob das Ergebnis deutlich besser ist als das von Claude ohne den Skill. Wir führen jeden dieser Tests in einem eigenen Subagent aus, damit die Ausführung eines Skills die eines anderen nicht beeinflussen kann.

Diese Konfiguration erzwingt eine klare Abgrenzung. Dem Subagent wird ein einziges Ziel gegeben: die Aufgabe unter Verwendung des bereitgestellten Skills auszuführen. Indem wir diesen Prozess tausende Male beobachten, sehen wir genau, wo die Skill-Abstraktion glänzt und wo sie versagt.

Unsere Katalogstatistiken sind aufschlussreich. Von den bisher 2090 getesteten Skills:

• 1291 (62 %) bestehen unsere Benchmarks. Sie lassen sich installieren, werden bei den Prompts ausgelöst, für die sie konzipiert sind, und übertreffen die Baseline ohne Skill bei einer realen Aufgabe.
• 697 benötigen Setup. Gemäß unserer Methodik bedeutet Setup, dass der Skill Konfiguration, einen begleitenden Skill oder eine verbundene Integration benötigt, um zu funktionieren. Bei der Durchsicht dieser 697 Testnotizen sind die Blocker überwiegend zugriffsbedingt: 229 erwähnen ein externes CLI oder Binary, 171 einen API-Schlüssel oder Anmeldeinformationen, 169 ein kostenpflichtiges Konto oder einen Plan, 136 einen MCP-Server oder eine Integration.
• 102 schneiden SCHLECHTER ab als das reine Claude. Sie konnten die Baseline ohne Skill nicht übertreffen – einige, weil sie überhaupt nicht ausgeführt werden konnten (ein fehlendes CLI, eine tote Abhängigkeit, ein Beispiel, das abstürzt), andere, weil sie liefen und die Ausgabe schlechter machten als das reine Claude.

Ehrlich betrachtet, sagt diese Verteilung weniger über die Architektur aus, als man vielleicht hoffen würde. Die Kategorie „Setup“ handelt hauptsächlich von Anmeldeinformationen und fehlenden Binärdateien, was orthogonal zu der Frage ist, ob eine Aufgabe in einen Skill oder einen Subagent gehört. Die Fehlschläge sind der Ort, an dem die eigentliche Lektion zur Architektur liegt, und wir werden unten darauf eingehen.

Wann man einen Skill verwendet: Das Rezept-Modell

Basierend auf den 1291 bestandenen Skills in unserem Verzeichnis zeichnet sich ein klares Muster ab. Erfolgreiche Skills sind fokussiert, zustandslos und deterministisch. Sie sind Werkzeuge, keine Denker.

Hier sind die idealen Anwendungsfälle für einen Skill:

1. Atomare, wiederholbare Aufgaben: Ein Skill eignet sich hervorragend für Aufgaben mit einer klaren Eingabe und einer vorhersagbaren Ausgabe. Denken Sie an Dinge, für die Sie normalerweise ein kleines Skript schreiben würden. audit-export, ein bestandener Skill in unserer Produktivitätskategorie, ist ein sauberes Beispiel: Man füttert ihn mit einem Markdown-Audit-Bericht und er gibt eine importfertige CSV-Datei für Jira, Linear, Teamwork oder Monday aus. In unserem Test wandelte er einen Bericht mit fünf Befunden in gültige Zeilen mit korrekten Fälligkeitsdaten für die Phasen und in Anführungszeichen gesetzten, mehrzeiligen Ticket-Vorlagen um. Eine Aufgabe, gut erledigt.

2. Claude beibringen, bereits vorhandenen Zugriff zu nutzen: Dies ist die Unterscheidung, die oft falsch verstanden wird, also ist hier Vorsicht geboten: Ein Skill gewährt keinen neuen Zugriff. Er kann nicht von sich aus auf Ihre Postgres-Instanz zugreifen oder eine Drittanbieter-API aufrufen – dafür sind MCP-Server da, und wir haben diese Trennung in Claude Skills vs MCP behandelt. Was ein Skill tut, ist, Claude beizubringen, eine bereits vorhandene Fähigkeit gut und konsistent zu nutzen. Wenn sich ein CLI bereits in Ihrem PATH befindet, ist ein Skill der richtige Ort, um zu kodieren, wie Ihr Team es aufruft.

3. Eingeschränkte Ausgabe und Formatierung: Wenn die Ausgabe einer starren Struktur entsprechen muss, ist ein Skill die richtige Wahl. git-workflow, in unserer Coding-Kategorie, ist ein funktionierendes Beispiel: Als um Hilfe gebeten wurde, bevor ein PR von einem Branch namens my-fix mit einem einzigen Commit und der Commit-Nachricht „fixed stuff“ geöffnet wurde, benannte der Skill die spezifischen Konventionsverstöße und erstellte konforme Ersetzungen. Die SKILL.md enthält strikte Anweisungen zur Form, die das Modell zuverlässig befolgt, da die Aufgabe eng gefasst ist.

Merkmale eines gut konzipierten Skills, wie sie in unseren hoch bewerteten Beispielen zu sehen sind, umfassen eine prägnante SKILL.md, eine klare Definition aller enthaltenen Werkzeuge und das Fehlen komplexer, verzweigter Logik. Die Anweisungen sollten das Modell leiten, nicht versuchen, es durch Prosa zu programmieren.

Wann man einen Subagent verwendet: Das Spezialisten-Modell

Wenn ein Skill ein Rezept ist, ist ein Subagent ein Spezialist, den man für eine komplexe Aufgabe engagiert. Die Entscheidung claude code subagent or skill wird klarer, wenn die Aufgabe Gedächtnis, Iteration oder eine ausgeprägte Persona erfordert.

Unsere Daten zu fehlschlagenden oder komplex einzurichtenden Skills zeigen, wann ein Entwickler von Anfang an eine Subagent-Architektur hätte wählen sollen.

Hier sind die idealen Anwendungsfälle für einen Subagent:

1. Mehrstufige, komplexe Arbeitsabläufe: Jede Aufgabe, die eine Abfolge von abhängigen Schritten erfordert, ist eine Aufgabe für einen Subagent. Zum Beispiel: „Recherchieren Sie die Leistung verschiedener Sortieralgorithmen für fast sortierte Daten, schreiben Sie eine Zusammenfassung der Ergebnisse und generieren Sie dann Python-Code, der den effizientesten implementiert.“ Dieser Arbeitsablauf erfordert die Aufrechterhaltung des Kontexts (die Recherche) über mehrere Schritte (Zusammenfassen, Codieren) hinweg. Die zustandslose Natur eines Skills macht dies zuverlässig fast unmöglich.

2. Aufgaben, die Isolation oder eine andere Persona erfordern: Manchmal erfordert eine Aufgabe eine völlig andere Denkweise als der Hauptagent. Ein klassisches Beispiel ist ein „Code-Reviewer“-Agent. Sie möchten vielleicht, dass dieser Agent kritisch, akribisch und ausschließlich auf die Codequalität fokussiert ist. Der Versuch, diese Persona einem allgemeinen Assistenten über einen Skill zu entlocken, ist ineffizient und unzuverlässig. Es ist weitaus effektiver, einen Subagent mit einem auf diese kritische Persona zugeschnittenen System-Prompt zu starten.

3. Langlaufende Aufgaben, die nicht im Kontext verbleiben sollen: Ein Skill ist überhaupt kein Aufruf – nichts wird aufgerufen und nichts wird zurückgegeben. Claude liest die SKILL.md in seinen eigenen Kontext ein und befolgt die Anweisungen selbst, innerhalb der Hauptschleife. Es gibt keinen separaten Worker, dem man eine lange Aufgabe übergeben kann. Subagents sind der Mechanismus dafür, und seit Claude Code v2.1.198 laufen sie standardmäßig im Hintergrund, wobei der Vordergrund für den Fall reserviert ist, dass das Ergebnis sofort benötigt wird. Eine Einschränkung, die klar formuliert werden sollte: Für reines Warten – das Abfragen eines Endpunkts, das Beobachten eines Build-Abschlusses – ist eine Hintergrund-Shell-Aufgabe günstiger und einfacher als das Starten eines Agenten. Greifen Sie zu einem Subagent, wenn die Arbeit Urteilsvermögen erfordert, nicht nur Geduld.

Die Grauzone: Warum 102 Skills schlechter als nichts sind

Die aufschlussreichsten Daten stammen von unseren Fehlschlägen – und sie sagen nicht das aus, was wir erwartet hatten. Wir gingen davon aus, dass die 102 Fehlschläge Skills wären, die versuchen, wie Subagents zu agieren: aufgeblähte SKILL.md-Dateien, verschachtelte Verzweigungen, zustandsbehaftete Prozesse, die in ein Rezept gezwängt wurden. Bei der Durchsicht der Testnotizen aller 102 erwähnen nur fünf überhaupt Länge oder Token-Aufblähung. Diese Theorie ist größtenteils falsch, und es ist besser, das zu sagen, als sie stillschweigend fallen zu lassen.

Was tatsächlich passiert, lässt sich in zwei Gruppen unterteilen. Die größere Gruppe sind Abhängigkeitsfehler: 30 der 102 nennen ein fehlendes CLI oder Binary, 22 ein kostenpflichtiges Konto, 19 einen fehlenden MCP-Server, 10 einen fehlenden API-Schlüssel. skill-builder ist repräsentativ – jeder Werkzeugaufruf hängt von einem separaten MCP-Server ab, der nicht gebündelt oder automatisch verbunden ist, und der Skill erwähnt die Voraussetzung nie, sodass ein einfacher manueller Ansatz ihn übertrifft. Dies sind Fehler bei der Paketierung, nicht bei der Architektur.

Die zweite Gruppe ist unauffälliger und lehrreicher: Skills, die sich sauber installieren lassen, korrekt ausgelöst werden und einfach nichts Besseres als die Baseline produzieren. api-design-principles ist der deutlichste Fall. Wir haben eine REST-Design-Aufgabe – einen Lesezeichen-Dienst mit Endpunkten, Versionierung, Paginierung und JSON-Beispielen – mit und ohne den Skill getestet. Beide Zweige produzierten korrekte, vergleichbare Arbeit. Bei aeon und arbor war das Ergebnis dasselbe. Hier greift die Frage nach Skill versus Subagent tatsächlich: Diese Skills versuchten, einen ganzen Denkprozess in Prosa zu kodieren, und das Modell war bereits zu diesem Denken fähig. Der Skill fügte Worte hinzu, ohne Fähigkeiten hinzuzufügen.

Das ist die ehrliche Lektion zur Architektur. Nicht „lange Skills schlagen fehl“, sondern: Wenn das, was Sie schreiben, ein Verfahren ist, das das Modell bereits kompetent befolgt, fügt ein Skill nichts hinzu – und wenn das Verfahren wirklich einen eigenen Kontext, eine Persona oder viele abhängige Schritte benötigt, ist Prosa in einer SKILL.md der falsche Container dafür. Die Antwort auf die Frage, wann man in Claude Code einen Skill im Vergleich zu einem Subagent verwenden sollte, lautet: Wenn sich Ihre Aufgabe wie ein Programm anfühlt, bauen Sie sie als Subagent; wenn sie sich wie ein Memo an einen kompetenten Kollegen anfühlt, der die Arbeit bereits kennt, muss sie möglicherweise gar nicht existieren.

Eine praktische Heuristik

Die Wahl zwischen einem Skill und einem Subagent muss keine akademische Debatte sein. Unsere Testdaten legen eine einfache, praktische Heuristik nahe:

Ist die Aufgabe ein Funktionsaufruf oder ein Programm?

• Wenn Ihre Aufgabe als einzelner Funktionsaufruf modelliert werden kann – sie eine klare Eingabe entgegennimmt und eine einzelne Ausgabe erzeugt, ohne sich an vergangene Interaktionen erinnern zu müssen – ist es ein Skill.
• Wenn Ihre Aufgabe Zustand, internes Gedächtnis, mehrere Schritte oder einen spezialisierten Kontext zur Ausführung benötigt – mit anderen Worten, wenn sie sich wie ein eigenständiges Programm verhält – sollte es ein Subagent sein.

Indem Entwickler sich an diese Unterscheidung halten, können sie robustere, zuverlässigere und effektivere Lösungen mit Claude Code erstellen. Beginnen Sie mit der einfachsten funktionierenden Abstraktion. Ein gut definierter Skill ist mächtig. Aber erkennen Sie die Anzeichen wachsender Komplexität und seien Sie bereit, zu einer Subagent-Architektur überzugehen, wenn die Aufgabe es erfordert.

Weiterführende Lektüre: Wenn Sie entschieden haben, dass die Aufgabe in einen isolierten Worker gehört, behandelt unser Leitfaden zu Claude Code Subagents, wie man einen definiert und was er tatsächlich sehen kann. Und wenn Sie noch überlegen, ob Sie neuen Zugriff anstelle von besseren Anweisungen benötigen, zieht Claude Skills vs MCP diese Grenze korrekt – dies ist die häufigere Quelle der Verwirrung.

Wenn Sie zuverlässige, vorab geprüfte Werkzeuge für gängige Entwicklungsaufgaben benötigen, haben wir über tausend bestandene Skills gebenchmarkt. Sie können nach Funktion in den Coding-Skills und Dokumenten-Skills stöbern oder ein rollenbasiertes Paket mit zehn getesteten Skills für 10 $ erwerben – das developer toolkit passt am besten zu der hier beschriebenen Arbeit.