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. Command-Hooks starten bei passenden konfigurierten Ereignissen und Bedingungen, ohne dass das Modell sie eigens anfordern muss.

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 – Laden und Einhalten getrennt prüfen

CLAUDE.md stellt jeder Sitzung Projektkontext bereit, sofern die Datei an einem geladenen Ort liegt. Für projektübergreifende Anweisungen verwenden Sie ~/.claude/CLAUDE.md. Sie enthält textliche Anweisungen, keine Einstellungen zur Durchsetzung von Ausführungsrechten.

Meldet der Agent, er habe die Datei gelesen, befolgt sie aber nicht, prüfen Sie diese drei Fragen getrennt.

  • Wurde sie geladen? Sehen Sie nach, ob CLAUDE.md und Regeln unter „Memory files“ in /context aufgeführt sind. Startverzeichnis und Ausschlusseinstellungen bestimmen den Umfang. Direkt geladenes AGENTS.md erscheint nicht in dieser Liste; sein Fehlen beweist daher nicht, dass es ungelesen blieb
  • Kehrte sie nach der Verdichtung zurück? Die CLAUDE.md im Projektstamm wird nach /compact erneut vom Datenträger geladen und eingefügt. CLAUDE.md-Dateien in Unterverzeichnissen und pfadbezogene Regeln kehren beim Lesen passender Dateien zurück. Reine Gesprächsabsprachen werden anders behandelt
  • Wirkte sie auf die Handlung? Auch wenn sie geladen wurde, prüfen Sie vage Regeln und widersprüchliche Anweisungen gesondert. Gehen Sie nicht davon aus, dass die neueste Anweisung immer gewinnt. Legen Sie Geltungsbereiche und Ausnahmebedingungen fest

Die offizielle Empfehlung lautet weniger als 200 Zeilen pro CLAUDE.md-Datei. Das ist weder eine Ladegrenze noch eine Grenze, die Einhaltung garantiert. Behalten Sie ständig benötigte Regeln und lagern Sie Einzelheiten mit Lesebedingungen aus. Alles über @path zu importieren reduziert den Startkontext nicht. Skills eignen sich für gelegentliche Abläufe, pfadbezogene Regeln für Anweisungen zu bestimmten Dateien.

Dies folgt der offiziellen Dokumentation zum Gedächtnis. Praktische Beispiele zur Unterscheidung und Unterschiede zwischen Werkzeugen erläutert die Untersuchung übergangener Regeln bei KI-Agenten.

„Ich habe es gelesen“ beweist keine Einhaltung. Prüfen Sie die Ladeanzeige getrennt von Diffs und Testergebnissen. Überführen Sie maschinell prüfbare Bedingungen wie im nächsten Abschnitt in Hooks oder CI und benennen Sie ungeprüfte Bereiche.

hooks – Prüfungen bei passenden Bedingungen ausführen

Eine Anweisung wie „Ändere die .env nicht“ garantiert keine bestimmte Einhaltungsquote. Wenn Sie eine Bedingung prüfen und einen Vorgang vor der Ausführung blockieren müssen, kommen Berechtigungseinstellungen und Hooks infrage.

Dieser Abschnitt behandelt Hooks vom Typ command, die Shell-Befehle ausführen. Stimmen aktivierte Einstellungen, Ereignis und Bedingungen überein, startet Claude Code selbst die Befehle. Das Modell muss sich nicht an die Ausführung erinnern. Ist die Einstellung jedoch deaktiviert oder läuft ein Vorgang über einen nicht erfassten Weg, greift der Hook nicht. Einen Überblick bietet Was Claude Code Hooks sind. Die folgenden neun Ereignisse sind Beispiele, keine vollständige Liste.

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 = Formatieren (macht die abgeschlossene Handlung nicht rückgängig) 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]

Was sich blockieren lässt, hängt vom Ereignis ab. Ein Werkzeug vor der Ausführung zu stoppen ist etwas anderes, als das Ende einer Antwort zu verhindern, damit die Arbeit weitergeht. Gefährliche Vorgänge bei PreToolUse abweisen und bei PostToolUse automatisch formatieren sind zwei übliche Einstiege. Die Konfiguration steht unter dem Schlüssel "hooks" in settings.json. Der Ablageort bestimmt den Geltungsbereich (~/.claude/ = Nutzer, .claude/ = gemeinsam, settings.local.json = persönlich).

