Claude Code: Skills, Subagents und Hooks

Wer Claude Code einrichten will und dabei über die ersten Tage hinausdenkt, stößt schnell auf eine verwirrende Werkzeugkiste: CLAUDE.md, Skills, Subagents, Hooks, MCP-Server, dazu noch vier verschiedene Settings-Ebenen. Die Dokumentation beschreibt jedes Element für sich sauber - die eigentliche Frage bleibt aber meistens offen: Wann nimmt man was? Und warum hält sich Claude an die eine Regel zuverlässig, an die andere aber nur „meistens”?

Genau diese Unterscheidung ist der rote Faden dieses Artikels. Anthropic selbst zieht sie explizit: Eine Anweisung in CLAUDE.md oder einem Skill ist „a request, not a guarantee” - eine Bitte, keine Garantie. Verbindlich wird etwas erst über Hooks oder über zentral verwaltete Settings. Wer diesen Unterschied verinnerlicht hat, kann seinen Claude-Code-Harness gezielt aufbauen - und beantwortet die eigentliche Frage, ob eine Aufgabe zu Skills, Subagents oder Hooks gehört, in Zukunft in Sekunden statt in Versuchsreihen.

Dieser Artikel ist der Einstiegs-Pillar für das Thema Claude Code im professionellen Einsatz. Er ordnet die Bausteine ein, zeigt, wie sie ineinandergreifen, und liefert eine Entscheidungslogik, mit der Sie für die nächste Automatisierungsidee schnell wissen, wo sie hingehört. Für die zentrale Verteilung dieser Konfiguration im Unternehmen - etwa per Intune - folgt ein eigener, vertiefender Artikel. Alle technischen Angaben in diesem Artikel beziehen sich auf den Dokumentationsstand August 2026; Claude Code erscheint mehrmals pro Woche, prüfen Sie Details im Zweifel gegen die offizielle Dokumentation.

Was ein Harness bei Claude Code ist

Im Sprachgebrauch rund um KI-Coding-Agenten meint „Harness” das Gerüst, das um ein Sprachmodell herum gebaut wird, damit aus einem Chatfenster ein Werkzeug wird, mit dem man tatsächlich arbeiten kann: Kontext, der bei jeder Anfrage mitgeliefert wird, Fähigkeiten, die bei Bedarf nachgeladen werden, Isolationsräume für Nebenaufgaben, und Leitplanken, die bestimmte Aktionen erlauben, verweigern oder erst nach Rückfrage zulassen.

Claude Code bildet dieses Gerüst über fünf Bausteine ab, die sich in genau dieser Reihenfolge sinnvoll erklären lassen:

CLAUDE.md liefert Kontext - Informationen, die Claude bei jeder Session automatisch kennt.
Skills liefern Fähigkeiten - Wissen und Workflows, die erst bei Bedarf geladen werden.
Subagents liefern Isolation - eigene Kontextfenster für Aufgaben, die den Hauptverlauf nicht fluten sollen.
Hooks liefern Durchsetzung - deterministisches Verhalten, das garantiert bei einem bestimmten Ereignis feuert.
MCP-Server liefern Anbindung - Werkzeuge und Datenzugriff aus der Welt außerhalb von Claude Code.

Darüber liegt die Konfigurations-Hierarchie: die Ebene, die festlegt, wessen Regeln am Ende gelten, wenn Projekt-Team, einzelne Entwickler und IT-Abteilung gleichzeitig etwas einstellen. Diese Hierarchie ist das Fundament, auf dem alles andere aufsetzt - deshalb zuerst dazu ein kompakter Überblick, bevor es an die einzelnen Bausteine geht.

Die Konfigurations-Hierarchie von Claude Code

Claude Code kennt vier Settings-Scopes:

Scope	Ort	Geteilt
Managed	serverseitig oder Datei/Registry am System, z. B. `managed-settings.json`	organisationsweit, von der IT vorgegeben
User	`~/.claude/settings.json`	nur die eigenen Projekte
Project	`.claude/settings.json`	über Git im Team geteilt
Local	`.claude/settings.local.json`	nicht geteilt, gitignored

