In den bisherigen fünf Kapiteln haben wir Claude Code installiert, Anweisungen gegeben, Sackgassen verlassen und die Rechte entworfen. In diesem Kapitel geht es darum, das Werkzeug selbst umzubauen. Erweiterungen lassen sich nicht dadurch benutzen, dass man ihre Namen kennt. Nützlich ist eine Zuordnungstabelle zur Frage: „Womit löse ich genau diesen Ärger?“

Die Landkarte der Auswahl – vier Fragen entscheiden

Es gibt sechs Erweiterungen, aber nur vier Dinge zu bedenken. Reicht eine Bitte? Soll es verlässlich wirken? Soll es in einen eigenen Kontext ausgelagert werden? Soll es nach draußen verbinden? Wer sich das in dieser Reihenfolge fragt, landet meist bei genau einer Antwort.

Q1
Reicht eine Bitte

Wenn ein gelegentliches Aussetzen nicht fatal ist, genügen Worte. → CLAUDE.md (Voraussetzungen für alles) / Skills (Abläufe für bestimmte Arbeiten)

Q2
Soll es verlässlich wirken

Wenn schon ein einziges Aussetzen Ärger macht, halten Sie es mit einem Mechanismus auf. → hooks. Sie laufen ohne Umweg über das Urteil des Modells in jedem Fall.

Q3
Soll es in einen eigenen Kontext

Wenn massenhafte Ausgabe den Hauptstrang nicht zuschütten soll, lassen Sie es draußen erledigen und nehmen nur das Fazit entgegen. → subagents

Q4
Soll es nach draußen verbinden

Wenn Informationen nötig sind, die die KI unmöglich kennen kann (der aktuelle Wert in der Datenbank, der Inhalt der Aufgabenverwaltung). → MCP

Die fünfte Frage lautet: „Soll das auch an andere gehen?“ Wenn ja, dann plugins. Leicht zu verwechseln sind Q1 und Q2, also CLAUDE.md, Skills und hooks. Sie sehen alle gleich aus, unterscheiden sich aber darin, wann sie gelesen werden und wer sie ausführt.

CLAUDE.md – ein Gedächtnis, das bleibt. Nur nicht, wenn es lang wird

Die CLAUDE.md ist eine Datei, die bei jeder Sitzung automatisch gelesen wird, wenn Sie sie in das Wurzelverzeichnis des Projekts legen (für alle Projekte gemeinsam: ~/.claude/CLAUDE.md). Weil sie eine Datei ist, betrifft sie das „vergisst den Anfang, wenn es lang wird“ aus Kapitel 1 nicht. Sie ist der Ort für das, was Sie sonst jedes Mal erklären.

„Es sagt, es habe gelesen, hält sich aber nicht daran“ ist keine Faulheit, sondern ein Strukturproblem mit drei Ursachen.

  • Die Mitte sinkt ab – Anweisungen in der Mitte eines langen Textes werden leicht übersehen, und je weiter Sie ihn dehnen, desto mehr verschwinden die Regeln der Mitte faktisch
  • Die Verdichtung fasst zusammen – läuft eine Verdichtung, werden kleinteilige Betriebsregeln zerdrückt. Dass die Verstöße gegen Ende zunehmen, hat genau darin seinen Grund
  • Die jüngste Anweisung gewinnt – „committe das erst mal“ lässt einen Prüfablauf, der vor einigen hundert Zügen gelesen wurde, unbeachtet durchrutschen

Die Abhilfe ist Streichen. Erfahrungsgemäß wirkt es zuverlässig bis etwa 100 bis 150 Zeilen. Bei mehr lassen Sie nur die entscheidenden Gebote am Anfang stehen und schieben die Einzelheiten in eine eigene Datei (Doppelungen erzeugen Abweichungen, also eine einzige maßgebliche Fassung). Nur was unverzichtbar ist, bekommt ein „CRITICAL“, und formulieren Sie es so, dass es von außen beurteilbar ist – nicht „sorgfältig schreiben“, sondern „in höchstens 3 Zeilen schreiben“.

„Ich habe es gelesen“ ist kein Beweis. Die einzige Entscheidungsgrundlage ist das Verhalten nach der Ausführung. Eine Regel, die auch nach mehrmaligem Umschreiben nicht eingehalten wird, hat kein Formulierungsproblem – sie gehört in den nächsten Abschnitt.

hooks – keine Bitte, sondern verlässliche Wirkung