Machen wir aus der Bitte vom Anfang, „Ändere die .env nicht“, nun einen Mechanismus. Dazu wird das Beispiel „Bearbeitung geschützter Dateien blockieren“ aus dem offiziellen Leitfaden auf .env eingegrenzt. Sie brauchen zwei Dinge: eine Einstellung und ein Skript.

① .claude/settings.json – führt das Skript unmittelbar vor jedem Aufruf von Edit oder Write aus.

{ "hooks": { "PreToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-env.sh" } ] } ] } }

② .claude/hooks/protect-env.sh – blockiert, wenn der Dateiname des Bearbeitungsziels mit .env beginnt (einschließlich .env.local usw.). Unter macOS und Linux machen Sie das Skript mit chmod +x .claude/hooks/protect-env.sh ausführbar.

#!/bin/bash # .claude/hooks/protect-env.sh command -v jq >/dev/null || { echo "jq nicht gefunden, Bearbeitung wurde blockiert" >&2; exit 2; } FILE_PATH=$(jq -r '.tool_input.file_path // empty') FILE_PATH="${FILE_PATH//\\//}" # Windows-Trennzeichen \ in / umwandeln if [[ "${FILE_PATH##*/}" == .env* ]]; then echo "Blocked: $FILE_PATH ist eine .env-Datei und wird nicht bearbeitet" >&2 exit 2 fi exit 0

Der Aufbau lautet Ereignisname → eine Liste aus Matchern und Befehlen. matcher bezeichnet Werkzeugnamen; "Edit|Write" trifft auf Edit oder Write zu (ohne Matcher werden alle Werkzeuge erfasst). Hooks empfangen JSON über die Standardeingabe; bei Edit und Write steht in tool_input.file_path der absolute Pfad der zu bearbeitenden Datei. Unter Windows ist das Trennzeichen in diesem Pfad \, daher wandelt das Skript es vor dem Vergleich in / um. Blockiert der Hook mit dem Exit-Code 2, erhält Claude den Text auf der Standardfehlerausgabe als Begründung der Ablehnung und sucht daraufhin einen anderen Weg. 1 gilt als nicht blockierender Fehler, der Vorgang läuft weiter; zum Blockieren verwenden Sie also 2. 0 bedeutet keinen Einwand; es folgt die übliche Berechtigungsprüfung.

Das Skript verwendet bash und jq (auch das Beispiel im offiziellen Leitfaden setzt jq voraus). Unter Windows laufen Hooks in Git Bash und, falls Git Bash fehlt, in PowerShell; für dieses Beispiel brauchen Sie daher Git Bash. Damit ein fehlendes jq nicht zum stillen Durchlassen führt, blockiert das Skript gleich im ersten Schritt.

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.

Getestet wird wie im offiziellen Leitfaden: Bitten Sie Claude „Füge der .env eine Kommentarzeile hinzu“. Der Vorgang wird vor der Bearbeitung gestoppt, und Claude erhält den Text mit Blocked:. Prüfen Sie zugleich, dass sich andere Dateien als .env weiterhin bearbeiten lassen. Ist der Pfad zum Skript falsch, erscheint nur der Hinweis Failed with non-blocking status code, und das Tor bleibt offen; achten Sie daher auch auf diesen Hinweis. Außerdem stoppt dieses Beispiel nur die beiden Werkzeuge Edit und Write; Änderungen durch Bash- oder PowerShell-Befehle nehmen andere Wege. Erweitern Sie die Abdeckung je nach gewünschtem Umfang. Ausgabeformate und Ereignisunterschiede erklärt der offizielle Hooks-Leitfaden.

