Claude · Power Features: Skills, Subagents, Hooks und Settings

Ob Sie Claude Code als Chatfenster in Ihrem Terminal nutzen oder als konfigurierte Engineering-Umgebung betreiben, hängt an einer Handvoll Features: Skills und Slash Commands, Subagents für parallele Arbeit, Hooks, die bei Events Ihre Skripte auslösen, MCPMCPEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen →-Server, die in Ihr Projekt eingebunden sind, und die settings.json, die all das steuert. Diese Lektion geht auf jedes davon im Detail ein.

Skills und Slash Commands

Sie wissen bereits, dass Claude Code eingebaute Slash Commands wie /clear und /init mitbringt. Der eigentliche Hebel ist, eigene zu schreiben, und das heißt heute: einen Skill schreiben.

Ein Skill ist ein Ordner mit einer SKILL.md-Datei sowie allen Skripten, Templates oder Referenzdokumenten, die die Aufgabe braucht. Legen Sie ihn unter .claude/skills/<name>/SKILL.md in Ihrem Repo ab, funktioniert ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → in diesem Projekt. Legen Sie ihn in ~/.claude/skills/ ab, funktioniert er überall. Jeder Skill lässt sich auf zwei Arten nutzen. Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen /<name> eingeben und ihn selbst ausführen, oder Claude lädt ihn von sich aus, wenn die Aufgabe zur Beschreibung des Skills passt.

Hier ein review-Skill, der dem Team einen einheitlichen Code-Review-Durchlauf gibt:

---
name: review
description: Review staged changes for bugs, security issues, and style
allowed-tools: Bash(git diff:*), Read
---

Review the staged diff below. Flag:
1. Logic bugs and edge cases
2. Security issues (injection, secrets, auth gaps)
3. Style deviations from CLAUDE.md

Be terse. Cite file:line. Skip praise.

Staged changes:
!`git diff --cached`

Zwei Dinge fallen auf. Das Präfix ! führt einen Shell-Befehl aus und fügt dessen Ausgabe in den Prompt ein. Das Frontmatter allowed-tools begrenzt, worauf der Skill zugreifen darf, sodass /review nicht abschweifen und Dateien bearbeiten kann. Argumente können Sie außerdem mit $ARGUMENTS übergeben.

Soll ein Skill nur laufen, wenn Sie ihn ausdrücklich aufrufen (etwa ein Deploy), setzen Sie disable-model-invocation: true im Frontmatter, damit Claude ihn nie selbst auslöst.

Das ältere Format funktioniert weiterhin. Eine einzelne Markdown-Datei unter .claude/commands/<name>.md wird zu /<name>, praktisch für einen schnellen Einmal-Prompt. Greifen Sie zum Ordnerformat, wenn die Fähigkeit mitgelieferte Dateien braucht: „Füll unser Rechnungs-Template aus“ oder „Erstelle aus diesen Daten ein PDF“ mit einem Hilfsskript daneben. Dasselbe Skills-Format funktioniert in Claude Code, den Claude-Apps und der APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →, ein einmal gebauter Skill geht also mit Ihnen mit. Siehe code.claude.com/docs/en/skills.

Subagents für parallele Arbeit

Ein Subagent ist eine separate Claude-Instanz mit eigenem Kontextfenster, eigenem System-Prompt und eigenem eingeschränktem Tool-Set, die Ihre Hauptsession startet, um eine klar umrissene Aufgabe zu erledigen. Es geht um Isolation. Der Subagent arbeitet sich durch eine laute Aufgabe (40 Dateien lesen, eine Test-Suite laufen lassen) und liefert nur das Ergebnis zurück, so bleibt Ihr Hauptkontext sauber.

Subagents definieren Sie mit Markdown-Dateien in .claude/agents/ oder interaktiv mit /agents. Jeder deklariert einen Namen, eine Beschreibung, die Claude sagt, *wann* an ihn delegiert werden soll, und die Tools, die er nutzen darf.

---
name: test-runner
description: Runs the test suite and diagnoses failures. Use after code changes.
tools: Bash, Read, Grep
---

You are a test specialist. Run the project's test command, read failing
output, locate the root cause, and report a concise fix. Do not edit
files unless explicitly asked.

Jetzt kann Ihre Hauptsession abgeben: „Prüf das mit dem test-runner.“ Claude liest die Beschreibung, ordnet die Aufgabe zu und delegiert. Weil der Subagent ein eigenes Fenster hat, verschmutzen tausend Zeilen Stack Traces nie Ihre Hauptkonversation.

