Ein Claude Code-Plugin wird aus Komponenten erstellt, wie Skills, Agents, Hooks und MCP-Servern. Jede Komponente hat einen Standard-Ordner im Plugin, einen optionalen Manifest-Schlüssel in .claude-plugin/plugin.json, der diesen Ordner ersetzt oder ergänzt, und einen Namen, den der Benutzer sieht. Für jede Schlüssels vollständige Feldtabelle siehe die Manifest-Referenz.
Verwenden Sie diese Seite, um eine Komponente zu einem Plugin hinzuzufügen, das bereits geladen wird.
Nachdem Sie eine Komponente hinzugefügt haben, führen Sie /reload-plugins in einer laufenden Sitzung aus oder starten Sie eine neue, damit Claude Code sie lädt. Um die Datei der Komponente vor dem Laden zu überprüfen, führen Sie claude plugin validate . in Ihrer Shell aus dem Plugin-Verzeichnis aus.
Plugin-Verzeichnis erkunden
Der Explorer zeigt ein Beispiel-Plugin, my-plugin, das an seinem Standard-Speicherort eine von jeder Art von Komponente hat:
Ein Review-Skill und einen about-Befehl
Einen Security-Review-Subagenten
Einen Hook, der Dateien nach Claude-Bearbeitungen formatiert, und den scripts/-Ordner, den er aufruft
Einen Log-Monitor
Einen Output-Stil und ein Farbschema
Einen Route-Audit-Workflow
Eine hello-plugin-Ausführungsdatei
Standard-Einstellungen
Einen lokalen MCP-Server und einen Go-Sprachserver
Jede Datei ist das kleinste gültige Beispiel ihres Formats, um die Form zu zeigen, nicht um nützlich zu sein: Ein echter Skill oder Agent trägt vollständige Anweisungen und oft unterstützende Dateien, und ein echter Hook oder Monitor führt echte Arbeit aus. Die Abschnitte nach dem Explorer verwenden die gleichen Dateien als ihre Beispiele und verlinken auf vollständigere. Wählen Sie eine Datei oder einen Ordner aus, um zu lesen, wofür sie gedacht ist, zu sehen, was darin geht, und den Abschnitt zu finden, der sie behandelt.
Das [Manifest](/docs/de/plugins/manifest-reference) ist die `plugin.json`-Datei im `.claude-plugin/`-Verzeichnis eines Plugins. Sie enthält die Metadaten des Plugins und die `userConfig`-Werte, die Claude Code den Benutzer fragt. Nur `name` ist erforderlich. In diesem Fall ist `description` der Text, den Benutzer für das Plugin in `/plugin` sehen, und `version` hält Benutzer auf dieser Version, bis Sie sie ändern:
```json theme={null}
{
"name": "my-plugin",
"version": "1.0.0",
"description": "Review, formatting, and database tools for this team"
}
```
Ein [Skill](/docs/de/skills) ist eine `SKILL.md`-Datei. Speichern Sie jeden Skill in seinem eigenen Verzeichnis unter `skills/`. Claude liest die `description` jedes Skills, und wenn das, was der Benutzer fragt, damit übereinstimmt, wie zum Beispiel Claude zu bitten, einen Pull Request zu überprüfen, lädt Claude die Anweisungen des Skills und folgt ihnen. Der Benutzer kann ihn auch direkt als `/my-plugin:review` ausführen:
```markdown theme={null}
---
description: Reviews a pull request for style and test coverage. Use when asked to review code.
---
Review the changed files. Report style problems first, then missing tests.
```
Ein Befehl ist eine einzelne Markdown-Datei, die der Benutzer nach Name ausführt. Befehle sind das ältere Format: Ein Skill wird auf die gleiche Weise nach Name ausgeführt und kann auch unterstützende Dateien in seinem eigenen Verzeichnis tragen, daher schreiben Sie neue als Skills und behalten Sie `commands/` für Dateien, die Sie bereits haben. Diese Datei wird zu `/my-plugin:about` und nimmt die gleiche Frontmatter wie ein Skill:
```markdown theme={null}
---
description: Summarize the repository
---
Summarize what this repository does in three sentences.
```
Ein [Subagent](/docs/de/sub-agents) ist ein separater Assistent mit seinen eigenen Anweisungen und seinem eigenen Kontextfenster, dem Claude eine Aufgabe delegieren und ein Ergebnis zurückbekommen kann. Jede Markdown-Datei unter `agents/` definiert einen: Die Frontmatter benennt ihn und sagt, wann er zu verwenden ist, und der Text ist sein System-Prompt. Dieser wird `my-plugin:security-reviewer` genannt, und der Benutzer kann ihn mit `@agent-my-plugin:security-reviewer` aufrufen:
```markdown theme={null}
---
name: security-reviewer
description: Reviews code changes for security issues. Use after edits to authentication or input handling.
model: sonnet
---
You are a security reviewer. Read the changed files and report injection, authentication, and secrets-handling risks.
```
Ein [Hook](/docs/de/hooks-guide) führt etwas automatisch an einem Punkt im Lebenszyklus von Claude Code aus, wie zum Beispiel nach jeder Dateibearbeitung: ein Shell-Befehl, eine HTTP-Anfrage, ein MCP-Tool-Aufruf, ein Prompt an ein Modell oder ein Subagent. Speichern Sie die Hooks des Plugins in `hooks/hooks.json` im Plugin-Root. Dieser führt das `scripts/format.sh` des Plugins nach jedem Write oder Edit aus:
Ein Monitor ist ein Shell-Befehl, den Claude Code im Hintergrund startet, wenn die Sitzung startet, und der läuft, bis sie endet, unter Verwendung des [Monitor-Tools](/docs/de/tools-reference#monitor-tool). Was er ausgibt, erreicht Claude als Benachrichtigungen. Ein `when`-Feld kann ihn stattdessen starten, wenn ein benannter Skill zum ersten Mal ausgeführt wird. Dieser verfolgt ein Fehlerprotokoll:
Ein Plugin kann [Output-Stile](/docs/de/output-styles) enthalten, die ändern, wie Claude seine Antworten formatiert und formuliert. Speichern Sie jeden Output-Stil als `output-styles/.md`. Dieser erscheint in `/output-style` als `my-plugin:terse`:
```markdown theme={null}
---
name: terse
description: Answer in as few words as possible
keep-coding-instructions: true
---
Keep every reply short. Skip preambles and summaries.
```
Ein Plugin kann [Farbschemas](/docs/de/terminal-config#create-a-custom-theme) für die Claude Code-Schnittstelle enthalten. Speichern Sie jedes Schema als `themes/.json`. Dieses erscheint in `/theme` als `Dracula`, markiert als von `my-plugin`:
Der `workflows/`-Ordner enthält [Workflow](/docs/de/workflows) `.js`-Dateien: einen `meta`-Block, dann einen Script-Text, der mehrere Subagenten orchestriert. Dieser läuft als `/my-plugin:audit-routes`:
`bin/` ist, wie ein Plugin ein Befehlszeilentool versendet. Während das Plugin aktiviert ist, setzt Claude Code diesen Ordner auf den `PATH` der Shell, in der es Befehle ausführt, damit Claude oder die Anweisungen eines Skills das Tool nach Name ausführen können, ohne dass der Benutzer etwas installieren muss. Mit dieser [ausführbaren Datei](#executables) an Ort und Stelle ist `hello-plugin` ein Befehl, den Claude ausführen kann:
```bash theme={null}
#!/bin/bash
echo "hello from my-plugin"
```
Der Hook in `hooks/hooks.json` führt ein Script aus, und dieser Ordner ist, wo das Beispiel es behält. Der Name `scripts/` ist eine Konvention, nicht etwas, das Claude Code sucht: Der Hook zeigt auf die Datei nach ihrem Pfad, `${CLAUDE_PLUGIN_ROOT}/scripts/format.sh`. Ein Formatter-Script könnte so aussehen:
Eine `settings.json` im Plugin-Root hält [Einstellungen](/docs/de/settings-reference), die gelten, während das Plugin aktiviert ist, damit ein Plugin ändern kann, wie sich die Sitzung verhält, und nicht nur Komponenten hinzufügt. Nur zwei Schlüssel wirken sich von einem Plugin aus, [`agent`](/docs/de/settings-reference#agent) und [`subagentStatusLine`](/docs/de/settings-reference#subagentstatusline); jeder andere Schlüssel wird gelöscht. Siehe [Standard-Einstellungen](#default-settings).
Dieser setzt `agent`, der die Haupt-Thread-Sitzung als den eigenen `security-reviewer`-Agent des Plugins ausführt, damit der System-Prompt, die Tool-Einschränkungen und das Modell dieses Agenten auf die ganze Sitzung angewendet werden:
```json theme={null}
{
"agent": "security-reviewer"
}
```
Ein [MCP-Server](/docs/de/mcp) gibt Claude Tools von einem externen System. Deklarieren Sie ihn in `.mcp.json` im Plugin-Root. Dieser startet einen lokalen Server aus einem Script im Plugin und erscheint in `/mcp` als `plugin:my-plugin:db`:
Ein LSP-Server gibt Claude [Diagnostik und Code-Navigation](/docs/de/plugins/code-intelligence) für eine Sprache. Deklarieren Sie den Server in `.lsp.json` im Plugin-Root. Dieser verbindet den Go-Sprachserver für `.go`-Dateien:
Jeder Abschnitt unten behandelt eine Art von Komponente: wo ihre Dateien im Plugin gehen, ein Beispiel, das validiert, was der Benutzer sieht, sobald das Plugin geladen wird, und der Manifest-Schlüssel, der den Standard-Speicherort ändert. Fügen Sie die hinzu, die Ihr Plugin benötigt; keine ist erforderlich.
Skills
Ein Skill ist eine SKILL.md-Datei, die Claude laden kann, wenn ihre Beschreibung der Aufgabe entspricht. Der Benutzer kann ihn auch als Befehl ausführen. Speichern Sie jeden Skill in seinem eigenen Verzeichnis unter skills/:
Geben Sie der SKILL.md eine description, damit Claude weiß, wann er sie verwenden soll:
---
description: Reviews a pull request for style and test coverage. Use when asked to review code.
---
Review the changed files. Report style problems first, then missing tests.
Nachdem Sie das Plugin geladen haben, führt /my-plugin:review den Skill aus. Der Befehlsname und wer ihn aufrufen kann, folgen diesen Regeln:
Befehlsname: /<plugin>:<directory>, also skills/review/SKILL.md in my-plugin ist /my-plugin:review. Wenn Sie name in der Frontmatter setzen, ersetzt es das letzte Segment und das Plugin-Präfix bleibt. Siehe wie ein Skill seinen Befehlsnamen erhält
Sie können auch Skills außerhalb des Standard-skills/-Verzeichnisses platzieren:
Zusätzliche Verzeichnisse: Listen Sie sie im skills-Manifest-Schlüssel auf. Sie ergänzen den Standard-skills/-Scan, anstatt ihn zu ersetzen, anders als commands und agents
Ein einzelner Skill im Plugin-Root: Ohne skills/-Verzeichnis und ohne skills-Manifest-Schlüssel lädt eine SKILL.md im Plugin-Root als ein Skill. Setzen Sie name in seiner Frontmatter, da sonst eine Marketplace-Installation den Skill nach seinem Cache-Verzeichnis benennt, anstatt nach Ihrem Plugin
Um Anweisungen in ein Plugin einzubeziehen, schreiben Sie sie als Skill. Claude Code lädt keine CLAUDE.md im Plugin-Root, und claude plugin validate warnt CLAUDE.md at the plugin root is not loaded as project context.
Für Frontmatter-Felder und unterstützende Dateien siehe Skills.
Befehle
Ein Befehl ist eine einzelne Markdown-Datei, die der Benutzer nach Name ausführt, wie /my-plugin:about.
Speichern Sie einen Befehl unter commands/<file>.md und er wird zu /<plugin>:<file>. Ein Unterverzeichnis fügt ein Segment hinzu, also ist commands/db/migrate.md/my-plugin:db:migrate.
Befehlsdateien nehmen die gleiche Frontmatter wie Skills.
Definieren Sie Befehle im Manifest
Sie brauchen dies nur, wenn Sie Befehlsdateien irgendwo anders als commands/ behalten möchten, oder um einen kurzen Befehl in plugin.json ohne separate Markdown-Datei zu definieren. Setzen Sie den commands-Manifest-Schlüssel, und Claude Code liest ihn statt commands/ zu scannen. Der Schlüssel nimmt einen Pfad, ein Array von Pfaden oder ein Objekt, das jeden Befehlsnamen entweder auf eine source-Datei oder inline content abbildet.
Dieses Manifest definiert /my-plugin:about inline, ohne Markdown-Datei:
{"name": "my-plugin",
"commands": {"about": {"content": "Summarize what this repository does in three sentences.",
"description": "Summarize the repository"}}}
Laden Sie das Plugin und führen Sie /my-plugin:about in der Sitzung aus, um zu bestätigen, dass es geladen wurde.
Für die vollständige Schlüsselsyntax siehe commands.
Agents
Ein Subagent ist ein separater Assistent mit seinen eigenen Anweisungen und Kontextfenster, dem Claude eine Aufgabe delegieren kann. Jede Markdown-Datei unter agents/ definiert einen:
---
name: security-reviewer
description: Reviews code changes for security issues. Use after edits to authentication or input handling.
model: sonnet
---
You are a security reviewer. Read the changed files and report injection, authentication, and secrets-handling risks.
Dieser Agent wird my-plugin:security-reviewer genannt, und der Benutzer kann ihn explizit aufrufen mit @agent-my-plugin:security-reviewer. Die Namensform ist <plugin>:<name>, wobei <name> aus der Frontmatter kommt, oder aus dem Dateinamen, wenn es keine gibt.
Der agents-Manifest-Schlüssel ersetzt den agents/-Scan.
Organisieren Sie Agents in Unterordnern
Sie können Plugin-Agent-Dateien in Unterordnern von agents/ platzieren. Claude Code lädt sie rekursiv und verbindet den Plugin-Namen, jeden Unterordnernamen und den Dateinamen mit Doppelpunkten, um den scoped Namen des Agenten zu bilden. Zum Beispiel lädt agents/review/security.md in einem Plugin namens my-plugin als my-plugin:review:security. Zwei Einstellungen ändern diesen Namen:
Frontmatter name: Sie ersetzt nur den Dateinamen, also name: audit in agents/review/security.md lädt als my-plugin:review:audit
Manifest agents-Feld: Eine Datei, die Sie dort auflisten, lädt ohne Unterordnernamen, also "agents": "./custom/review/security.md" lädt als my-plugin:security
Frontmatter-Felder in Plugin-Agents
Die Frontmatter eines Plugin-Agenten folgt diesen Regeln:
Unterstützte Felder: name, description, model, effort, maxTurns, tools, disallowedTools, skills, memory, background, omitClaudeMd, isolation, color und der cacheTtl-Schlüssel von experimental. Der einzige gültige isolation-Wert ist "worktree". Siehe unterstützte Frontmatter-Felder für das, was jedes tut
Ignorierte Felder: permissionMode, hooks, mcpServers und initialPrompt. Eine Agent-Datei kann nicht auf eigene Faust Hooks oder MCP-Server hinzufügen, daher fügen Sie diese stattdessen als Plugin-Hooks und MCP-Server hinzu
Frontmatter, die nicht analysiert wird: Der Agent lädt immer noch mit jedem Feld ignoriert. Er wird nach der Datei benannt, und seine Beschreibung liest Agent from my-plugin plugin. Führen Sie claude plugin validate in Ihrer Shell aus, um diese Dateien zu finden
Für das, was jedes Feld tut und die Vorrangregeln, siehe Subagents.
Hooks
Ein Hook führt etwas automatisch an einem Punkt im Lebenszyklus von Claude Code aus, wie zum Beispiel nach jeder Dateibearbeitung: ein Shell-Befehl, eine HTTP-Anfrage, ein MCP-Tool-Aufruf, ein Prompt an ein Modell oder ein Subagent. Speichern Sie die Hooks des Plugins in hooks/hooks.json im Plugin-Root, unter einem Top-Level-"hooks"-Schlüssel, in der gleichen Form wie das hooks-Objekt in settings.json. Das ermöglicht es Ihnen, einen bestehenden Settings-Hook unverändert zu kopieren.
Dieser Hook führt ein gebündeltes Script nach jedem Write oder Edit aus:
Speichern Sie das Script unter scripts/format.sh und machen Sie es ausführbar.
Laden Sie das Plugin und bitten Sie Claude, eine Datei zu bearbeiten. Ein PostToolUse-Hook, der 0 beendet, zeigt nichts im Transkript, daher bestätigen Sie, dass er mit Debug-Logging oder durch das, was das Script selbst ändert, gelaufen ist.
Hooks in hooks/hooks.json und im hooks-Manifest-Schlüssel laden beide. Für jedes Ereignis und seine Nutzlast siehe Hook-Ereignisse.
Wenn Plugin-Hooks auslösen
Die Hooks eines Plugins warten nicht darauf, dass einer der Skills oder Befehle des Plugins verwendet wird. Claude Code registriert sie, wenn eine Sitzung das Plugin lädt, und sie lösen auf ihren Ereignissen von da an aus. Um einzuschränken, wann ein Hook läuft, verengen Sie seinen matcher.
Umgebung, Anführungszeichen und Matching von MCP-Tools
Die Umgebung des Hooks, die Anführungszeichen von ${CLAUDE_PLUGIN_ROOT} und Matcher für die eigenen MCP-Tools des Plugins funktionieren wie folgt:
Umgebung: Jeder Hook-Prozess erhält CLAUDE_PLUGIN_ROOT und CLAUDE_PLUGIN_DATA in seiner Umgebung, plus CLAUDE_PLUGIN_OPTION_<KEY> für jeden Benutzerkonfiguration-Wert, damit Ihr Script sie von dort lesen kann
Anführungszeichen: Wenn command keine args hat, läuft es durch eine Shell, daher wickeln Sie den ${CLAUDE_PLUGIN_ROOT}-Pfad in doppelte Anführungszeichen, wie das Beispiel hooks/hooks.json unter Hooks tut, um den erweiterten Pfad ein Shell-Wort zu halten. Wenn Sie stattdessen args übergeben, wird jedes Element als ein Argument ohne Shell übergeben und braucht keine Anführungszeichen. Siehe Exec-Form und Shell-Form
Matching der eigenen MCP-Tools des Plugins: Ein Tool von einem MCP-Server, den dieses Plugin deklariert, wird mcp__plugin_<plugin>_<server>__<tool> genannt, daher schreiben Sie diesen vollständigen Namen in den Matcher. Ein Matcher nur auf dem Servernamen löst nie aus. Siehe Match MCP-Tools
MCP-Server
Ein MCP-Server gibt Claude Tools von einem externen System. Deklarieren Sie ihn in .mcp.json im Plugin-Root, in der gleichen Form wie ein Projekt .mcp.json. Diese .mcp.json deklariert einen Server namens db:
Sie können auch den mcpServers-Wrapper weglassen und db auf der Top-Level der Datei platzieren.
Laden Sie das Plugin und führen Sie /mcp aus, um zu bestätigen, dass der Server als plugin:my-plugin:db erscheint.
claude plugin validate überprüft .mcp.json und meldet einen Server-Eintrag, den Claude Code zur Ladezeit als Fehler ablegen würde. Erfordert Claude Code v2.1.281 oder später.
Der mcpServers-Manifest-Schlüssel nimmt eine inline Server-Map, einen Pfad zu einer JSON-Datei oder ein Array davon. Wenn ein Manifest-Server den gleichen Namen wie einer in .mcp.json hat, ersetzt der Manifest-Server ihn.
Erreichen Sie Benutzer auf claude.ai und Cowork
Ein lokaler Stdio-Server, wie der db-Server unter MCP-Server, läuft in Claude Code und in einer Cowork-Sitzung, die auf Ihrem Computer in der Claude Desktop-App läuft, aber nicht auf claude.ai. Um Benutzer dort auch zu erreichen, referenzieren Sie einen Remote-Server durch seine https://-URL, die claude.ai und Cowork dem Benutzer als Connector anbieten.
Server-Namen, Tool-Namen und Neuladen
Die Namen des Servers, die Variable-Substitution und das Neuladen-Verhalten folgen diesen Regeln:
Server-Name: plugin:<plugin>:<server>, also der db-Server in my-plugin ist plugin:my-plugin:db in /mcp. Verwenden Sie die gleiche Form, um den Server in einem mcp_tool-Hook zu benennen
Tool-Namen: mcp__plugin_<plugin>_<server>__<tool>, also ein query-Tool auf diesem db-Server ist mcp__plugin_my-plugin_db__query. Das ist der Name, der in Berechtigungsregeln und Hook-Matchern verwendet wird
Substitution: ${CLAUDE_PLUGIN_ROOT} und die anderen Pfad-Variablen werden in command, args und env ersetzt. Keine Anführungszeichen sind in args erforderlich, da jedes Element als ein Argument übergeben wird
Neuladen: Wenn der Benutzer /reload-plugins ausführt und das Neuladen angewendet wird, behält ein Server, dessen Konfiguration unverändert ist, seine Verbindung. Ein Server, dessen Konfiguration sich geändert hat, verbindet sich neu, und einer, den Sie entfernt haben, trennt sich
Schließen Sie einen verpackten MCPB-Server ein
Der mcpServers-Schlüssel akzeptiert auch einen verpackten Server als MCPB-Datei, deren Erweiterung .mcpb oder die ältere .dxt ist. Zeigen Sie den Schlüssel auf die Datei, als Pfad im Plugin oder eine https://-URL:
Ein LSP-Server gibt Claude Diagnostik und Code-Navigation für eine Sprache. Wenn ein offizielles Code-Intelligence-Plugin Ihre Sprache bereits abdeckt, installieren Sie das statt einen zu schreiben. Andernfalls deklarieren Sie den Server in .lsp.json im Plugin-Root:
Die Datei bildet jeden Server-Namen direkt auf seine Konfiguration ab, ohne ein Wrapper-Objekt um die Map. command ist der Name des Binärs, mit seinen Argumenten in args. extensionToLanguage braucht mindestens eine Erweiterung, jede beginnend mit ..
claude plugin validate liest diese Datei nicht. Wenn ein Eintrag ungültig ist, wird die ganze Datei zur Ladezeit übersprungen und Invalid LSP server config for ".lsp.json" erscheint in der /plugin-Registerkarte Errors.
Ihr Plugin konfiguriert die Verbindung, installiert aber nicht das Server-Binär, und jede Dateierweiterung bekommt einen Server:
Fehlendes Binär: Claude Code startet command nach Name aus dem PATH des Benutzers. Wenn das Binär nicht da ist, schlägt der Server fehl zu starten und claude --debug protokolliert LSP server <name> failed to start
Erweiterungs-Konflikte: Wenn zwei aktivierte Server die gleiche Erweiterung beanspruchen, behandelt der erste registrierte diese Dateien und der andere wird nicht für sie verwendet, ob die Server von einem Plugin oder zwei kommen. Die /plugin-Registerkarte Errors zeigt die Warnung LSP server "<name>" is not used for <ext> files
Der lspServers-Manifest-Schlüssel nimmt die gleiche Map inline, einen Pfad zu einer JSON-Datei oder ein Array davon, und seine Server ergänzen die in .lsp.json. Wenn ein Manifest-Server den gleichen Namen wie einer in .lsp.json hat, ersetzt der Manifest-Server ihn.
Für transport, Timeouts, Neustarts und die anderen Felder siehe lspServers.
Senden Sie Log-Ausgabe an stderr, nicht stdout. Claude Code liest den stdout eines Servers nur als Protokoll-Nachrichten und akzeptiert Nachrichten-Header bis zu 64 KiB und einen Nachrichten-Text bis zu 32 MiB.
Claude Code trennt einen Server, der eines der Limits überschreitet oder nicht-Protokoll-Ausgabe an stdout schreibt, und zählt die Trennung als Absturz für restartOnCrash und maxRestarts. Wenn Sie mit --debug laufen, schreibt Claude Code einen Fehler, der die Ursache benennt, in das Debug-Log.
Ausführbare Dateien
Dateien in bin/ im Plugin-Root sind auf dem PATH der Shell des Bash-Tools, während das Plugin aktiviert ist, daher kann Claude sie als bloße Befehle ausführen. Fügen Sie ein ausführbares Script hinzu:
#!/bin/bashecho"hello from my-plugin"
Machen Sie es mit chmod +x bin/hello-plugin ausführbar und laden Sie das Plugin. Wenn Sie Claude bitten, hello-plugin auszuführen, zeigt das Bash-Tool-Ergebnis die Ausgabe des Scripts.
Plugin-bin/-Verzeichnisse kommen nach den eigenen PATH-Einträgen des Benutzers, daher kann ein Plugin nicht git, ls oder einen anderen System-Befehl überschatten.
Um Standard-Einstellungen zu setzen, die gelten, während das Plugin aktiviert ist, fügen Sie eine settings.json im Plugin-Root hinzu, oder setzen Sie das gleiche Objekt inline im settings-Manifest-Schlüssel. Zwei Schlüssel wirken sich aus, agent und subagentStatusLine, und jeder andere Schlüssel wird gelöscht.
Setzen Sie agent, um einen der eigenen Agents des Plugins als Haupt-Thread auszuführen:
{"agent": "security-reviewer"}
Laden Sie das Plugin und starten Sie eine Sitzung. Claude antwortet dann in der Haupt-Konversation mit dem System-Prompt und Modell des security-reviewer-Agenten.
Für alles, das der Schlüssel kontrolliert, siehe die agent-Einstellung.
Wenn der gleiche Schlüssel an mehr als einem Ort gesetzt ist, entscheiden diese Regeln, welcher Wert angewendet wird:
Datei über Manifest: Wenn beide existieren und settings.json mindestens einen unterstützten Schlüssel setzt, wendet settings.json an und das Manifest settings wird ignoriert
Benutzer-Einstellungen über Plugin-Standard: Über Einstellungs-Quellen hinweg sind Plugin-Standard die niedrigste Schicht, daher überschreibt Ihr eigenes agent eines Benutzers in ~/.claude/settings.json Ihres
Zwei Plugins setzen den gleichen Schlüssel: Der Wert vom zuletzt geladenen Plugin wendet an, und claude --debug protokolliert overrides setting
Ein Plugin kann Farbschemas und Output-Stile enthalten. Beide erscheinen in den gleichen Pickern wie die des Benutzers. Für jeden setzt der Manifest-Schlüssel den Ordner-Scan.
Plugin-Themen sind schreibgeschützt, daher wenn ein Benutzer eines in /theme bearbeitet, wird die Bearbeitung als Kopie in seinem eigenen Themen-Verzeichnis gespeichert.
Dieses Thema färbt den Prompt-Akzent und Fehlertext auf der dunklen Voreinstellung um:
Ein Kanal ermöglicht es einem externen System wie einer Chat-App, Nachrichten in eine Sitzung zu senden. In einem Plugin ist ein Kanal einer der MCP-Server plus ein channels-Eintrag, der sich daran bindet und seine eigene Konfiguration auffordern kann. Dieses Manifest bindet einen Kanal an einen telegram-Server und fragt nach einem Bot-Token:
server muss einem Schlüssel in mcpServers entsprechen. Die pro-Kanal userConfig nimmt die gleiche Form wie der Top-Level-userConfig-Schlüssel.
Für das, was der Server implementieren muss und wie Benutzer einen Kanal-Plugin aktivieren, siehe Als Plugin verpacken in der Kanäle-Referenz. Für die Feldtabelle siehe channels.
Monitore
Ein Monitor ist ein Shell-Befehl, der im Hintergrund für die ganze Sitzung läuft. Was er ausgibt, erreicht Claude als Benachrichtigungen, daher kann Claude auf ein Protokoll oder eine Statusänderung reagieren, ohne gebeten zu werden, es zu beobachten. Speichern Sie die Einträge in monitors/monitors.json:
Der Befehl läuft in einer Shell, im Arbeitsverzeichnis, in dem die Sitzung gestartet wurde.
Der Befehl eines Monitors ist begrenzt, wo er startet und was er referenzieren kann:
Nur interaktive Sitzungen: Plugin-Monitore starten in einer interaktiven Sitzung und nie im nicht-interaktiven Modus mit dem -p-Flag. Sie starten auch nur, wo das Monitor-Tool verfügbar ist
Keine Benutzerkonfiguration: command erhält die Pfad-Variablen und ${ENV_VAR} aus der Umgebung, aber nie ${user_config.*}. Ein Monitor, der einen referenziert, startet nicht, und Monitor-Prozesse erhalten auch nicht CLAUDE_PLUGIN_OPTION_<KEY>
Deaktivieren während der Sitzung: Wenn Sie ein Plugin während der Sitzung deaktivieren, stoppt Claude Code nicht die Monitore, die bereits laufen. Sie stoppen, wenn die Sitzung endet
Der experimental.monitors-Manifest-Schlüssel nimmt das gleiche Array inline oder einen Pfad zu einer JSON-Datei und wird statt monitors/monitors.json gelesen.
Für den when-Trigger und die anderen Felder siehe monitors.
Fragen Sie den Benutzer nach Konfigurationswerten
Deklarieren Sie die Werte, die Ihr Plugin vom Benutzer benötigt, im userConfig-Manifest-Schlüssel, damit Benutzer nicht settings.json selbst bearbeiten. Jede Option erscheint in einem Dialog mit seinem title als Label und seiner description darunter.
Setzen Sie "sensitive": true für einen Token oder ein Passwort. Der Dialog maskiert dann die Eingabe, und der Wert wird in sicherer Speicherung statt settings.json gespeichert.
Dieses Manifest fragt nach einem Endpunkt und einem Token:
{"name": "my-plugin",
"userConfig": {"api_url": {"type": "string",
"title": "API URL",
"description": "Base URL of your team's API"},
"api_token": {"type": "string",
"title": "API token",
"description": "Token for your team's API",
"sensitive": true
}}}
Wenn der Konfigurationsdialog erscheint
Der Dialog erscheint nur in der interaktiven /plugin-Schnittstelle. Er öffnet sich für jede Option, die noch nicht gesetzt ist, wenn der Benutzer eines der folgenden tut:
Installiert das Plugin in /plugin
Führt /plugin install <plugin>@<marketplace> in einer Sitzung aus
Aktiviert das Plugin aus der Installed-Registerkarte in /plugin
Um den gleichen Dialog jederzeit zu öffnen, führt der Benutzer /plugin configure <plugin>@<marketplace> aus.
Der claude plugin install-Shell-Befehl fordert nie userConfig-Werte auf. Um Werte aus der Shell zu setzen, übergeben Sie jeden als --config KEY=VALUE. Wenn Optionen ungesetzt bleiben, druckt der Befehl eine userConfig options not yet set-Zeile, die beide Wege benennt, um sie zu setzen. Der userConfig-Dialog erscheint nie zitiert die Zeile.
Für die Optionsfelder, wo jeder Wert gespeichert wird, wie eine Komponente einen gespeicherten Wert referenziert und welche Felder ${user_config.*} ablehnen, siehe Benutzerkonfiguration.
Referenzieren Sie Plugin-Pfade und speichern Sie Daten
Sie wissen nicht, wo Ihr Plugin installiert wird, daher referenzieren Sie seine Dateien und Daten durch diese Variablen statt fester Pfade. Sie werden in Skill-, Befehls- und Agent-Inhalten, in Hook- und Monitor-Befehlen und in MCP- und LSP-Server-Konfigurationen ersetzt. Sie werden auch an Hook-, MCP- und LSP-Prozesse exportiert:
${CLAUDE_PLUGIN_ROOT}: Das Installationsverzeichnis des Plugins. Jede Version hat ihr eigenes Cache-Verzeichnis, daher ändert sich der Pfad, wenn das Plugin aktualisiert wird. Schreiben Sie keinen Zustand dort
${CLAUDE_PLUGIN_DATA}: Ein Verzeichnis, das Updates überlebt, für node_modules, virtuelle Umgebungen und Caches. Es wird zu ~/.claude/plugins/data/<id>/ aufgelöst und wird erstellt, wenn zuerst referenziert
${CLAUDE_PROJECT_DIR}: Das Projekt-Root, der gleiche Wert, den Hooks erhalten
Im Pfad des Daten-Verzeichnisses ist <id> die Plugin-ID mit jedem Zeichen außer Buchstaben, Ziffern, _ und - ersetzt durch -, daher wird my-plugin@my-marketplace zu my-plugin-my-marketplace.
Auf Windows verwenden die ersetzten Pfade Schrägstriche, daher liest eine Shell Backslashes nicht als Escapes.
Installieren Sie Abhängigkeiten in das Daten-Verzeichnis
Für ein Marketplace-installiertes Plugin installiert Claude Code automatisch berechtigte Node.js-Paket-Abhängigkeiten, wenn es das Plugin zwischenspeichert, daher müssen Sie sie möglicherweise nicht selbst installieren. Wenn Sie es tun, installiert dieser SessionStart-Hook node_modules in ${CLAUDE_PLUGIN_DATA} beim ersten Lauf und erneut nach einer Aktualisierung, die package.json ändert:
Nach der ersten Sitzung existiert ~/.claude/plugins/data/<id>/node_modules. Ein MCP-Server kann dann NODE_PATH auf ${CLAUDE_PLUGIN_DATA}/node_modules in seinem env setzen. Für welche Felder welche Variable ersetzen, siehe Umgebungsvariablen.
953Ein Plugin kann Farbschemas und Output-Stile enthalten. Beide erscheinen in den gleichen Pickern wie die des Benutzers. Für jeden setzt der Manifest-Schlüssel den Ordner-Scan.953Ein Plugin kann Farbschemas und Output-Stile enthalten. Beide erscheinen in den gleichen Pickern wie die des Benutzers. Für jeden setzt der Manifest-Schlüssel den Ordner-Scan.
954954
955| Komponente | Speichern unter | Format | Erscheint in | Manifest-Schlüssel |955| Komponente | Speichern unter | Format | Erscheint in | Manifest-Schlüssel |
957| Thema | `themes/<slug>.json` | Das [benutzerdefinierte Thema-Dateiformat](/docs/de/terminal-config#create-a-custom-theme), das Benutzer in `~/.claude/themes/` schreiben | `/theme`, unter dem `name` der Datei | `experimental.themes` |957| Thema | `themes/<slug>.json` | Das [benutzerdefinierte Thema-Dateiformat](/docs/de/terminal-config#create-a-custom-theme), das Benutzer in `~/.claude/themes/` schreiben | `/theme`, unter dem `name` der Datei | `experimental.themes` |
958| Output-Stil | `output-styles/<name>.md` | Das [benutzerdefinierte Output-Stil-Format](/docs/de/output-styles#create-a-custom-output-style), mit `name` und `description`-Frontmatter | `/output-style`, als `<plugin>:<name>` | `outputStyles` |958| Output-Stil | `output-styles/<name>.md` | Das [benutzerdefinierte Output-Stil-Format](/docs/de/output-styles#create-a-custom-output-style), mit `name` und `description`-Frontmatter | `/output-style`, als `<plugin>:<name>` | `outputStyles` |