Devin CLI-Plugins

Ein Plugin ist ein Bündel von Skills und optionalen Regeln, Hooks, MCP-Servern oder benutzerdefinierten Subagenten, das Sie aus einem GitHub-Repo, einer Git-URL, einem Unterordner eines Repo oder einem lokalen Ordner installieren können. Plugins funktionieren in Devin Cloud-Sitzungen, der Devin CLI und Devin Desktop, vorbehaltlich der unten beschriebenen oberflächenspezifischen Einschränkungen. Beim Installieren eines Plugins werden seine Skills als /<plugin>:<skill>-Slash- Befehle verfügbar. Diese Seite behandelt Plugins in der CLI; für die Web-App — die Seite Customize, Organisations- und Enterprise-Geltungsbereiche, Indexing und MCP-Verbindungen — siehe den Plugins-Leitfaden. Das Plugin ist die Installationseinheit. Beim Installieren eines Plugins werden alle seine Skills und seine requiredPlugins installiert; Sie können keine einzelnen Skills aus einem Plugin installieren. Um Skills separat anzubieten, teilen Sie sie in separate Plugins auf. Ein Plugin ist einfach eine source, die Folgendes enthält:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # The plugin manifest
├── AGENTS.md           # Optional always-on rule
├── rules/              # Optional triggered rules
├── agents/
│   └── reviewer.md     # Optionaler benutzerdefinierter Subagent (reviewer/AGENT.md funktioniert auch)
├── hooks.json          # Optional lifecycle hooks
├── .mcp.json           # Optional MCP servers
└── skills/
    └── review/
        └── SKILL.md    # An ordinary skill

Das skills/-Verzeichnis enthält normale Skills — Plugins bringen kein neues Skill- Format mit. Das Format von SKILL.md wird unter Skills erstellen beschrieben. Ein Repo (oder ein git-subdir-Unterordner) entspricht einem Plugin. Ein einzelnes Repo kann viele Plugins als Unterordner enthalten, die jeweils mit einer eigenen git-subdir-Quelle referenziert werden. Über Skills hinaus kann ein Plugin Folgendes mitliefern:

Regeln — eine AGENTS.md im Plugin-Stammverzeichnis wird in jeder Sitzung zusammen mit den eigenen Regeln Ihres Projekts als immer aktive Regel eingefügt. Markdown-Dateien in einem rules/-Ordner werden ebenfalls geladen, mit demselben trigger-Frontmatter und denselben Aktivierungstypen wie Windsurf-Regeln.
Benutzerdefinierte Subagenten — agents/<name>.md oder agents/<name>/AGENT.md-Profile (dasselbe Format für benutzerdefinierte Subagenten wie Projekt- Subagenten), verfügbar als <plugin>:<name>. Plugin-Subagenten werden derzeit nur in lokalen Devin-Agenten geladen — in der CLI und in Devin Desktop — nicht in Cloud-Devin-Sitzungen.
Hooks — eine hooks.json im Plugin-Stammverzeichnis registriert Lifecycle-Hooks in lokalen Devin- Sitzungen (der CLI und Devin Desktop), in denen das Plugin installiert ist. Plugin-Hooks funktionieren derzeit nach dem Best-Effort-Prinzip und sind nicht blockierend — falls ein Hook nicht geladen oder ausgeführt werden kann, wird die Sitzung ohne ihn fortgesetzt — verlassen Sie sich daher noch nicht auf sie für entscheidende Guardrails.
MCP-Server — Plugins können optionale MCP-Server bereitstellen, die mit der Sitzung starten. Ihre Tools sind für Devin verfügbar. In der CLI authentifizieren Sie den OAuth-Server eines Plugins mit devin mcp login; Cloud-Sitzungen verwenden die in der Web-App hergestellte Verbindung (siehe MCPs). Eine Plugin-MCP-Konfiguration kann eine OAuth-Client-ID und Scopes festlegen, aber niemals ein Client Secret — eine Serverkonfiguration, die eines enthält, wird bei der Aktivierung abgelehnt. Referenzieren Sie Secrets als ${NAME}; literale Werte, die in die Konfiguration geschrieben werden, werden entfernt.

Kompatible Formate