Bedenken Sie den Aufwand vorab: Command-Hooks führen Shell-Befehle automatisch mit Ihren Benutzerrechten aus und können jede Datei ändern oder löschen, auf die Ihr Konto Zugriff hat. Auch die offizielle Dokumentation verlangt, alle Befehle vor dem Hinzufügen zu lesen und zu testen. Konfigurieren Sie nur vertrauenswürdige Befehle und validieren Sie Eingaben. Direkt in Konfigurationsdateien vorgenommene Änderungen werden normalerweise automatisch übernommen. Sehen Sie die Registrierung über /hooks nach. Wirkt eine Änderung nicht, kontrollieren Sie JSON und Ablageort, bevor Sie die Sitzung neu starten.

subagents – den Kontext trennen und abgeben

Vollständige Testausgaben und riesige Logs können den Kontext mit Textmengen füllen, die Sie nur überfliegen wollten, und wichtige Voraussetzungen verdrängen. Subagenten erledigen diese Arbeit in einem eigenen Kontext und liefern eine Zusammenfassung zurück. Normalerweise besitzen sie eigenen Kontext, eigene Anweisungen und Werkzeugrechte; der Hauptagent muss benötigte Informationen ausdrücklich weitergeben. Eine Ausführung, die das Gespräch abzweigt und den Verlauf des Hauptagenten übernimmt, ist eine Ausnahme. Das unterscheidet sich vom context: fork eines Skills. Da der Bericht eine Zusammenfassung ist, verlangen Sie auch notwendige Belege und offene Fragen.

  • 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 eine automatische Auswahl unwahrscheinlicher. 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.

Das Kernprinzip ist die stufenweise Offenlegung. Normalerweise gelangt eine Liste aus Skill-Namen und Beschreibungen in den Kontext. Der Haupttext wird durch automatische Auswahl oder einen ausdrücklichen Aufruf mit /skill-name geladen; Zusatzmaterialien werden bei Bedarf gelesen. Auch die Beschreibungsliste verbraucht Kontext. Bei vielen Skills können Beschreibungen zum Einhalten des Budgets gekürzt oder ausgelassen werden. Formulieren Sie die description konkret und prüfen Sie getrennt, ob der Skill aufgerufen wurde und ob sein Ablauf die erwarteten Ergebnisse lieferte. Die Erstellung behandelt Was Claude Agent Skills sind.

In einem Satz: CLAUDE.md = regelmäßig geladene Voraussetzungen; Skills = automatisch oder ausdrücklich aufgerufene Abläufe; Command-Hooks = Verarbeitung bei konfigurierten Ereignissen und Bedingungen.

MCP – nach draußen zu anderen Systemen greifen

MCP (Model Context Protocol) ist ein Standard für den Zugriff auf externe Daten und Operationen, etwa aktuelle Datenbankwerte oder Tickets. Zwei verbreitete Verbindungsarten folgen. Ermitteln Sie Ursachen, indem Sie Verbindungsart und Fehlerdetails gemeinsam betrachten.

  • Lokal (stdio) — der Server startet als Unterprozess auf Ihrem Rechner. Anhaltspunkte sind Programmpfad, benötigte Umgebungsvariablen und Fehlerausgabe des Servers
  • Entfernt (HTTP) — die Verbindung erfolgt über eine URL. Anhaltspunkte sind URL, Netzwerk, serverseitige Fehler und Zugangsdaten

Beginnen Sie mit Status und Details in /mcp. failed tritt bei lokalen wie entfernten Servern auf. Enthält Issue: in claude mcp get <name> einen HTTP-Code oder Fehlertext, lesen Sie auch diesen. needs authentication verweist auf die Authentifizierung, pending approval auf die Überprüfung der Freigabe eines Projektservers. Wird ein fester Authorization-Header beim Verbindungsaufbau mit 401/403 abgelehnt, lautet der Status ebenfalls failed, obwohl die Authentifizierung die Ursache ist. Lösungen finden Sie unter MCP-Verbindungsfehler in Claude Code beheben.

Die geteilte Konfiguration .mcp.json gehört in den Projektstamm. Variablen für stdio-Server setzen Sie im jeweiligen env; zur HTTP-Authentifizierung dienen je nach Dienst OAuth oder headers. Schreiben Sie echte Schlüssel nicht direkt in geteilte Dateien, sondern verweisen Sie etwa mit ${API_KEY} auf eine Umgebungsvariable. Einige Variablennamen, darunter Claude Codes eigene Zugangsdaten, ergeben in entfernten URLs und Headern leere Zeichenfolgen. Einzelheiten stehen in den offiziellen Expansionsregeln.