„Ändere die .env nicht“ – in die CLAUDE.md geschrieben, wird das in neun von zehn Fällen befolgt. Wenn ein Zehntel Aussetzer keinen Schaden anrichtet, genügt ein Satz. Richtet es Schaden an, nehmen Sie hooks – das ist die Weggabelung.

hooks sind Shell-Befehle, die zu festgelegten Zeitpunkten automatisch ausgeführt werden. Ausgeführt werden sie nicht vom Modell, sondern von Claude Code selbst (dem Rahmenprogramm), sie laufen also ohne auf ein Urteil zu warten in jedem Fall. Das Gesamtbild behandelt Was Claude Code hooks sind. Es gibt neun gängige Auslösepunkte.

SessionStart beim Start oder Fortsetzen UserPromptSubmit direkt nach dem Absenden [kann blockieren] PreToolUse direkt vor einem Werkzeug = Torwächter [kann blockieren] PostToolUse nach dem Erfolg eines Werkzeugs = Formatieren [kann blockieren] Notification wartet auf Eingabe oder Freigabe Stop Ende einer Antwort [kann blockieren] SubagentStop Subagent beendet [kann blockieren] SessionEnd Sitzung endet PreCompact vor der Verdichtung [kann blockieren]

„Kann blockieren“ heißt, dass Sie an dieser Stelle die Handlung anhalten können. Gefährliche Befehle bei PreToolUse abweisen, bei PostToolUse automatisch formatieren – diese beiden sind der übliche Einstieg. Die Konfiguration steht unter dem Schlüssel "hooks" in der settings.json, und der Ablageort bestimmt den Geltungsbereich (~/.claude/ = Sie, .claude/ = geteilt, settings.local.json = nur Sie).

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "..." } ] } ] } }

Der Aufbau ist Ereignisname → ein Feld aus Matcher und Befehl. matcher ist der Name des betroffenen Werkzeugs (mit | getrennt wie in "Edit|Write"; weggelassen trifft es auf alles zu). Ein Hook nimmt JSON über die Standardeingabe entgegen und antwortet über den Beendigungscode – 0 ist Erfolg, 2 ist Blockade (die Standardfehlerausgabe wird an Claude übergeben). Auch der betroffene Dateipfad steht im eingehenden JSON, „bei diesem Pfad anhalten“ lässt sich also formulieren.

Hooks können Beschränkungen verschärfen, aber nicht lockern. Auch wenn sie eine Freigabe zurückgeben, überspringen sie damit nur die Rückfrage; Verweigerungsregeln haben immer Vorrang. Eine Verweigerung bei PreToolUse wirkt auch in dem Modus, der alle Bestätigungen überspringt, sie taugt also als Boden unter dem, was Sie in Kapitel 5 gelockert haben.

Der Preis gleich vorweg: hooks führen beliebige Shell-Befehle automatisch mit Ihren Rechten aus. Auch offiziell steht ausdrücklich, dass die Verantwortung vollständig bei Ihnen liegt. Richten Sie nur Vertrauenswürdiges ein und prüfen Sie die Eingaben. Die Konfiguration wird beim Sitzungsstart festgeschrieben, öffnen Sie also eine neue Sitzung, wenn es heißt „ich habe es korrigiert, und es wirkt nicht“.

subagents – den Kontext trennen und abgeben

Die vollständige Ausgabe eines Testlaufs, ein riesiges Log – wenn sich Textmassen ansammeln, die eigentlich zum Wegwerfen gelesen wurden, werden die entscheidenden Voraussetzungen hinausgedrängt. subagents sind der Mechanismus, diese Arbeit in einem eigenen Kontext laufen zu lassen und nur die Zusammenfassung des Fazits entgegenzunehmen. Sie haben ein eigenes Kontextfenster, einen eigenen Systemprompt und eigene Werkzeugrechte, und weil sie Ihren Gesprächsverlauf nicht sehen, kommt der Schutt der Recherche nicht in den Hauptstrang zurück.

  • Trennen lohnt sich – breit angelegte Untersuchungen / Prüfungen mit massenhafter Ausgabe / in sich geschlossene Aufgaben, bei denen nur das Fazit zählt
  • Trennen schadet – schrittweise Verarbeitung / häufiges Hin und Her / paralleles Arbeiten an derselben Datei / Korrekturen, die nach ein bis zwei Zügen fertig sind

Es ist eine Standardfunktion und ohne Konfiguration nutzbar. Wollen Sie eigene Definitionen ergänzen, schreiben Sie in .claude/agents/<Name>.md (gemeinsam: ~/.claude/agents/) im YAML-Frontmatter name, description, tools und model. Verwaltet wird mit /agents, aufgerufen mit @agent-<Name>. Fangen Sie mit den mitgelieferten für Erkundung, Planung und allgemeine Zwecke an.

