Claude Skills vs. Slash Commands vs. Subagents

Inhaltsverzeichnis

Aktualisiert im August 2026.

TL;DR: Slash Commands sind eine Abkürzung für einen Prompt, den du oft eintippst — du rufst sie namentlich auf. Subagents sind parallele Worker mit einem eigenen Kontextfenster — du (oder Claude) startest sie für eine abgegrenzte Aufgabe und bekommst ein Ergebnis zurück. Skills sind gebündeltes Fachwissen, das Claude von sich aus lädt, je nachdem, worum du bittest, ohne dass du irgendetwas benennst. Die meisten Leute greifen zu einem eigenen Agenten, wenn ein Slash Command reichen würde, und zu einem Slash Command, wenn sie eigentlich einen Skill gebraucht hätten, den Claude selbst auslöst.

Notiz vom Betreiber: Ich betreibe 30+ Produktionsagenten in zwei Unternehmen, und genau diese Verwirrung — Command, Subagent oder Skill — ist die erste Designfrage bei fast jedem davon. Liegst du falsch, baust du entweder zehn Commands, deren Namen sich niemand merkt, oder einen Skill, der so breit ist, dass er nie zuverlässig auslöst. Die Lösung ist keine Faustregel, sondern die Frage, was sich zwischen den Durchläufen tatsächlich ändert.

Die drei Primitive lösen unterschiedliche Probleme

Alle drei lassen dich Anweisungen einmal bündeln und wiederverwenden. Da endet die Ähnlichkeit — und genau deshalb verwechseln Leute sie: Von außen sieht “etwas Kurzes eintippen und ein brauchbares Ergebnis bekommen” gleich aus, egal welches der drei im Hintergrund die Arbeit macht.

Der eigentliche Unterschied ist, wer entscheidet, es aufzurufen, und in welchem Kontext es läuft:

• Ein Slash Command wird von dir namentlich aufgerufen. Du tippst /deploy oder /review, Claude erweitert es zu einer ausführlicheren Anweisung, und sie läuft in deiner aktuellen Konversation.
• Ein Subagent wird von dir oder Claude für eine Aufgabe mit klarer Abgrenzung aufgerufen. Er bekommt sein eigenes Kontextfenster, erledigt die Arbeit und meldet ein Ergebnis zurück — er sieht nicht deine ganze Konversation, und du siehst seine Zwischenschritte nicht, außer du fragst danach.
• Ein Skill wird von Claude automatisch aufgerufen, wenn deine Anfrage zu dem passt, was die Beschreibung des Skills abdeckt. Du tippst nie seinen Namen. Fragst du nicht nach etwas, das der Skill abdeckt, lädt er nie.

Diese dritte Eigenschaft — kein expliziter Aufruf — ist die, die am meisten unterschätzt wird. Sie ist auch die mit dem größten Hebel, sobald du mehr als eine Handvoll gebündelter Workflows hast, weil du dir nicht mehr merken musst, wie du die Dinge genannt hast.

Slash Commands: Abkürzung für einen Prompt, den du oft eintippst

Baue einen Slash Command, wenn der Auslöser ist: “Ich tippe im Grunde ständig dieselbe Anweisung.” Ein Command, der immer zum selben zugrunde liegenden Prompt aufgelöst wird, erweitert aus einem kurzen Namen, den du gewählt hast, in der Konversation, die du schon führst. Kein separater Kontext, kein autonomer Aufruf — du entscheidest jedes Mal, wann er läuft.

Gute Fälle: eine feste Release-Checkliste, ein Code-Review-Durchlauf mit deinen eigenen Regeln fest eingebaut, eine “Fasse diesen PR zusammen”-Abkürzung. Der Command braucht kein Urteilsvermögen darüber, ob er laufen soll — das entscheidest du, indem du ihn eintippst.

Der Fehlermodus ist, einen Command für etwas zu bauen, das eigentlich ein Urteil des Modells braucht, ob er zutrifft. Wenn die halbe Nutzung “Moment, zählt diese Situation überhaupt?” ist — dann ist das eine Skill-Frage, keine Command-Frage, denn ein Command hat keine Möglichkeit, sich selbst auszulösen.

Subagents: parallele Worker mit eigenem Kontextfenster

Baue einen Subagent, wenn die Aufgabe abgegrenzt, delegierbar ist und sonst deine Hauptkonversation mit Schritten verschmutzen würde, die du nicht sehen musst. Ein Subagent läuft mit seinem eigenen Kontext — eigenen Tool-Aufrufen, eigenem Hin und Her — und liefert am Ende ein Ergebnis zurück. Das ist dasselbe Prinzip, über das ich bei Context Engineering geschrieben habe: Jeder zusätzliche Tool-Aufruf und Zwischenschritt ist Kontext, den dein Hauptthread nicht mittragen muss, und ein Subagent ist, wie du dieses Rauschen draußen hältst.