Die Präzedenz bei einer Kollision läuft in dieser Reihenfolge, höchste Priorität zuerst: Managed, dann Command-Line-Argumente, dann Local, dann Project, dann User. Managed Settings lassen sich von keiner anderen Ebene überschreiben - mit wenigen, dokumentierten Ausnahmen.

Eine Besonderheit betrifft Permission-Regeln: Sie werden nicht einfach nach Präzedenz ersetzt, sondern über alle Scopes hinweg gemergt. Ein deny auf irgendeiner Ebene blockiert eine Aktion, selbst wenn eine höhere Ebene sie erlaubt hätte. Für Teams heißt das praktisch: Ein Sicherheitsteam kann projektübergreifend einzelne gefährliche Befehle sperren, ohne dass ein einzelnes Projekt-Setting das versehentlich wieder aufhebt.

Für dieses Fundament reicht an dieser Stelle der Überblick - wie sich Managed Settings über Server, Konfigurationsprofile, Registry-Werte oder Dateien tatsächlich im Unternehmen ausrollen lassen (und wo dabei die Stolperfallen liegen), ist Thema des vertiefenden Artikels zur zentralen Verteilung. Für den Rest dieses Artikels reicht die Grundregel: Was in Managed Settings steht, gewinnt. Alles darunter ist Verhandlungsmasse zwischen Team und einzelnem Entwickler.

CLAUDE.md: Kontext, kein Vertrag

CLAUDE.md ist der naheliegendste Einstiegspunkt, wenn Sie Claude Code einrichten - und gleichzeitig der Baustein, bei dem die meisten Missverständnisse entstehen. Die Grundregeln guter Prompt-Formulierung gelten dabei genauso wie im Chat: klar, konkret, ohne Widersprüche - Details dazu haben wir in unserem Grundlagenartikel zu Prompt Engineering eingeordnet.

Wo CLAUDE.md liegen kann:

Ebene	Ort
Managed Policy	am Managed-Settings-Pfad des Systems
User	`~/.claude/CLAUDE.md`
Project	`./CLAUDE.md` oder `./.claude/CLAUDE.md`
Local	`./CLAUDE.local.md` (gitignoren)

Claude Code läuft beim Start vom aktuellen Arbeitsverzeichnis den Verzeichnisbaum nach oben und lädt alle gefundenen CLAUDE.md- und CLAUDE.local.md-Dateien vollständig. Wichtig: Die Inhalte werden konkateniert, nicht überschrieben - es gilt additiv von der Wurzel abwärts, wobei die Datei im aktuellen Arbeitsverzeichnis zuletzt gelesen wird. CLAUDE.md-Dateien in Unterverzeichnissen laden erst on demand, sobald Claude dort tatsächlich Dateien liest. Wer nicht möchte, dass eine fremde CLAUDE.md mitgeladen wird, kann sie über claudeMdExcludes ausschließen - außer es handelt sich um eine Managed-Policy-CLAUDE.md, die lässt sich nicht ausschließen.

