Claude Code Skills vs. Subagents vs. Slash Commands
Wann ein Skill, wann ein Subagent, wann ein Command-File? Entscheidungshilfe zu Kontext, Invocation, Tools und Kosten in Claude Code, mit Frontmatter-Beispielen.
Grafik: Vibecoding Pro · Grundlage: die Quellen unten
Im Repo liegen drei Ordner nebeneinander: .claude/commands/, .claude/skills/ und .claude/agents/. Alle drei nehmen Markdown mit Frontmatter, alle drei sehen ähnlich aus. Die Wahl entscheidet trotzdem darüber, was im Hauptkontext landet, wer die Ausführung auslöst und welche Tools laufen dürfen. Falsch gewählt, zahlt man das in Tokens oder in Agenten, die zur falschen Zeit deployen.
Hier die Abgrenzung nach dem Stand der Skills-Doku und der Subagent-Doku von Claude Code.
Slash Commands: das Altformat
Eine Datei .claude/commands/deploy.md wird zu /deploy, ein Unterordner wird per Doppelpunkt eingehängt: .claude/commands/frontend/component.md ergibt /frontend:component. Command-Files akzeptieren dieselbe Frontmatter wie Skills, nur name und paths nicht.
Die Doku nennt das Format ausdrücklich das ältere und empfiehlt für neue Arbeit Skills, weil nur die Supporting Files mitbringen können. Bestehende Commands musst du nicht migrieren. Neue legst du als Skill an.
Skills: Prozedur und Wissen im Hauptkontext
Ein Skill ist ein Ordner mit SKILL.md und optionalen Scripts, Referenzen und Assets. Claude Code folgt dabei dem offenen Agent-Skills-Standard und erweitert ihn um Invocation-Kontrolle, Ausführung im Subagent und dynamische Context-Injection.
Zwei Frontmatter-Felder steuern, wer auslöst:
---
name: deploy
description: Deploy auf Staging nach grünem CI
disable-model-invocation: true # nur per /deploy, Claude startet ihn nie selbst
---user-invocable: false macht das Gegenteil: Nur Claude lädt den Skill, etwa für Hintergrundwissen zu einem Legacy-System, das als Command keinen Sinn ergibt.
Der Trade-off ist der Kontext. Nach dem Aufruf bleibt der gerenderte Inhalt über alle weiteren Turns im Gespräch, Claude Code liest die Datei nicht neu. Jede Zeile ist wiederkehrender Token-Aufwand. Nach einer Compaction kann nur der Anfang erhalten bleiben, also gehört das Wichtigste nach oben. Und allowed-tools gibt nur für den aufrufenden Turn Freigaben, es schränkt keine Tools ein. Harte Grenzen bleiben Sache der Permissions in settings.json.
Subagents: eigener Kontext, eigene Grenzen
Ein Subagent in .claude/agents/ läuft in einem frischen Kontextfenster mit eigenem System-Prompt, eigener Tool-Liste und eigenen Permissions. Er sieht weder deine History noch bereits geladene Skills oder gelesene Files und liefert am Ende nur eine Zusammenfassung zurück. Laut Doku lohnt er sich, wenn eine Nebenaufgabe den Hauptkontext mit Suchergebnissen, Logs oder Dateiinhalten fluten würde, die du nie wieder brauchst.
---
name: code-reviewer
description: Read-only Review geänderter Dateien
tools: Read, Grep, Glob, Bash
model: haiku
skills:
- review-checklist
---tools ist eine Allowlist, disallowedTools eine Denylist, die zuerst angewendet wird. Das skills-Feld lädt den vollen Inhalt der genannten Skills beim Start vor. Ohne das Feld kann der Subagent Skills trotzdem über das Skill-Tool aufrufen. Mit model: haiku routest du Arbeit auf ein günstigeres Modell. Die Requests des Subagents zählen aber auf dieselben Usage-Limits.
Zwei Grenzen solltest du kennen: Ab 15.000 Tokens kombinierter Descriptions eigener Subagents warnt Claude Code beim Start. Und Subagents können standardmäßig bis zu drei Ebenen tief weitere Subagents starten, steuerbar über CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Mehr zur Architektur steht in Kontext-Isolation und wann sie lohnt.
Die Mischform: context: fork
Ein Skill mit context: fork startet einen Subagent des Typs aus dem Feld agent und gibt ihm den Skill-Inhalt als Prompt. Der Subagent sieht deine Konversation nicht, die Anweisungen müssen also für sich stehen. Mit agent: Explore startet er zudem ohne CLAUDE.md, weil Explore und Plan bewusst schlank laden.
Die Faustregel daraus: Bei context: fork schreibst du die Aufgabe und leihst dir einen Worker. Beim eigenen Subagent definierst du den Worker und gibst ihm Skills als Referenz mit.
Was das für deinen Workflow bedeutet
- Wiederholbare Prozedur, die du selbst triggerst (Commit, Deploy, Release): Skill mit
disable-model-invocation: true. - Wissen, das Claude bei Bedarf ziehen soll: Skill, kurz gehalten, Kerninfos oben. Projektweite Regeln gehören eher in CLAUDE.md und .claude/rules.
- Lauter, lesender Seitenauftrag (Codebase-Recherche, Log-Analyse): Subagent oder Skill mit
context: fork. - Harte Tool-Grenzen oder anderes Modell: eigener Subagent mit
toolsundmodel. - Bestehende Command-Files: lassen, neue nicht mehr anlegen.
Du willst wissen, ob die Abstraktionen in deinem Repo richtig geschnitten sind? Fordere ein Agent-Setup-Review an und bekomm priorisierte Änderungsvorschläge für Skills, Subagents und Permissions.
Häufige Fragen
Sind Slash Commands in Claude Code veraltet?
Command-Files in .claude/commands/ sind laut Doku das ältere Format und funktionieren weiter, mit derselben Frontmatter außer name und paths. Für neue Arbeit empfiehlt die Doku Skills, weil sie zusätzlich Supporting Files unterstützen.
Was ist der Unterschied zwischen einem Skill mit context: fork und einem Subagent?
Bei context: fork schreibst du die Aufgabe im Skill und wählst über das agent-Feld einen Agent-Typ, der sie ausführt. Bei einem eigenen Subagent definierst du den Worker selbst, mit System-Prompt, Tools und Modell, und kannst Skills als Referenz vorladen.
Kostet ein geladener Skill dauerhaft Kontext?
Ja. Der gerenderte SKILL.md-Inhalt bleibt nach dem Aufruf über spätere Turns im Kontext, jede Zeile ist also wiederkehrender Token-Aufwand. Nach einer Compaction bleibt eventuell nur der Anfang erhalten, deshalb gehören die wichtigsten Anweisungen nach oben.
Wie verhindere ich, dass Claude einen Deploy-Skill selbst startet?
Setz disable-model-invocation: true in die Frontmatter. Dann kann nur du den Skill per /name aufrufen, und er wird auch nicht in Subagents vorgeladen.