Gute Fälle: “Recherchiere das und berichte zurück”, “führe diese fünf unabhängigen Checks parallel aus”, “geh und behebe diese eine Datei isoliert.” Die Aufgabe hat einen Anfang, ein Ende und ein Ergebnis — genau die Form, die der Eval-Harness, den ich zum Ausliefern von Agenten nutze, als eine einzige bewertbare Einheit behandelt.

Der Fehlermodus ist, einen Subagent für etwas zu starten, das eigentlich im Hauptkontext hätte bleiben müssen, weil der nächste Schritt von Details abhängt, die die Zusammenfassung des Subagents fallen gelassen hat. Wenn du den Subagent ständig erneut fragen musst “Moment, was genau hast du gefunden” — war die Abgrenzung falsch gezogen. Entweder faltest du es zurück in den Hauptthread, oder du machst den Bericht des Subagents strukturiert genug, dass bei der Übersetzung nichts verloren geht.

Skills: gebündeltes Fachwissen, das Claude von sich aus lädt

Baue einen Skill, wenn die Auslösebedingung etwas ist, das Claude aus dem erkennen sollte, worum du bittest — nicht etwas, an dessen Benennung du dich erinnern musst. Ein Skill ist eine Beschreibung plus ein Bündel aus Anweisungen und Skripten; Claude liest die Beschreibung, entscheidet, ob deine Anfrage passt, und lädt die vollständigen Anweisungen nur, wenn sie passt. Du tippst nie /skill-name.

Das klarste Beispiel, auf das ich zeigen kann, ist das, das die Pipeline hinter diesem Blog betreibt. Alejandrorioja.com veröffentlicht in 13 Sprachen, und der ganze Ablauf von Generieren → Übersetzen → Rendern → Prüfen lebt in einem einzigen Skill: einer SKILL.md-Datei, die beschreibt, wann er genutzt wird (“einen neuen Beitrag generieren”, “in alle Sprachen übersetzen”, “einen Promo entwerfen”), plus die Skripte, die die eigentliche Arbeit erledigen. Ich führe nicht vier separate Commands aus und merke mir ihre Reihenfolge. Ich sage in normaler Sprache, was ich will, und die Beschreibung des Skills ist präzise genug, dass Claude sie aufgreift und die richtigen Schritte ausführt — genauso wie der Facebook-Ads-Skill bei “prüfe meine Anzeigen” auslöst, ohne dass ich einen Command-Namen eintippe.

Diese Design-Entscheidung — ein Skill, der selbst entscheidet, wann er zutrifft — ist auch, warum die Sicherheitsvoreinstellung hier mehr zählt als bei Commands oder Subagents. Ein Slash Command läuft nur, wenn du ihn eintippst; ein Skill läuft, wenn das Modell denkt, er sollte es. Mein Content-Skill schreibt standardmäßig Entwürfe und braucht einen expliziten, separaten Freigabeschritt, bevor irgendetwas veröffentlicht wird oder gepusht wird — dasselbe Human-in-the-Loop-Muster, das ich überall nutze, wo ein Skill sich selbst in eine Aktion mit echten Konsequenzen auslösen kann.

Gute Fälle: alles mit einer erkennbaren Auslösephrase und einer wiederholbaren Prozedur dahinter — “erstelle einen Bericht”, “bewerte diese Einreichung”, “entwirf eine Zusammenfassung für Slack”. Der Fehlermodus ist eine Skill-Beschreibung, die so breit ist, dass sie auslöst, wenn du es nicht wolltest, oder so eng, dass sie nie auslöst, wenn du es wolltest. Schreib die Beschreibung so, wie du einer neuen Mitarbeiterin die Auslösebedingung erklären würdest, nicht so, wie du eine Funktion benennen würdest.

Das Entscheidungsraster

Frag das	Wenn ja →	Warum
Will ich immer einen Namen eintippen, um das auszulösen?	Slash Command	Du bist der Auslöser, nicht das Modell
Ist die Aufgabe abgegrenzt, delegierbar und besser aus meinem Hauptkontext herausgehalten?	Subagent	Eigenes Kontextfenster, liefert ein Ergebnis
Sollte Claude den Bedarf erkennen, ohne dass ich irgendetwas benenne?	Skill	Beschreibungsabgleich, automatischer Aufruf
Geht es um Geld, Veröffentlichung oder irgendetwas schwer Rückgängigzumachendes?	Jedes der drei, plus ein explizites Freigabetor	Automatischer Aufruf ist nicht dasselbe wie automatische Ausführung