Werkzeugdefinitionen werden standardmäßig bei Bedarf geladen. Bei gewöhnlicher Konfiguration mit aktivierter Werkzeugsuche gelangen zunächst nur Werkzeugnamen und Serverbeschreibungen in den Kontext. Definitionen werden vorab geladen, etwa bei deaktivierter Suche, nicht unterstützten Umgebungen oder mit alwaysLoad konfigurierten Servern. Auch Ausgaben verbrauchen Kontext. Prüfen Sie den tatsächlichen Verbrauch mit /context und deaktivieren Sie ungenutzte Server.

plugins – ein Paket schnüren und weitergeben

Plugins ermöglichen es, Skills, Subagent-Definitionen, Hooks und MCP-Konfigurationen gemeinsam zu verteilen. Ein Manifest für ein einzelnes Plugin liegt unter .claude-plugin/plugin.json. In der Standardstruktur liegen skills/, agents/, hooks/hooks.json und .mcp.json im Stammverzeichnis des Plugins selbst. Legen Sie diese nicht unter .claude-plugin/ ab. Bei ausschließlich standardmäßiger Struktur kann das Manifest entfallen.

/plugin marketplace add owner/repo ← Katalog registrieren /plugin install name@marketplace ← einzelne Plugins daraus installieren /plugin list ← über Marketplaces installierte Plugins anzeigen

Dies sind die grundlegenden Schritte für die Installation über einen Marketplace. Die Registrierung eines Katalogs allein installiert keine Plugins. /plugin list zeigt über diesen Weg installierte Plugins, nicht sämtliche über Skills-Verzeichnisse oder Synchronisierung verfügbaren Plugins. Die Bereiche sind user (alle eigenen Projekte), project (geteilte Konfiguration) und local (nur für Sie in diesem Projekt). Auch bei project muss jedes Teammitglied Plugins aus externen Quellen installieren. Managed wird zentral verwaltet und schränkt Konfigurationsänderungen durch Nutzer ein. Die eigene Entwicklung erklärt Claude-Code-Plugins und Marketplace: nutzen, erstellen, veröffentlichen.

Plugins können beliebigen Code mit Ihren Rechten ausführen, warnt die offizielle Dokumentation. Community-Einträge durchlaufen Anthropics automatische Validierung und Sicherheitsprüfung, doch das garantiert kein bestimmungsgemäßes Verhalten. Prüfen Sie Herausgeber, enthaltenen Code und MCP-Server. Das Berechtigungsdesign aus Kapitel 5 betrifft hier auch fremden Code.

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
  • Aufgeschriebene Regeln werden übergangen → Laden, Geltungsbereich und Widersprüche prüfen. Maschinell prüfbare Bedingungen in Hooks überführen
  • 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
  • CLAUDE.md hält dauerhafte Anweisungen fest. Die Datei im Projektstamm wird nach der Verdichtung erneut eingefügt. Kürzen garantiert keine Einhaltung; prüfen Sie Laden und Verhalten getrennt
  • Command-Hooks werden von Claude Code ausgeführt, wenn konfigurierte Bedingungen passen. Prüfen Sie Ausführungswege und Blockierverhalten; ein nachträglicher Hook macht abgeschlossene Vorgänge nicht rückgängig
  • 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 nutzen stufenweise Offenlegung und laden ihre Haupttexte bei Bedarf. Konkrete Beschreibungen helfen bei der automatischen Auswahl; kontrollieren Sie auch nach ausdrücklichem Aufruf die Ergebnisse des Ablaufs
  • MCP ist ein Standard für externen Zugriff. Ermitteln Sie Ursachen anhand des Status in /mcp zusammen mit Verbindungsart und Fehlerdetails
  • 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

Der Vergleich der Werkzeuge selbst und die Wahl zwischen ihnen steht in Kapitel 6 „Fähigkeiten mit Erweiterungen ausbauen“ des Kurses zum KI-Coding.

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“.