Der eigentliche Gewinn ist Parallelität. Sie können Claude bitten, Arbeit auf mehrere Subagents gleichzeitig zu verteilen: einer prüft Dependencies, einer schreibt Doku, einer refaktoriert ein Modul. Sie laufen unabhängig und berichten zurück. Das ist dasselbe Delegationsmuster, das das Claude Agent SDK programmatisch bereitstellt, nur aus dem Terminal gesteuert. Halten Sie die Tool-Freigaben pro Subagent knapp. Ein Doku-Schreiber hat mit Bash nichts zu tun.

Hooks, die bei Events Ihre Skripte ausführen

Skills und Subagents rufen Sie auf. Hooks sind das Gegenteil: Shell-Befehle, die Claude Code an definierten Punkten seines Lebenszyklus *automatisch* ausführt, ohne Prompt. Mit ihnen setzen Sie Regeln durch, statt zu hoffen, dass Claude sie befolgt.

Die wichtigsten Lifecycle-Events:

• PreToolUse: bevor ein Tool läuft (Sie können es blockieren)
• PostToolUse: nachdem ein Tool erfolgreich war
• UserPromptSubmit: wenn Sie Enter drücken
• Stop: wenn Claude mit der Antwort fertig ist
• SessionStart: wenn eine Session startet

Jeder Hook erhält über stdin ein JSON-Payload, das das Event beschreibt: Tool-Name, Input, Session-ID und so weiter. Der klassische Anwendungsfall ist das automatische Formatieren jeder Datei, die Claude bearbeitet. Fügen Sie Folgendes in Ihre settings.json ein:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs prettier --write 2>/dev/null"
          }
        ]
      }
    ]
  }
}

Nachdem Claude eine Datei bearbeitet oder geschrieben hat, zieht jq den Pfad aus dem Payload, und Prettier formatiert diese Datei. Claude muss sich Ihre Style-Regeln nie merken, weil der Hook sie unverhandelbar macht. Der matcher ist ein Regex, der gegen Tool-Namen geprüft wird.

PreToolUse geht weiter, weil er blockieren kann. Beenden Sie mit Exit-Code 2, bricht Claude Code den Tool-Aufruf ab und zeigt Claude Ihre stderr-Meldung, damit es sich anpassen kann. Andere Exit-Codes ungleich null gelten als nicht blockierende Fehler, und das Tool läuft trotzdem. Eine Schutzregel muss also genau 2 verwenden. Für feinere Kontrolle kann ein Hook JSON mit einer Permission-Entscheidung allow, deny oder ask ausgeben. Teams nutzen das, um Änderungen an secrets/ zu verbieten, git push --force zu blockieren oder vor einem Commit einen erfolgreichen Lint vorauszusetzen. Der Hook läuft deterministisch, außerhalb des Urteils des Modells.

Ein Warnhinweis: Hooks führen echte Shell-Befehle mit Ihren Berechtigungen aus. Lesen Sie, was Sie einfügen. Ein Hook aus einem nicht vertrauenswürdigen Repo kann alles, was Sie auch können. Die vollständige Event-Referenz und die Payload-Schemas finden Sie unter code.claude.com/docs/en/hooks.

MCP-Server in Claude Code

Das Model Context Protocol kennen Sie bereits als Konzept: ein Standard, um Tools und Daten für jeden KI-Client bereitzustellen. Claude Code ist ein MCP-Client, Sie können also dieselben Server, die Sie in der Claude-Desktop-App nutzen würden, direkt in Ihre Terminal-Sessions einbinden.

Fügen Sie einen über die CLI hinzu. GitHub betreibt einen offiziellen Remote-Server:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Führen Sie in einer Session /mcp aus, um sich zu authentifizieren. Nach der Verbindung kann Claude Issues anlegen, PRs lesen und Repos als native Tools untersuchen, ganz ohne Glue Code. Lokale Server, die als Prozess auf Ihrem Rechner laufen, nutzen die ---Form, zum Beispiel claude mcp add myserver -- npx -y some-mcp-package. Server lassen sich auf ein einzelnes Projekt beschränken oder global verfügbar machen. Projektbezogene Server stehen in einer .mcp.json-Datei, die ins Repo eingecheckt wird, so bekommt Ihr ganzes Team dieselben Integrationen.

MCP verbindet Claude Code mit dem größeren Ökosystem. Die Connectors, die Sie in den Claude-Apps sehen, sind unter der Haube MCP, und die Protokollspezifikation ist unter modelcontextprotocol.io dokumentiert. Bauen Sie einen Server einmal, und er funktioniert in Claude Code, in der Desktop-App und in allem anderen, das MCP spricht.