Die meisten echten Workflows sind ein Stapel davon, keine einzelne Wahl. Meine Content-Pipeline ist ein Skill (automatisch ausgelöst bei “schreib einen Beitrag”), der intern Subagents aufruft (einer pro Sprache, parallel laufend) und einen Slash Command (/publish) für den einen Schritt bereitstellt — live gehen — der nie ohne meine ausdrückliche Zustimmung passieren sollte.

Der Fehler, den ich am häufigsten sehe

Einen vollständigen eigenen Agenten zu bauen — mit eigener Planung, eigenem Zustand, eigenem Deployment — für etwas, das eigentlich ein Slash Command im Kostüm war. Wenn die Aufgabe ist “führe genau diese Prozedur aus, wenn ich es sage”, brauchst du keine Autonomie, kein Gedächtnis und keine Auslösebedingung. Du brauchst einen Namen und einen Prompt. Hebe dir die Subagent- und Skill-Maschinerie für Aufgaben auf, bei denen die Abgrenzung (Subagent) oder der Auslöser (Skill) tatsächlich Arbeit leistet — nicht nur Infrastruktur zu etwas hinzufügt, das bereits einfach war.

Das Fazit des Operators

Frag, wer entscheidet, es aufzurufen, bevor du fragst, wie du es baust. Du entscheidest, namentlich, jedes Mal → Slash Command. Eine abgegrenzte Aufgabe, die du aus deinem Hauptkontext heraushalten willst → Subagent. Claude erkennt den Bedarf von sich aus → Skill, mit einem Freigabetor für alles, was nicht rückgängig gemacht werden kann. Bekommst du diese eine Frage richtig, ergibt sich der Rest — was in die Datei kommt, wie viel Anweisung du bündelst — von selbst.

FAQ

Was ist der Unterschied zwischen einem Claude Skill und einem Slash Command?

Ein Slash Command wird explizit, namentlich, jedes Mal aufgerufen, wenn du ihn laufen lassen willst. Ein Skill wird automatisch aufgerufen — Claude gleicht deine Anfrage mit der Beschreibung des Skills ab und lädt ihn, ohne dass du irgendetwas benennst. Nutze einen Command, wenn du immer selbst entscheidest, ihn auszulösen; nutze einen Skill, wenn die Auslösebedingung etwas ist, das das Modell selbst erkennen sollte.

Wann sollte ich einen Subagent statt eines Skills verwenden?

Wenn die Aufgabe abgegrenzt und delegierbar ist und du willst, dass sie in ihrem eigenen Kontextfenster läuft, getrennt von deiner Hauptkonversation — nicht wegen wie sie ausgelöst wird, sondern wegen wo die Arbeit stattfindet. Skills und Subagents schließen sich nicht gegenseitig aus: Ein Skill kann intern Subagents starten, so wie ein Übersetzungs-Skill einen Beitrag auf einen Subagent pro Sprache aufteilen könnte.

Ist es sicher, einen Skill Aktionen wie Veröffentlichen oder Geldausgeben automatisch auslösen zu lassen?

Nur mit einem expliziten Freigabetor am folgenreichen Schritt. Der automatische Aufruf des Skills selbst ist unbedenklich — er bedeutet nur, dass Claude erkannt hat, worum du bittest. Das Risiko ist die automatische Ausführung von irgendetwas schwer Rückgängigzumachendem. Lass Entwerfen, Lesen und Berichten innerhalb des automatisch ausgelösten Skills geschehen; verlange eine separate, ausdrückliche Bestätigung für Veröffentlichen, Bezahlen oder Löschen.

Muss ich irgendwann alle drei bauen?

Nur wenn deine Workflows tatsächlich alle drei Formen haben. Ein Solo-Betreiber mit einer Handvoll wiederholbarer Aufgaben kann lange komplett mit Slash Commands auskommen. Der Bedarf an Skills und Subagents zeigt sich, sobald du genug unterschiedliche Auslösebedingungen hast, dass du dir die Command-Namen nicht mehr merken kannst, oder genug abgegrenzte Teilaufgaben, dass sie in deinem Hauptkontext zu behalten der Qualität schadet.

---

Verwandt: Der Claude Skill, der meine Facebook-Ads steuert · Context Engineering: Was ins Kontextfenster gehört · KI-Agenten mit Mensch im Loop: wann braucht es Freigaben? · Der Agenten-Stack, mit dem ich 30+ Produktionsagenten betreibe

Brauchst du Hilfe zu entscheiden, was du automatisierst und wie? Nimm Kontakt auf — ich entwerfe Produktionsagentensysteme für Operator-Teams.