Der obige Aufbau ist Devins eigenes Plugin-Format. Devin lädt auch Plugins, die in zwei weiteren Strukturen paketiert sind, mit folgendem Manifest-Vorrang: .devin-plugin/plugin.json > .claude-plugin/plugin.json > plugin.json im Stammverzeichnis:

Claude-Plugins — wenn keine .devin-plugin/plugin.json vorhanden ist, greift Devin auf .claude-plugin/plugin.json zurück. Die .mcp.json im Stammverzeichnis und das Manifestfeld mcpServers von Claude-Plugins werden berücksichtigt, und ${CLAUDE_PLUGIN_ROOT} in Serverkonfigurationen wird zum Plugin-Stammverzeichnis aufgelöst.
Agent Plugins — Plugins, die gemäß der offenen Agent Plugins 1.0.0 Spezifikation paketiert sind (ein plugin.json-Manifest im Plugin-Stammverzeichnis, MCP-Server in einer mcp.json im Stammverzeichnis, Skills unter skills/), werden ebenfalls geladen. Für diese Plugins wird die mcp.json im Stammverzeichnis als konventionelle MCP-Quelle gelesen (nach .mcp.json, die bei einer Kollision von Servernamen Vorrang hat) — Legacy-Plugins im Devin-/Claude-Aufbau lesen sie nur, wenn ihr Manifest sie ausdrücklich deklariert. MCP-Einträge können ihren Transport über das type-Feld der Spezifikation (stdio, streamable-http oder sse) statt über transport angeben, und ${PLUGIN_ROOT} in Serverkonfigurationen wird wie ${CLAUDE_PLUGIN_ROOT} zum Plugin-Stammverzeichnis aufgelöst. Bei einer nicht erkannten $schema-Version wird eine Warnung ausgegeben, und das Plugin wird dennoch bestmöglich geladen. MCP-Server von Agent Plugins erhalten außerdem die Runtime-Konventionen der Spezifikation (diese gelten nur für Plugins, deren Manifest die plugin.json im Stammverzeichnis ist; Devin- und Claude-Aufbauten verhalten sich genau wie zuvor):
- ${PLUGIN_DATA} in args, env-Werten und cwd wird zu einem persistenten, beschreibbaren Datenverzeichnis pro Plugin aufgelöst. Das Verzeichnis ist über die Plugin-Identität — nicht die Version — bestimmt, sodass sein Inhalt Plugin-Updates überdauert, und wird gelöscht, wenn das Plugin deinstalliert wird.
- stdio-Serverprozesse erhalten die Umgebungsvariablen PLUGIN_ROOT und PLUGIN_DATA zusätzlich zu allen env-Werten, die in der Konfiguration festgelegt sind.
- Ein Server kann cwd festlegen (relativ zum Plugin-Stammverzeichnis); standardmäßig ist dies das Plugin-Stammverzeichnis. Ein mit ./ beginnender command wird relativ zum Plugin-Stammverzeichnis aufgelöst, sodass Plugins ihre eigenen ausführbaren Dateien mitliefern können. Beide werden darauf geprüft, innerhalb des Plugin-Stammverzeichnisses oder Datenverzeichnisses zu bleiben.

Ein Plugin installieren

Als Plugin-Quelle sind ein GitHub-owner/repo, eine Git-URL oder ein lokaler Pfad möglich; hängen Sie #path/to/plugin an, wenn das Plugin unterhalb des Root-Verzeichnisses liegt:

# Von GitHub
devin plugins install acme/review-tools

# Ein Plugin in einem Unterordner eines Repos
devin plugins install acme/plugins#plugins/review

# Von einem beliebigen Git-Host
devin plugins install https://gitlab.com/acme/review-tools.git

# Aus einem lokalen Ordner (ideal zum Entwickeln)
devin plugins install ./my-plugin

# Nur auf dieser Maschine, keine Synchronisierung mit Ihren persönlichen Plugins in Devin Cloud
devin plugins install --local ./my-plugin