settings.json: die Steuerzentrale

Alles oben Genannte wird über Settings-Dateien konfiguriert, und wer ihre Schichtung versteht, hat ein aufgeräumtes Setup statt eines verwirrenden. Claude Code liest Settings aus mehreren Orten, und der spezifischste gewinnt:

• ~/.claude/settings.json: Ihre persönlichen Defaults, für alle Projekte
• .claude/settings.json: Projekt-Settings, in git eingecheckt, mit dem Team geteilt
• .claude/settings.local.json: Ihre persönlichen Projekt-Overrides, von git ignoriert

Legen Sie teamweite GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen → (den Format-Hook, die Permission-Regeln) in die geteilte .claude/settings.json, damit alle sie erben. Persönliche Präferenzen und maschinenspezifische Pfade gehören in settings.local.json, damit Sie sich in der Versionskontrolle nicht mit Ihren Kollegen streiten. Organisationen können zudem verwaltete Settings ausrollen, die alle drei überschreiben.

Der wichtigste Key ist permissions. Er steuert, was Claude tun darf, ohne anzuhalten und nachzufragen. Sie erlauben Tool-Muster, lassen nachfragen oder verbieten sie:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Read",
      "Edit"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

So darf Claude Ihre Test-Skripte ausführen und Dateien frei bearbeiten, liest aber nie Ihre `.env` oder Secrets und verweigert gefährliche Löschvorgänge. Stellen Sie das einmal ein, und Sie müssen Bestätigungsabfragen für sichere Operationen nicht mehr babysitten, während um die gefährlichen eine harte Mauer steht. Betrachten Sie Bash-Deny-Muster als Komfortfunktion, denn ein entschlossener Befehl lässt sich auf viele Arten formulieren. Für harte Garantien sichern Sie sie mit einem PreToolUse-Hook ab.

Weitere Keys, die Sie kennen sollten: env injiziert Umgebungsvariablen in jede Session, model legt fest, welches Claude-Modell das Projekt nutzt, und hooks (siehe oben) liegt ebenfalls hier. Halten Sie die geteilte Datei schlank und bewusst, denn jeder, der das Repo klont, erbt sie. Das vollständige SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → finden Sie unter code.claude.com/docs/en/settings.

Wie die Teile zusammenspielen

Diese Features bauen aufeinander auf. Ein echtes Setup sieht so aus:

Ein SessionStart-Hook lädt die Projektkonventionen. Ihr permissions-Block gibt den Test-Befehl frei und schottet Secrets ab. Ein /review-Skill führt auf Abruf Ihr standardisiertes Code Review aus. Ein test-runner-Subagent übernimmt die laute Arbeit, die Suite laufen zu lassen und Fehler zu diagnostizieren. Ein PostToolUse-Hook formatiert jede Datei, die Claude anfasst. Ein GitHub-MCP-Server lässt Claude den PR öffnen, wenn Sie fertig sind. All das liegt in Dateien im Repo, ein neuer Kollege klont es also und bekommt am ersten Tag genau denselben konfigurierten Claude.

Um diese Reproduzierbarkeit geht es. Sie liefern neben Ihrem Code eine konfigurierte Engineering-Umgebung aus.

Das Wichtigste in Kürze

• Skills sind der wichtigste Weg, Claude Code zu erweitern. Ein Ordner unter .claude/skills/<name>/ gibt Ihnen einen /<name>-Befehl, den Claude auch von sich aus aufrufen kann. Einzeldatei-Prompts in .claude/commands/ funktionieren für schnelle Fälle weiterhin.
• Nutzen Sie Subagents, um Ihren Hauptkontext zu schützen. Delegieren Sie laute, klar umrissene Aufgaben an isolierte Agents mit knappen Tool-Freigaben, und verteilen Sie unabhängige Arbeit parallel auf mehrere.
• Hooks machen Regeln deterministisch. Sie lesen Event-JSON aus stdin, und ein PreToolUse-Hook blockiert nur mit Exit-Code 2. Sie führen echte Shell-Befehle mit Ihren Berechtigungen aus, prüfen Sie also alles, was Sie nicht selbst geschrieben haben.
• Behandeln Sie MCP als Ihre Integrationsschicht. claude mcp add bindet dieselben Server, die im gesamten Anthropic-Ökosystem genutzt werden, in Ihr Terminal ein, und .mcp.json teilt sie mit dem Team.
• Committen Sie Ihre settings.json und planen Sie die Schichtung: geteilte Guardrails in der Team-Datei, persönliche Overrides in settings.local.json.