Claude Code Skills, Hooks, Subagents oder MCP: Was man wann nutzt

Die vier Mechanismen, die Claude Code erweitern, lösen wirklich unterschiedliche Probleme. Ein Skill lehrt Claude, wie du etwas gemacht haben möchtest. Ein Hook garantiert, dass etwas passiert, unabhängig davon, was Claude entscheidet. Ein Subagent schützt den Kontext des Hauptgesprächs, indem er fokussierte Arbeit an einen sauberen Nebenprozess delegiert. Ein MCP-Server gibt Claude Zugriff auf ein System, das es ohne ihn buchstäblich nicht erreichen kann. Wählst du den falschen aus, landest du entweder bei einer „Regel", die das Modell stillschweigend ignorieren kann, oder bei einer MCP-Abhängigkeit, wo schlichte Anweisungen gereicht hätten.

Wähle einen Mechanismus nach der Aufgabe

Fang mit einer einzigen Diagnostikfrage an: Was fehlt wirklich?

Wenn die Antwort „Claude weiß nicht, wie ich das haben will" ist, dann ist das ein Skill. Commit-Nachrichtenformat, PR-Beschreibungsvorlagen, Lint-Richtlinien, Review-Checklisten. Das alles ist verpacktes Know-how, das bei Bedarf geladen wird und in deiner bestehenden Session läuft — ohne externe Abhängigkeit.

Wenn die Antwort „etwas muss an einem festen Punkt passieren und ich kann dem Modell nicht trauen, es zu merken" ist, dann ist das ein Hook. Hooks werden bei Lebenszyklusereignissen wie PreToolUse oder PostToolUse ausgelöst und laufen außerhalb von Claudes Kontext. Das Modell kann sie nicht überschreiben. CodingNomads beschreibt das gut: Hooks laufen deterministisch ab, ohne LLM-Einbindung und ohne Kontextkosten.

Wenn die Antwort „diese Unteraufgabe würde 40 Dateilesevorgänge in meinen Hauptthread ziehen" ist, dann ist das ein Subagent. Eigenes Kontextfenster, eigenes Token-Budget, meldet eine Zusammenfassung zurück. Leise und fokussiert.

Wenn die Antwort „Claude muss ein System wirklich anfassen, das es nicht erreichen kann" ist, dann ist das ein MCP-Server. Datenbanklesevorgänge, Slack-Posts, interne APIs, Notion-Seiten. Das sind keine Wissensprobleme, das sind Konnektivitätsprobleme, und nur MCP löst sie.

Und CLAUDE.md sitzt über allem als die ständig aktive Schicht. Jede Session liest sie automatisch. Halte sie unter 200 Zeilen, gemäß Anthropics eigener Anleitung, sonst verschwinden wichtige Einschränkungen und werden ignoriert.

Anweisungen, Toolzugriff, Ereignisse und isolierter Kontext

Was jeder Mechanismus wirklich kontrolliert:

• Skills: Anweisungen und Kontext, bei Bedarf in das aktuelle Gespräch geladen. Keine externen Aufrufe. Kein Event-Trigger. Das Modell entscheidet, wann ein Skill relevant ist, basierend auf der Beschreibung in seinem Frontmatter.
• MCP-Server: Toolzugriff. Claude ruft MCP-Tools so auf wie jedes andere Tool auch, aber die Ausführung findet in einem separaten Prozess via JSON-RPC statt. Ein MCP-Server verbindet Claude mit externen Systemen; ein Skill zeigt ihm, wie er sie richtig nutzt, sobald die Verbindung hergestellt ist.
• Hooks: Lebenszyklusereignisse. SessionStart, PreToolUse, PostToolUse, PreCompact. Sie laufen deterministisch ab. Ein Hook, der einen destruktiven Befehl blockiert, blockiert ihn jedes Mal, ob Claude das für eine gute Idee hielt oder nicht.
• Subagents: isolierter Kontext. Du übergibst einem Subagent einen Auftrag; er arbeitet unabhängig; er liefert ein Ergebnis zurück. Ein Test-schreibender Subagent braucht nicht von deiner Deployment-Pipeline zu wissen. Ein Dokumentations-Subagent braucht dein Datenbankschema nicht. Diese Trennung ist der ganze Sinn.

Skills und Commands sind hier eine kurze Notiz wert, weil sie leicht verwechselt werden. Laut der offiziellen Skills-Dokumentation werden Custom Commands in Skills integriert, nicht als sechstes separates System. Sie teilen sich das SKILL.md-Autorenmodell. Mehr dazu im nächsten Abschnitt.

Inventive HQs Analyse bringt es auf den Punkt: „Ein Skill ändert das Verhalten, ein Subagent schützt den Kontext, und ein MCP-Server fügt Fähigkeit hinzu, und ein Hook garantiert, dass eine Aktion deterministisch bei einem Ereignis läuft, egal was das Modell tun will."