Vor der Installation zeigt Devin an, was das Plugin hinzufügt — welche Skills es bereitstellt, welche erforderlichen Plugins automatisch installiert werden und welche Richtlinie es einführt (zum Beispiel, wenn es andere Plugins verbietet). Übergeben Sie -y / --yes, um die Abfrage zu überspringen. Plugins werden auf Nutzer-Ebene installiert und sind in all Ihren Projekten verfügbar. Standardmäßig trägt install das Plugin in Ihr persönliches Manifest in Devin Cloud ein, sodass dieselben Plugins auf jeder Maschine geladen werden, auf der Sie sich anmelden (und in Ihren Cloud-Sitzungen). Übergeben Sie --local, um das Plugin nur auf der aktuellen Maschine zu installieren. Für die Verwaltung von Plugins müssen Sie angemeldet sein (devin auth login); ein Enterprise kann CLI-Plugins für seine Member deaktivieren — in diesem Fall werden installierte Plugins nicht angewendet.

Plugins verwalten

# Installierte Plugins, ihre Versionen und durch Richtlinien blockierte Plugins auflisten
devin plugins list

# Skills, Hooks und Regel eines Plugins sowie seine Listen erforderlich/optional/verboten anzeigen
devin plugins info review-tools

# Ein Plugin (oder alle Plugins) in der neuesten Version erneut abrufen
devin plugins update review-tools
devin plugins update

# Ein Plugin aus deinen persönlichen Plugins entfernen (automatisch installierte erforderliche Plugins bleiben erhalten)
devin plugins remove review-tools

# Nur von dieser Maschine entfernen (schlägt bei Plugins in deinen persönlichen Plugins fehl)
devin plugins remove review-tools --local

# Plugin-Anforderungen aus Repos entfernen, die nicht mehr auf der Festplatte liegen, und ungenutzte Plugin-Inhalte bereinigen
devin plugins prune

remove --force entfernt ein Plugin auch dann, wenn ein anderes Plugin oder ein Governance-Manifest es weiterhin voraussetzt; ein per Governance vorausgesetztes Plugin wird bei der nächsten Sitzung im anfordernden Geltungsbereich erneut installiert, und die CLI weist darauf hin, welche Enterprise-, Organisations- oder Repository-Konfiguration es weiterhin voraussetzt. Plugins aus lokalen Ordnern sind direkt mit ihrem Quellordner verknüpft, Änderungen wirken also sofort: devin plugins install --local ./my-plugin → skills/<name>/SKILL.md bearbeiten → die Änderungen gelten ab der nächsten Sitzung, ohne update. Wenn die CLI das Plugin hat, in Customize aber fehlende oder veraltete Inhalte angezeigt werden, siehe Indexierungsprobleme beheben. devin plugins update aktualisiert lokale Plugin-Inhalte; Reindex plugins in Customize aktualisiert die Auflistung im Web. Eine mit --local durchgeführte Installation bleibt auf diesem Gerät.

Manifest

.devin-plugin/plugin.json beschreibt das Plugin. Nur name ist erforderlich; der Wert muss unter den installierten Plugins eindeutig sein (er bildet den Namespace /<name>:…). Namen bestehen aus alphanumerischen Kleinbuchstaben mit einzelnen -- oder .-Trennzeichen (z. B. review-tools, acme.tools).

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

Metadaten

name, version, description, author ({ name, email }), homepage, repository, license und keywords. Nur name wird für die Identität und den Namespace des Plugins verwendet; die übrigen sind beschreibend und werden von devin plugins info angezeigt.

Skills & Regeln

Das Feld skills legt fest, aus welchen Quellen Skills geladen werden, und ersetzt das Standardverzeichnis skills/. Es akzeptiert einen einzelnen Pfad relativ zum Plugin-Stammverzeichnis oder ein Array solcher Pfade:

{ "skills": "custom-skills" }
{ "skills": ["skills", "extra/skills"] }

Ein leeres Array ("skills": []) deaktiviert das Laden von Skills vollständig. Pfade müssen innerhalb des Plugins bleiben — absolute Pfade, ~ und ..-Traversal werden abgelehnt, und ein ungültiger Eintrag führt dazu, dass das gesamte Manifest fehlschlägt. Regeln werden unabhängig von skills geladen: Eine AGENTS.md im Plugin-Stammverzeichnis ist immer aktiv, und Markdown-Dateien im Verzeichnis rules/ werden als getriggerte Regeln geladen. Details zur Aktivierung finden Sie unter Regeln.