Für sehr modulare Regelwerke gibt es zusätzlich .claude/rules/*.md: Ohne paths-Frontmatter laden diese Dateien beim Start mit derselben Priorität wie die Projekt-CLAUDE.md; mit paths:-Frontmatter (Glob-Muster) laden sie nur, wenn Claude passende Dateien liest. Und für Teams, die bereits mit AGENTS.md für andere Coding-Agenten arbeiten: Claude Code liest diese Datei nicht direkt. Der empfohlene Weg ist, eine CLAUDE.md anzulegen, deren erste Zeile per Import-Syntax (@AGENTS.md) darauf verweist, und darunter Claude-spezifische Ergänzungen zu ergänzen.

Anthropics eigene Best Practices für den Inhalt sind konkret:

Zielgröße unter 200 Zeilen pro Datei. Längere Dateien kosten Kontext und senken die Befolgungsrate.
Testfrage pro Zeile: Würde das Entfernen dieser Zeile dazu führen, dass Claude Fehler macht? Wenn nein, streichen. Anthropic formuliert es pointiert: „Bloated CLAUDE.md files cause Claude to ignore your actual instructions!”
Konkret formulieren statt vage - „2-Space-Einrückung verwenden” statt „Code ordentlich formatieren”.
Widersprüchliche Regeln vermeiden; bei Konflikten wählt Claude im Zweifel willkürlich.
Emphase wie „IMPORTANT” oder „YOU MUST” kann die Befolgung verbessern.
CLAUDE.md gehört ins Git-Repository und wird wie Code behandelt: reviewen, kürzen, Wirkung beobachten.

Rein sollten nicht erratbare Bash-Befehle, vom Standard abweichende Style-Regeln, Test-Instruktionen, Repo-Etikette, projektspezifische Architekturentscheidungen und bekannte Stolperfallen. Raus sollte alles, was Claude aus dem Code selbst ableiten kann, Standard-Sprachkonventionen, ausführliche API-Dokumentation und alles, was sich häufig ändert.

Und hier kommt der zentrale Punkt, der diesen Artikel durchzieht: CLAUDE.md wird technisch als User-Nachricht nach dem eigentlichen System-Prompt ausgeliefert, nicht als dessen Teil. Anthropic sagt es unumwunden: „there’s no guarantee of strict compliance”. Wer eine Regel wirklich erzwingen will - etwa „niemals .env bearbeiten” - braucht dafür keinen dringlicheren Ton in CLAUDE.md, sondern einen Hook. Dazu später mehr.

Ergänzend läuft im Hintergrund noch ein zweites, komplementäres Gedächtnis: Auto Memory. Claude schreibt hier standardmäßig selbst Notizen, gespeichert unter ~/.claude/projects/<project>/memory/ mit einer MEMORY.md als Index. Anders als CLAUDE.md ist das maschinenlokal und nicht geräteübergreifend geteilt - für Team-Wissen bleibt CLAUDE.md der richtige Ort.

Aus unseren Projekten: In einem Projekt war die CLAUDE.md historisch gewachsen und enthielt Anweisungen, die sich gegenseitig widersprachen. Sie lief bei jeder Anfrage vollständig mit und verbrauchte entsprechend Kontext, ohne die Arbeit besser zu machen. Wir haben sie auf das Nötige zusammengestrichen - und prüfen gewachsene CLAUDE.md-Dateien seitdem regelmäßig, statt nur weiter anzubauen.

Claude Code Skills: Wissen, das nur bei Bedarf lädt

Ein Skill ist Referenzmaterial oder ein Workflow, der nicht bei jeder Session mitgeladen wird, sondern erst, wenn er gebraucht wird. Genau das unterscheidet ihn von CLAUDE.md: CLAUDE.md sagt „tu das immer”, ein Skill sagt „hier ist, wie man das gut macht, wenn es gebraucht wird”.

Claude-Code-Skills folgen dem offenen Agent-Skills-Standard, der über mehrere KI-Tools hinweg funktioniert - Claude Code erweitert diesen Standard um zusätzliche Features wie Invocation Control und Subagent-Ausführung.

Skills können auf mehreren Ebenen liegen:

Ebene	Pfad
Enterprise	über Managed Settings
Personal	`~/.claude/skills/<skill-name>/SKILL.md`
Project	`.claude/skills/<skill-name>/SKILL.md`
Plugin	`<plugin>/skills/<skill-name>/SKILL.md`

Bei Namenskonflikten gewinnt Enterprise vor Personal vor Project. Der /-Befehl, mit dem man einen Skill manuell aufruft, ergibt sich bei Personal- und Project-Skills aus dem Verzeichnisnamen - das Frontmatter-Feld name ist dort nur ein Anzeigelabel. Bei Plugin-Skills bestimmt name dagegen das letzte Segment des Befehls.

Ein minimales SKILL.md sieht so aus:

---
name: <skill-name>
description: <wann und wofür — der wichtigste Satz zuerst>
allowed-tools: <optionale Tool-Allowlist>
disable-model-invocation: false
---

# <Skill-Titel>

<Anleitung, Playbook oder Referenzwissen, das Claude
lädt, sobald der Skill gezogen wird.>

Das Frontmatter kennt eine ganze Reihe weiterer, alle optionaler Felder - unter anderem when_to_use, argument-hint, arguments, user-invocable, model, effort, context (für isolierte Ausführung als Subagent-Fork), paths und hooks. Zwei Details lohnen sich für die Praxis besonders:

Erstens: description und when_to_use werden im Skill-Listing bei 1.536 Zeichen abgeschnitten - der wichtigste Anwendungsfall gehört an den Anfang. Zweitens: disable-model-invocation: true sorgt dafür, dass ein Skill ausschließlich manuell per /-Befehl aufrufbar ist und bis dahin keinerlei Kontext kostet. Anthropic empfiehlt das ausdrücklich für Skills mit Seiteneffekten - also für alles, was tatsächlich etwas verändert, statt nur zu recherchieren.

Wichtig für die Kontextkosten-Rechnung: Beim Session-Start lädt nur die Beschreibung jedes Skills, der volle Inhalt erst bei tatsächlicher Nutzung. Das macht Skills deutlich günstiger als eine überladene CLAUDE.md, die bei jeder einzelnen Anfrage komplett mitgeschickt wird.

Ein Skill ist das richtige Werkzeug, wenn Sie merken, dass Sie dasselbe Playbook zum wiederholten Mal in den Chat kopieren, oder wenn Sie denselben Prompt immer wieder abtippen. Für einmalige Konventionen, die Claude einfach immer kennen soll, bleibt CLAUDE.md die bessere Wahl.

Claude Code Subagents: eigener Kontext für Nebenaufgaben

Ein Subagent ist ein isolierter Worker mit eigenem Kontextfenster, der eine abgeschlossene Aufgabe erledigt und ein Ergebnis an die Hauptkonversation zurückmeldet. Definiert werden Subagents in Markdown-Dateien unter .claude/agents/*.md, mit ähnlicher Ebenen-Logik wie bei Skills:

Ort	Scope	Priorität
Managed Settings	organisationsweit	höchste
CLI-Flag `--agents`	Session	2
`.claude/agents/`	Projekt	3
`~/.claude/agents/`	alle eigenen Projekte	4
Plugin-`agents/`	wo das Plugin aktiv ist	niedrigste

Bei gleichem Namen gewinnt bei Projekt-Subagents die Definition, die dem Arbeitsverzeichnis am nächsten liegt.

Das Frontmatter braucht mindestens name und description; optional lassen sich tools als Allowlist, disallowedTools, model (ein Modell-Alias, eine vollständige Modell-ID oder inherit), permissionMode, maxTurns, vorzuladende skills, mcpServers, memory, eine eigene isolation: worktree und ein effort-Level setzen:

---
name: <agent-name>
description: <wann dieser Subagent gezogen werden soll>
tools: <optionale Tool-Allowlist>
model: sonnet
---

<System-Prompt / Aufgabenbeschreibung für den Subagent>

Beim Start bekommt ein Subagent einen frischen, isolierten Kontext: einen eigenen System-Prompt (nicht den vollen Claude-Code-System-Prompt der Hauptsession), den vollständigen Inhalt der im Frontmatter gelisteten Skills, sowie CLAUDE.md und Git-Status - plus den Prompt, den der Lead-Agent ihm mitgibt. Die Auto-Memory der Hauptkonversation wird dabei nicht übernommen. Subagents lassen sich bis zu drei Ebenen tief verschachteln und können eigene Hooks besitzen, die nur laufen, solange der Subagent aktiv ist.

Anthropic nennt mehrere Kriterien für den Griff zum Subagent: Die Aufgabe erzeugt viel Output, den man im Hauptkontext nicht braucht; man möchte gezielt Tool-Zugriffe einschränken; die Arbeit ist in sich abgeschlossen und eine Zusammenfassung reicht; oder es geht um parallele Recherche, die den Hauptkontext sonst fluten würde. Umgekehrt bleibt die Hauptkonversation die bessere Wahl, wenn häufiges Hin und Her nötig ist, mehrere Phasen viel Kontext teilen müssen, es um kleine gezielte Änderungen geht oder Latenz zählt.

Ein kurzer Ausblick, der über diesen Artikel hinausgeht: Wenn parallele Subagents an Kontextgrenzen stoßen oder untereinander kommunizieren müssten, bietet Claude Code inzwischen experimentell Agent Teams - mehrere eigenständige Claude-Code-Instanzen, die sich über Nachrichten und eine geteilte Task-Liste selbst koordinieren, statt nur an einen Lead zu melden. Das Feature ist von Anthropic als experimentell eingestuft und standardmäßig deaktiviert; ein eigener Erfahrungsbericht dazu folgt.

Claude Code Hooks: die einzige Ebene, die Regeln erzwingt

Hooks sind der Baustein, der den Unterschied zwischen „Bitte” und „Garantie” tatsächlich auflöst. Ein Hook feuert garantiert bei einem bestimmten Ereignis - unabhängig davon, wie Claude die Situation gerade interpretiert.

Die Liste der Events ist umfangreich und deckt praktisch den gesamten Session-Lebenszyklus ab, unter anderem: SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, Stop, SubagentStart, SubagentStop, PreCompact, PostCompact und SessionEnd. Manche Events feuern einmal pro Session, manche einmal pro Turn, manche bei jedem einzelnen Tool-Aufruf - PreToolUse und PostToolUse etwa laufen bei jedem Tool-Call.

Ein verbreitetes Missverständnis: Hooks sind längst nicht mehr nur Shell-Skripte. Claude Code kennt fünf Handler-Typen:

Typ	Was passiert	Default-Timeout
`command`	Shell-Befehl, JSON auf stdin	600 s
`http`	POST an eine URL	600 s
`mcp_tool`	Tool auf einem verbundenen MCP-Server	600 s
`prompt`	Bewertung durch ein Claude-Modell	30 s
`agent`	Subagent für komplexe Validierung	60 s

Die Konfiguration liegt im hooks-Block der jeweiligen Settings-Datei:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-command.sh",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Der matcher bestimmt, auf welche Tool-Aufrufe der Hook reagiert: leer oder "*" heißt alles, ein einfacher String matcht exakt, | oder , erlauben eine Liste, Sonderzeichen lösen einen unankered Regex aus. Wird args statt einer reinen Command-Line verwendet, spawnt Claude Code den Prozess direkt ohne Shell - ohne Variablen-Expansion, was Anthropic bei Pfad-Platzhaltern ausdrücklich empfiehlt.

Für die Wirkung entscheidend sind die Exit-Codes: 0 bedeutet Erfolg, JSON auf stdout wird als Entscheidung ausgewertet. 2 ist ein Blocking Error - die Aktion wird verhindert, unabhängig vom sonstigen JSON-Inhalt. Bei PreToolUse blockiert das den Tool-Call, bei UserPromptSubmit den Prompt, bei Stop das Beenden der Antwort - Claude arbeitet dann weiter. Eine ganze Reihe von Events kann grundsätzlich nicht blockieren, darunter PostToolUse, PermissionRequest und SessionEnd. HTTP-Hooks nutzen statt Exit-Codes den HTTP-Statuscode plus JSON im Response-Body.

Genau hier liegt der praktische Kern der Guardrail-Logik: Eine Regel wie „niemals .env bearbeiten” in CLAUDE.md oder einem Skill ist eine Bitte - Claude interpretiert sie, und das Ergebnis kann variieren. Ein PreToolUse-Hook, der den entsprechenden Edit-Aufruf mit Exit-Code 2 blockiert, ist dagegen Durchsetzung. Typische Einsatzmuster sind Format-Checks nach jedem Edit (PostToolUse), Guardrails gegen gefährliche Bash-Befehle (PreToolUse) oder Qualitätsschranken, bevor Claude eine Antwort abschließt (Stop). Dieselbe Denkweise - technische Durchsetzung statt Vertrauen auf eine Instruktion - trägt auch jenseits von Claude Code, etwa bei Zero Trust für KI-Agenten generell.

Für den Unternehmenskontext sind Hooks auch die Ebene, über die Admins gezielt eingreifen können: Projekt-Hooks feuern erst nach Bestätigung des Workspace-Trust-Dialogs, allowManagedHooksOnly lässt nur noch zentral verwaltete Hooks laufen, allowedHttpHookUrls schränkt HTTP-Hooks auf eine Allowlist ein, und disableAllHooks schaltet sämtliche Hooks (und die Custom-Statusline) komplett ab.

MCP-Server in Claude Code: Werkzeuge und Daten von außen

Der fünfte Baustein ist die Anbindung an die Außenwelt über das Model Context Protocol (MCP). MCP-Server liefern Tools und Datenzugriff - den Unterschied zu Skills bringt Anthropic auf den Punkt: MCP verbindet, ein Skill dokumentiert, wie man diese Verbindung gut nutzt. Beides ergänzt sich in der Praxis oft im selben Setup: Ein MCP-Server stellt zum Beispiel eine Datenbankverbindung her, ein begleitender Skill dokumentiert Schema und typische Query-Muster dazu.

Auch MCP-Server kennen drei Scopes, die per Namen konkurrieren - bei Namensgleichheit gewinnt Local vor Project vor User, ohne Feld-Merge:

Scope	Lädt in	Team-geteilt	Gespeichert in
Local (Default)	nur aktuelles Projekt	nein	`~/.claude.json`
Project	nur aktuelles Projekt	ja, via Git	`.mcp.json` im Projektroot
User	alle eigenen Projekte	nein	`~/.claude.json`

Angelegt wird ein Server über die CLI, etwa claude mcp add --transport http <name> <url>, optional mit --scope local|project|user.

Kontextkostenmäßig gilt: Beim Session-Start lädt nur die Liste der Tool-Namen, die vollständigen Schemas bleiben deferred bis zur tatsächlichen Nutzung. Trotzdem empfiehlt Anthropic, für rein lokale Aufgaben CLI-Tools wie gh, aws oder gcloud gegenüber einem MCP-Server vorzuziehen, wenn beides möglich ist - CLI-Tools erzeugen gar kein Per-Tool-Listing im Kontext. Und ein Punkt, den dieser Artikel nur anreißen kann, aber ernst nehmen sollte: Wer einem MCP-Server vertraut, vertraut auch dessen Betreiber - Tool-Beschreibungen und Rückgabewerte eines Servers sind letztlich fremder Input, den Claude verarbeitet. Managed Settings können das über allowedMcpServers, deniedMcpServers oder allowManagedMcpServersOnly zentral eingrenzen.

Skills, Subagents oder Hooks: die Entscheidungslogik

Damit lässt sich der rote Faden dieses Artikels zu einer praktischen Faustregel verdichten. Anthropic selbst beschreibt das Setup als etwas, das über Zeit wächst - mit klaren Auslösern dafür, wann welcher Baustein ergänzt wird:

Claude bekommt eine Konvention oder einen Befehl zum zweiten Mal falsch → CLAUDE.md.
Sie tippen denselben Prompt immer wieder → ein user-invocable Skill.
Sie kopieren dasselbe Playbook zum dritten Mal in den Chat → Skill.
Sie kopieren ständig Daten aus einem externen System → MCP-Server.
Eine Nebenaufgabe flutet die Konversation mit Output → Subagent.
Etwas soll jedes Mal passieren, ohne dass Claude gefragt wird → Hook.
Ein zweites Repository braucht exakt dasselbe Setup → Plugin.

Die Bausteine überschreiben sich dabei nicht willkürlich, sondern nach klaren Regeln: CLAUDE.md-Dateien sind additiv, alle geladenen Ebenen tragen gleichzeitig bei. Skills und Subagents überschreiben sich per Namensgleichheit (Skills: Enterprise vor User vor Projekt; Subagents: Managed vor CLI-Flag vor Projekt vor User vor Plugin). MCP-Server überschreiben sich ebenfalls per Name (Local vor Project vor User). Hooks dagegen mergen: Alle registrierten Hooks aus allen Quellen feuern auf ihre jeweiligen Events, unabhängig davon, woher sie stammen.

Und die Kontextkosten unterscheiden sich fundamental - eine Tabelle, die beim Entwurf eines Setups hilft, bevor man sich über eine „langsame” Session wundert:

Baustein	Lädt wann	Kosten
CLAUDE.md	bei jedem Session-Start	voller Inhalt bei jedem Request
Skills	Start + bei Nutzung	Beschreibung beim Start, Inhalt bei Nutzung - niedrig
MCP-Server	Session-Start	nur Tool-Namen, Schemas on demand - niedrig bis zur Nutzung
Subagents	beim Spawn	isolierter, eigener Kontext
Hooks	beim Trigger	praktisch null, außer der Hook liefert selbst Output

Der eigentliche Kernsatz, um den sich alles dreht, stammt aus Anthropics eigener Formulierung: „Put guardrails in hooks.” CLAUDE.md und Skills sind Instruktionen, die Claude interpretiert - sinnvoll für Wissen, Kontext und Konventionen, aber ohne Garantie. Sobald eine Regel tatsächlich verbindlich sein muss, weil sonst ein reales Risiko entsteht - ein produktives .env, ein geschützter Branch, ein Kunden-Tenant - , gehört sie in einen Hook oder in Managed Settings, nicht in eine noch dringlicher formulierte Zeile CLAUDE.md.

Häufige Fragen zu Claude Code

Was gehört in die CLAUDE.md?

Konventionen, Architekturentscheidungen und Gotchas, die für jede Session gelten sollen - nicht spezialisierte Workflows, die nur gelegentlich gebraucht werden (dafür sind Skills da). Halten Sie die Datei kurz: Sie lädt vollständig bei jedem Session-Start, jede zusätzliche Zeile kostet also bei jedem Request Kontext.

Was ist der Unterschied zwischen CLAUDE.md und einem Skill?

CLAUDE.md lädt vollständig bei jeder Session, ein Skill lädt seine Beschreibung beim Start und den vollen Inhalt erst bei Bedarf. CLAUDE.md eignet sich für Regeln, die immer gelten sollen, Skills für Wissen oder Workflows, die nur situativ relevant sind.

Wann Skill und wann Subagent?

Ein Skill liefert Wissen, das Claude in der Hauptkonversation direkt nutzt - Kontext bleibt erhalten. Ein Subagent liefert ein eigenes Kontextfenster für eine Aufgabe, deren Output den Hauptverlauf sonst fluten würde. Wenn beides zutrifft: Der Subagent kann den Skill selbst laden.

Wie erzwinge ich eine Regel in Claude Code zuverlässig?

Über einen Hook, nicht über eine noch eindringlicher formulierte Instruktion. Ein PreToolUse-Hook mit Exit-Code 2 kann eine Aktion garantiert blockieren; eine Anweisung in CLAUDE.md oder einem Skill bleibt eine Interpretation durch das Modell, keine Garantie.

Brauche ich einen MCP-Server oder reicht ein Skill?

Das hängt vom Zugriff ab: Ein MCP-Server bindet externe Werkzeuge und Daten an - etwas, das ein Skill allein nicht kann. Beim Session-Start kosten MCP-Server nur die Namen der verfügbaren Tools, die vollständigen Schemas laden erst bei tatsächlicher Nutzung; für rein lokale Kommandozeilenaufgaben bleibt ein CLI-Tool wie gh trotzdem oft kontexteffizienter.

Wie rolle ich diesen Harness zentral im Unternehmen aus?

Über Managed Settings - serverseitig verwaltet oder als Datei am Systempfad, per MDM verteilt. Diese Ebene kann von keiner darunterliegenden Ebene überschrieben werden - auch nicht per Kommandozeilen-Argument. Dokumentiert sind nur wenige sicherheitsrelevante Ausnahmen, bei denen Claude Code einen strengeren Wert aus einer niedrigeren Ebene übernimmt; Permission-Regeln aus Managed Settings gehören nicht dazu. Die konkreten Verteilwege für Windows und macOS behandelt der Folgeartikel zur zentralen Verteilung.

Fazit

Der Claude-Code-Harness ist kein einzelnes Setting, sondern ein Zusammenspiel aus fünf Bausteinen mit sehr unterschiedlichen Eigenschaften: CLAUDE.md für Kontext, der immer mitläuft, Skills für Wissen, das erst bei Bedarf geladen wird, Subagents für isolierte Nebenaufgaben, Hooks für alles, was wirklich garantiert passieren muss, und MCP für die Anbindung nach außen. Die wichtigste Unterscheidung, die Sie aus diesem Artikel mitnehmen sollten, ist die zwischen Bitte und Garantie: Wer Claude Code produktiv und kontrolliert einsetzen will, baut sein Setup entlang genau dieser Linie auf - und verlässt sich bei allem, was schiefgehen darf, nicht auf eine Instruktion, sondern auf einen Hook.

Quellen (Stand: August 2026):

Der Claude-Code-Harness: CLAUDE.md, Skills, Subagents und Hooks richtig aufsetzen