Wo Slash Commands in Skills passen

Custom Slash Commands sind kein separater Mechanismus neben Skills. Sie sind die Aufrufsurface für Skills. Wenn du /deploy oder /review eingibst, rufst du einen Skill beim Namen auf. Dieser Skill enthält die Anweisungen, alle verknüpften Referenzdateien und den Kontext dafür, wie Claude diese Aufgabe handhaben soll.

Die Autorenaufgabe (das Schreiben einer SKILL.md mit guten Frontmatter-Beschreibungen), die Command-Lookup-Aufgabe (Entscheidung, welcher Kommandoname exponiert werden soll) und die Mechanismus-Vergleich-Aufgabe (Auswahl zwischen Skills und Hooks) sind drei verschiedene Leseanliegen. Sie teilen sich zufällig ein Dateiformat, was teilweise erklärt, warum die Verwirrung bestehen bleibt.

Wenn du entscheidest, ob du einen Skill überhaupt verwenden möchtest, lautet die Frage immer: Ist dies Wissen, das ich sonst erneut eingeben würde, oder ist dies etwas, das unabhängig von der Eingabe bei einem Ereignis ausgelöst werden muss? Das Erste ist ein Skill, möglicherweise als Kommando exponiert. Das Letzte ist ein Hook.

Für einen tieferen Blick darauf, wie CLAUDE.md Projektkontext in jede Sitzung einfließt, behandelt der CLAUDE.md-Leitfaden für Agenturen die Scoping und Dateistruktur im Detail.

Mechanismen für eine Repository-Aufgabe zusammensetzen

Die meisten realen Setups wählen nicht einfach einen Mechanismus und sind damit fertig. Sie setzen zwei oder drei zusammen. Hier ist ein anschauliches Szenario, das zeigt, wie das für einen PR-Workflow aussieht:

Das Linter-Beispiel lohnt sich zu betrachten. Moeeds Aufschlüsselung fasst es prägnant zusammen: „Der ‚Linter ausführen'-Teil ist eine Skill, Claude kann das, du möchtest nur Konsistenz. Der ‚nur committen wenn erfolgreich'-Teil ist ein Hook, das ist eine Garantie, keine Richtlinie. Sie arbeiten zusammen."

Das ist das praktische mentale Modell. Skills und Hooks arbeiten oft von verschiedenen Winkeln an derselben Aufgabe.

Häufige falsche Entscheidungen und wie man sie korrigiert

Ein paar Muster tauchen wiederholt auf:

1. MCP-Server für etwas, das nur Wissen war. Falls du dich dabei ertappst, einen MCP-Server zu starten, damit Claude auf dein Style Guide „zugreifen" kann, stopp. Das ist eine Skill. MCP ist für Konnektivität zu Live-Systemen, nicht zum Laden von Markdown-Dokumentation.
2. CLAUDE.md-Regel, die tatsächlich ein Hook ist. „Führe nie rm -rf aus" in CLAUDE.md ist ein Vorschlag, den das Modell technisch umgehen kann. Ein PreToolUse-Hook, der das Bash-Tool bei diesem Muster blockiert, ist ein harter Stopp. Wenn eine Regel garantiert sein muss, gehört sie in einen Hook, nicht in den Kontext.
3. Skill für eine Aufgabe, die ein eigenes Kontext-Budget braucht. Wenn die Arbeit das Lesen Dutzender Dateien umfasst, verschärft sich der Token-Verbrauch in deine Hauptsitzung schnell. Starte einen Subagenten. Er bekommt einen fokussierten Prompt, erledigt die Arbeit und gibt eine Zusammenfassung zurück. Dein Hauptkontext bleibt kohärent.
4. Subagent für etwas, das nur eine Anweisung brauchte. Subagenten haben Overhead. Falls Claude einfach deine Migrationskonvention kennen muss, schreib eine Skill. Starte keinen isolierten Worker für ein Wissensproblem.
5. Überladenes CLAUDE.md. Nach 200 Zeilen sagt Anthropics eigene Anleitung, dass kritische Constraints verloren gehen. Verschiebe Referenzmaterial zu Skills oder teile es in .claude/rules/-Dateien auf, die conditional basierend auf Pfad-Matching laden.

Wenn du einen Claude Code-Workflow von Grund auf aufbaust und einen strukturierten Startpunkt möchtest, führt dich der Claude Code-Workflow-Guide durch die Sequenzierung dieser Schichten für ein echtes Repository-Setup.

Folge dem relevanten Implementierungsleitfaden