MCP-Server

Das Feld mcpServers fügt Deklarationen für MCP-Server hinzu. Plugins können auch die übliche Datei .mcp.json im Stammverzeichnis verwenden (bzw. mcp.json bei Plugins mit dem Root-Manifest-Aufbau von Agent Plugins). Vier Formate werden unterstützt:

// Eine Deklarationsdatei
{ "mcpServers": "config/mcp.json" }

// Mehrere, in der angegebenen Reihenfolge gelesen
{ "mcpServers": ["config/mcp.json", "config/extra.json"] }

// Nur diese Dateien – unterdrückt die Konvention der root-Datei .mcp.json / mcp.json
{ "mcpServers": { "paths": ["config/mcp.json"], "exclusive": true } }

// Inline-server-Map (unterdrückt die root-Konvention, sofern nicht leer)
{ "mcpServers": { "linear": { "command": "npx", "args": ["-y", "linear-mcp"] } } }

Deklarierte Pfade unterliegen denselben Begrenzungsregeln wie skills, unsichere Einträge werden jedoch verworfen, statt dass das Plugin fehlschlägt. Ein ungültiges Feld mcpServers deaktiviert nur das Laden von MCP; Skills, Rules und Hooks bleiben weiterhin nutzbar. Ein leeres Array fügt keine Deklarationsdateien hinzu, unterdrückt die Root-Konvention jedoch nicht. Eine leere Inline-Map lässt die Root-Konvention ebenfalls aktiviert. Wenn derselbe Servername in mehr als einer Quelle vorkommt, hat die erste Quelle Vorrang.

Abhängigkeiten

Ein Abhängigkeitseintrag ist eine source — entweder eine Zeichenfolgen-Kurzform oder ein Objekt:

Form	Bedeutung
`"owner/repo"`	GitHub-Repository
`"https://…"`, `"git@…"`, `"ssh://…"`	beliebige Git-URL
`{ "source": "github", "repo": "owner/repo" }`	GitHub, Objektform
`{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`	Git-URL, Objektform
`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`	ein Plugin in einem Unterordner eines gemeinsam genutzten Repo
`{ "source": "github", "repo": "owner/repo", "sha": "3f2a9c1…" }`	auf einen exakten Commit angepinnt — ändert sich nie, bis du den Eintrag bearbeitest
`{ "source": "github", "repo": "owner/repo", "ref": "v2" }`	verfolgt einen Branch oder ein Tag — wird bei jeder Aktualisierung neu bezogen

sha und ref funktionieren mit jeder Objektform (github, url, git-subdir) und schließen sich gegenseitig aus: Ein sha ist ein Pin, ein ref bleibt beweglich. Fehlen beide, folgt die Source dem Standard-Branch des Repository. Alle GitHub-Formen für dasselbe Repo (owner/repo, die HTTPS-URL, die .git-URL, die SSH-Form) verweisen auf dieselbe Plugin-Identität. Ein Plugin kann drei Listen definieren, sodass ein einzelnes Plugin als kuratierte, verwaltete Sammlung anderer Plugins dienen kann.

`requiredPlugins`

Wird automatisch (rekursiv) mitinstalliert, wenn das Plugin installiert wird. Wenn ein erforderliches Plugin durch eine Richtlinie blockiert wird, schlägt die gesamte Installation fehl — eine Teilinstallation ist nicht möglich.

`optionalPlugins`

Eine Allowlist von Plugins, die von diesem Plugin ausdrücklich erlaubt werden. Sie werden nicht automatisch installiert; die Liste ist nur als Ausnahme für einen verbotenen Eintrag relevant (siehe unten).

`forbiddenPlugins`

Eine Verbotsliste von Plugin-Identitäten und Glob-Mustern. forbiddenPlugins-Einträge werden mit Plugin-Identitäten abgeglichen:

Eine exakte Identität, angegeben als owner/repo oder als git-URL. Alle GitHub-Varianten desselben Repo (owner/repo, die HTTPS-URL, die .git-URL, die SSH-Form) beziehen sich auf dieselbe Identität.
Ein Glob-Muster — also jeder Eintrag, der * enthält. Das * steht für jede Zeichenfolge, einschließlich /: acme/* entspricht allen GitHub-Repos von acme, */secrets entspricht einem Repo namens secrets unter jedem Owner und https://gitlab.com/acme/* entspricht jedem Repo unter diesem Pfad.
Das einzelne "*", das auf alles andere passt (ein vollständiger Lockdown).