Der Schlüssel zum Aufruf ist die description. Der Hauptagent entscheidet anhand dieser Beschreibung, ob er delegiert; ist sie vage, wird der Subagent nie aufgerufen. Formulieren Sie konkret, was er tut und wann er einzusetzen ist – dieselbe Falle gibt es auch bei den Skills.

Leicht damit zu verwechseln sind Agent Teams: ein Mechanismus, bei dem mehrere unabhängige Sitzungen über eine gemeinsame Aufgabenliste zusammenarbeiten. Er ist experimentell, muss aktiv eingeschaltet werden und ist standardmäßig deaktiviert (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Weil dabei eigene Instanzen laufen, ist der Tokenverbrauch hoch, und verschachteln lässt es sich auch nicht. Den Unterschied vergleicht Der Unterschied zwischen subagents und Agent Teams. Im Zweifel eine einzelne Sitzung oder subagents.

Skills – aus Abläufen ein Kapital machen

Für Standardabläufe nach dem Muster „jedes Mal so vorgehen“ liegt die Stärke der Skills darin, dass sie nur bei Bedarf geöffnet werden. Der Kern ist ein Ordner um eine SKILL.md. Ganz oben stehen name und description, darunter der Ablauf in Markdown, und reference/ sowie scripts/ können mitgeliefert werden. Es genügt, das Ganze in .claude/skills/ (Projekt) oder ~/.claude/skills/ (gemeinsam) zu legen, damit es erkannt wird.

Entscheidend ist die stufenweise Offenlegung. Beim Sitzungsstart wird nur die kurze description jedes Skills gelesen, und erst wenn ein Auftrag dazu passt, werden der Haupttext und die Materialien geladen. Deshalb füllen selbst Dutzende von Skills den alltäglichen Kontext kaum – der entscheidende Unterschied zur CLAUDE.md, die immer vollständig mitläuft. Umgekehrt gilt: Was nicht passt, wird nie geöffnet. Ist die description vage, ist der aufgeschriebene Ablauf so gut wie nicht vorhanden. Wie man sie schreibt, behandelt Was Claude Agent Skills sind.

In einem Satz: CLAUDE.md = Voraussetzungen, die immer gelesen werden, Skills = ein Handbuch, das Claude nach eigenem Urteil aufschlägt, hooks = eine Verarbeitung, die in jedem Fall läuft.

MCP – nach draußen zu anderen Systemen greifen

Die bisherigen drei waren Erweiterungen, die die Vorgehensweise ändern. Allein MCP (Model Context Protocol) erweitert die Reichweite – ein Standard, der die Hand an Dinge reichen lässt, die eine KI strukturell nicht wissen kann, etwa den aktuellen Wert in einer Datenbank oder ein Ticket in der Aufgabenverwaltung. Es gibt zwei Formen der Verbindung, und sie haken an verschiedenen Stellen.

  • Lokal (stdio) – der Server wird auf Ihrem Rechner als Unterprozess gestartet. Es hakt beim Start selbst (Pfad, Umgebungsvariablen, Auflösung des Befehls)
  • Entfernt (HTTP) – Verbindung über eine URL zu einem Server in der Cloud. Es hakt fast immer an der Authentifizierung, also an einem zurückgegebenen 401 oder 403

Werfen Sie „es verbindet nicht“ deshalb nicht in einen Topf, sondern sehen Sie zuerst mit /mcp den Status an. Bei failed geht es um den lokalen Start, bei needs authentication um die Authentifizierung der Gegenstelle, bei pending approval um eine ausstehende Freigabe – der Status bestimmt den Zug. Die Abhilfen stehen gesammelt unter Wie Sie MCP-Serververbindungsfehler beheben.

Es gibt auch eigene Fallstricke. Die geteilte Konfiguration .mcp.json gehört direkt in das Wurzelverzeichnis des Repositorys (weder unter .claude/ noch in die settings.json), und API-Schlüssel gehören in das env je Server. Unter Windows ist npx in Wirklichkeit eine Batchdatei, es funktioniert also, wenn Sie es über cmd als /c npx ... übergeben.

Angeschlossene Server verbrauchen Kontext. Schon dadurch, dass sich Werkzeugdefinitionen ansammeln, wird der Kontext eng. Server, die Sie nicht benutzen, deaktivieren Sie besser.

plugins – ein Paket schnüren und weitergeben

Wenn sich Skills, Subagenten-Definitionen, Hooks und MCP-Konfiguration zu verstreuen beginnen, bringen plugins sie in eine Form, die sich bündeln und weitergeben lässt. Leicht falsch macht man die Verzeichnisregel. Das Manifest ist .claude-plugin/plugin.json, und mehr kommt nicht in .claude-plugin/. skills/, agents/, hooks/hooks.json und .mcp.json liegen im Wurzelverzeichnis.

/plugin marketplace add owner/repo ← einen Katalog registrieren /plugin install name@marketplace ← daraus einzeln installieren /plugin list ← nachsehen, was installiert ist

Die Einführung hat zwei Stufen. Den Katalog registrieren und darauf einzeln installieren – vom bloßen Hinzufügen ist noch nichts installiert. Der Geltungsbereich ist user (alle Projekte), project (alle Mitarbeitenden), local (nur Sie) oder managed (von der Verwaltung verteilt, nicht änderbar); für ein einheitliches Team nehmen Sie project. Wie Sie selbst eines bauen, behandelt Was plugins und marketplace sind.

Ein Plugin kann beliebigen Code mit Ihren Rechten ausführen – so steht es ausdrücklich in der offiziellen Dokumentation. Anthropic prüft weder Plugins von Dritten noch die darin mitgelieferten MCP-Server. Installieren Sie nur, was von einem vertrauenswürdigen Herausgeber stammt. Der Rechteentwurf aus Kapitel 5 kommt hier als Code, den andere geschrieben haben, auf Sie zurück.

Womit anfangen – eine Frage der Reihenfolge

Wir haben sechs aufgezählt, aber Sie müssen nicht alle einführen. Wer sie einführt, solange es keinen Ärger gibt, erhöht nur die Komplexität der Konfiguration. Die Reihenfolge ergibt sich aus dem Symptom.

  • Sie erklären jedes Mal dasselbe → CLAUDE.md. Betrifft es nur eine bestimmte Arbeit, dann Skills
  • Sie haben es aufgeschrieben, und es wird nicht befolgt → zuerst streichen. Nur was echten Schaden anrichtet, wandert zu hooks
  • Der Kontext ist sofort voll → schwere Recherchen an subagents / nicht benötigte MCP-Server deaktivieren
  • Die KI kommt an die Information nicht heran → MCP. Einen nach dem anderen anschließen und erst weitermachen, wenn einer läuft
  • Sie wollen dieselbe Konfiguration verteilen → plugins. Bündeln Sie nur, was Sie selbst benutzen können
  • Es gibt keinen besonderen Ärger → gar nichts einführen. Das ist der beste Zustand

Die letzte Zeile ist kein Scherz. Erweiterungen vermehren auch die Ursachen des Steckenbleibens – oft steckt hinter „Claude Code spinnt“ eine Schicht, die man selbst ergänzt hat. Deshalb kommt die Eingrenzung aus Kapitel 4 zuerst.

Zusammenfassung

  • Ausgewählt wird nach vier Fragen: Reicht eine Bitte (CLAUDE.md, Skills)? Soll es verlässlich wirken (hooks)? Soll es in einen eigenen Kontext (subagents)? Soll es nach draußen verbinden (MCP)? Zum Weitergeben plugins
  • Die CLAUDE.md ist ein Gedächtnis über Sitzungen hinweg. Wird sie lang, sinkt die Mitte ab, die Verdichtung verdünnt sie, und die jüngste Anweisung schlägt sie. Streichen und die Prioritäten deutlich machen
  • hooks werden vom Rahmenprogramm ausgeführt, also ohne dass ein Urteil dazwischentritt. Sie können Beschränkungen verschärfen, aber nicht lockern
  • subagents arbeiten in einem eigenen Kontext und liefern nur eine Zusammenfassung zurück. Für schrittweise Verarbeitung und häufiges Hin und Her taugen sie nicht
  • Skills werden nur geöffnet, wenn die description passt – stufenweise Offenlegung. Auch viele bleiben leicht, aber eine vage Beschreibung wird nie aufgerufen
  • MCP ist der Standard, der die Reichweite erweitert. Der Status von /mcp bestimmt den Zug
  • plugins sind die Schachtel für die Weitergabe. Fremder Code läuft mit Ihren Rechten, prüfen Sie also den Herausgeber
  • Die Reihenfolge der Einführung ergibt sich aus dem Symptom. Eines nach dem anderen, sobald ein Ärger entsteht

Je weiter Sie erweitern, desto mehr wird verbraucht. Zum Schluss behandeln wir den Betrieb für den langen Einsatz. Weiter zu Kapitel 7 „Kosten und Grenzen“.