Sobald du den richtigen Mechanismus identifiziert hast, teilen sich die Implementierungswege sauber auf. Dieser Beitrag ist eine Navigations- und Vergleichsebene, keine Setup-Anleitung. Hier geht es als Nächstes hin, nach Mechanismus:

• Hooks-Setup: Der Claude Code-Hooks-Guide deckt Lifecycle-Ereignisse, Handler-Typen und das Schreiben von Shell- und HTTP-Handlern ab, die deterministisch ausgeführt werden.
• Subagenten: Der Claude Code-Subagenten-Guide erklärt, wie du einen Subagenten briefst, seine Tool-Berechtigungen definierst und das Ergebnis in der Hauptsitzung handhabst.
• Subagenten: Der Claude Code-Subagenten-Guide erklärt, wie du einen Subagenten briefst, seine Tool-Berechtigungen definierst und das Ergebnis in der Hauptsitzung handhabst.
• Skills: Beginne mit der offiziellen Skills-Dokumentation, die SKILL.md-Struktur, Frontmatter-Beschreibungen und die Zuordnung von benutzerdefinierten Befehlen zu Skill-Dateien abdeckt.

Versuchen Sie nicht, alle vier auf einmal zu lesen, bevor Sie entschieden haben, welcher Mechanismus gilt. So landen Sie drei Stunden tief in der Hook-Konfiguration, wenn Sie nur eine zweizeilige Fähigkeit brauchten.

FAQ

Ist CLAUDE.md ein Mechanismus, den ich in diese Entscheidung einbeziehen sollte?

Ja, aber es ist eine andere Art von Entscheidung. CLAUDE.md wird nicht zur Aufgabenzeit ausgewählt. Es lädt sich automatisch jede Sitzung. Die Frage für CLAUDE.md lautet: „Braucht Claude diese Information jedes einzelne Mal, ohne Bedingung?" Wenn ja, dann gehört sie dort hin. Falls die Anweisung nur für bestimmte Aufgaben relevant ist, gehört sie in eine Fähigkeit mit einer spezifischen Frontmatter-Beschreibung.

Kann eine Fähigkeit einen MCP-Server-Aufruf auslösen?

Ja. Eine Fähigkeit kann Claude anweisen, verfügbare MCP-Tools als Teil eines Workflows zu nutzen. Die Fähigkeit stellt das Wie zur Verfügung (was zu fragen ist, in welcher Reihenfolge, mit welchen Formatierungserwartungen) und der MCP-Server stellt den Zugriff zur Verfügung. Sie ergänzen sich, sie konkurrieren nicht.

Was ist der Unterschied zwischen einem Subagenten und einem Agent-Team?

Ein Subagent ist ein Helfer, den Sie aus der Hauptsitzung entsenden, um eine fokussierte Teilaufgabe zu bearbeiten. Ein Agent-Team ist eine Reihe von Peer-Sitzungen, die direkt miteinander kommunizieren können, geeignet für echte parallele Zusammenarbeit. Für die meisten Repository-Aufgaben ist ein Subagent die richtige Wahl. Agent-Teams ergeben Sinn, wenn mehrere unabhängige Arbeitsströme koordiniert werden müssen, anstatt dass eine Sitzung nach unten delegiert.

Haben Hooks Zugriff auf Claudes Kontext?

Nein. Das ist der Sinn dahinter. Hooks laufen außerhalb von Claudes Kontext und das Modell kann sie nicht außer Kraft setzen. Das macht sie zum richtigen Werkzeug für harte Garantien: Sicherheitsprüfungen, obligatorische Linting-Durchläufe, gesperrte Dateimuster. Der Kompromiss ist, dass ein Hook keine differenzierten Entscheidungen auf Grundlage dessen treffen kann, was Claude über die Aufgabe versteht. Er wird beim Ereignis ausgelöst und führt seinen Handler aus.

Wann macht es Sinn, alle vier Mechanismen zusammen zu nutzen?

Wenn Sie einen Workflow mit mehreren unterschiedlichen Fehlermodi haben: eine Wissenslücke (Fähigkeit), eine Konnektivitätsanforderung (MCP), ein Kontext-Bleed-Risiko (Subagent) und mindestens eine Aktion, die garantiert sein muss, unabhängig vom Modellurteil (Hook). Die meisten einfachen Aufgaben benötigen einen oder zwei Mechanismen. Auf jede Aufgabe alle vier Mechanismen anzusetzen, erhöht den Overhead ohne Nutzen.

Die schärfste Unterscheidung in diesem ganzen Vergleich: Eine Fähigkeit ist ein Vorschlag, den Claude liest und befolgt; ein Hook ist eine Regel, die das System durchsetzt, egal ob Claude zustimmt oder nicht. Wenn Sie das falsch verstehen, ist Ihre „Sicherheitsregel" nur eine höfliche Bitte.