Die Listen werden nach dem Deny-wins-Prinzip kombiniert:

Deny wins. Ein Plugin wird blockiert, wenn es von einem aktiven Manifest oder einem installierten Plugin verboten wird. Wenn nichts verboten ist, wird auch nichts blockiert.
Selbst-Override. Die eigenen requiredPlugins und optionalPlugins eines Manifests (oder Plugins) — und bei einem Plugin das Plugin selbst — sind von seiner eigenen Verbotsliste ausgenommen; "forbiddenPlugins": ["*"] plus "optionalPlugins": ["acme/approved"] bedeutet also: „Erlaube nur, was dieses Manifest auflistet; verbiete alles andere.“ Diese Ausnahme gilt nur für diese direkten Einträge, nicht für die transitiven Abhängigkeiten eines erforderlichen Plugins — führe sie bei einem Lockdown ausdrücklich auf.
Keine scope-übergreifende Wiederfreigabe. Die Allow-List eines Manifests oder Plugins kann nicht erneut erlauben, was ein anderes verbietet. Ein "forbiddenPlugins": ["*"]-Lockdown kann nicht aus einem niedrigeren Geltungsbereich ausgehebelt werden.

Die Durchsetzung erfolgt an zwei Stellen:

Bei der Installation — die Installation eines blockierten Plugins (oder eines Plugins, dessen erforderliche Plugins nicht erfüllt werden können oder dessen Name mit einem installierten Plugin kollidiert) wird verweigert.
Beim Laden — ein Plugin, das erst nach der Installation blockiert wird, bleibt auf dem Datenträger, aber seine Skills werden beim Start der Sitzung übersprungen, zusammen mit einer Warnung, die den Verursacher des Verbots nennt.

Eine verbotene Identität kann neben den oben genannten Formen owner/repo und Git-URL auch ein lokaler Pfad sein (für Plugins, die aus einem lokalen Ordner installiert werden).

Vererbung und Ebenen

Plugins werden nicht an einer einzigen Stelle deklariert. Zusätzlich zu Ihren eigenen Installationen können Plugins von Ihrem Repo und vom Admin Ihrer Organisation vorgeschrieben, empfohlen oder verboten werden. Jede Quelle ist eine Ebene, und die Ebenen sind nach Autorität geordnet, mit der höchsten zuerst:

Enterprise — das kontoweit verwaltete Manifest, das von einem Enterprise Admin konfiguriert wird.
Org — ein auf Organisationsebene verwaltetes Manifest, das unterhalb des zugehörigen Enterprise liegt (eine Org kann ergänzen, was ihr Enterprise deklariert, es aber nicht außer Kraft setzen). Cloud-Sitzungen verwenden das Manifest der Organisation der Sitzung; die CLI und Devin Desktop verwenden das Manifest Ihrer primären Organisation.
Repo — die requiredPlugins / optionalPlugins / forbiddenPlugins in der .devin/config.json eines Checkouts, die ermittelt werden, indem vom Arbeitsverzeichnis aus nach oben traversiert wird (in Cloud-Sitzungen von jedem geklonten Repository aus).
User — Plugins, die Sie selbst mit devin plugins install installieren (über Ihr persönliches Manifest synchronisiert) oder mit --local auf dieser Maschine.

Die CLI ruft die Enterprise-, Org- und persönlichen Manifeste beim Anmelden von Devin Cloud ab; Admins verwalten die ersten beiden über die Web-App (siehe den Plugins-Leitfaden). Jede Ebene deklariert dieselben drei Listen, und innerhalb einer Ebene werden sie nach denselben Deny-wins-, Self-override-Regeln wie ein einzelnes Manifest zusammengeführt. Zusätzlich kommt über die Ebenen hinweg eine Regel hinzu: Die höhere Autorität setzt sich durch.

Höhere Autorität setzt sich durch

Eine niedrigere Ebene kann niemals wieder erlauben, was eine höhere Ebene verbietet.
Eine niedrigere Ebene kann niemals verbieten, was eine höhere Ebene verlangt — das Verbot wird ignoriert und das Plugin wird trotzdem geladen.

So kann ein Admin ein Plugin vorschreiben, das kein Repo und kein Nutzer abwählen kann, und ein Plugin verbieten, das keine niedrigere Ebene wieder zulassen kann.

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Da Allowlists keine Ebenen überschreiten, besteht die einzige Möglichkeit, eine Ausnahme von einer Denylist zu machen, darin, dies auf derselben Ebene zu tun, auf der sie festgelegt wurde. Das forbiddenPlugins einer Ebene wird nur durch die eigenen optionalPlugins (oder requiredPlugins) desselben Manifests überschrieben — niemals durch eine Liste auf einer niedrigeren Ebene. Zum Beispiel kann ein auf Enterprise-Ebene verwaltetes Manifest das Konto auf ein einziges genehmigtes Plugin beschränken:

// Verwaltetes Manifest auf Unternehmensebene
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Das bedeutet “im gesamten Konto nur acme/approved zuzulassen und jedes andere Plugin zu verbieten.” Keine Org, kein Repo und kein Nutzer kann diese Allowlist erweitern — weder durch die Installation eines Plugins noch durch das Hinzufügen zu den optionalPlugins einer niedrigeren Ebene. Diese Ausnahme gilt außerdem nur für die Einträge, die dieses Manifest direkt aufführt; die eigenen transitiven Abhängigkeiten eines erforderlichen Plugins sind nicht ausgenommen und müssen bei einem Lockdown daher ausdrücklich mit aufgeführt werden.

Konflikte und Abhängigkeiten

Ein Verbot und ein verbieten für dasselbe Plugin auf derselben Ebene, aber aus verschiedenen Manifesten (zum Beispiel zwei separat installierte Plugins auf Nutzer-Ebene), führen dazu, dass sich das Verbot durchsetzt — eine Allowlist nimmt nur Einträge im eigenen Manifest aus, sie kann also kein Plugin retten, das ein anderes Manifest verbietet. (Innerhalb eines einzelnen Manifests bleiben dessen eigene required/optional von dessen eigenen Verboten ausgenommen, wie oben.)
Ein durch Governance blockiertes Plugin scheitert weich: Zu Sitzungsbeginn werden seine Skills mit einer Warnung übersprungen, die nennt, wer das Verbot gesetzt hat, statt die Sitzung abzubrechen.
Eine Abhängigkeit von ihm gewährt keine Ausnahme. Ein Plugin, das nur als transitive Abhängigkeit eingebunden wird, unterliegt weiterhin jedem Verbot, das auf es zutrifft, und es übernimmt die höchste Autoritätsebene aller Plugins, die es voraussetzen.
Ein Pin-Konflikt — zwei Manifeste pinnen dasselbe Plugin auf unterschiedliche shas an — sollte aufgelöst werden, indem die Pins angeglichen werden oder das Anpinnen der Ebene mit der höheren Autorität überlassen wird.
Wenn ein verwaltetes Manifest zu Sitzungsbeginn nicht abgerufen werden kann, scheitert diese Ebene offen: Es wird nichts davon installiert und ihre Verbote werden für diese Sitzung nicht durchgesetzt.

Erste Schritte

Editor-Integrationen

Erweiterbarkeit

Enterprise

Referenz

Changelog

Kompatible Formate

Ein Plugin installieren

Plugins verwalten

Manifest

Metadaten

Skills & Regeln

MCP-Server

Abhängigkeiten

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Vererbung und Ebenen

Höhere Autorität setzt sich durch

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Konflikte und Abhängigkeiten

​Kompatible Formate

​Ein Plugin installieren

​Plugins verwalten

​Manifest

​Metadaten

​Skills & Regeln

​MCP-Server

​Abhängigkeiten

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Vererbung und Ebenen

​Höhere Autorität setzt sich durch

​Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

​Konflikte und Abhängigkeiten

Kompatible Formate

Ein Plugin installieren

Plugins verwalten

Manifest

Metadaten

Skills & Regeln

MCP-Server

Abhängigkeiten

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Vererbung und Ebenen

Höhere Autorität setzt sich durch

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Konflikte und Abhängigkeiten