Plugins

Plugins sind in der geschlossenen Beta. Um Zugang anzufordern, kontaktieren Sie support@cognition.ai. Verhalten und Konfiguration können sich in zukünftigen Releases ändern.

Ein Plugin ist ein Bündel von Skills, das Sie aus einem GitHub-Repo, einer Git-URL oder einem lokalen Ordner installieren und projektübergreifend wiederverwenden können. Beim Installieren eines Plugins werden seine Skills als /<plugin>:<skill>-Slash-Befehle verfügbar, und es kann automatisch andere Plugins einbinden, von denen es abhängt. Ein Plugin ist einfach eine Quelle, 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_config.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. Über Skills hinaus kann ein Plugin Folgendes mitliefern:

Regeln — eine AGENTS.md im Stammverzeichnis des Plugins 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 Stammverzeichnis des Plugins registriert Lifecycle-Hooks, die in jeder Sitzung ausgeführt werden, in der das Plugin installiert ist.
MCP-Server — eine mcp_config.json im Stammverzeichnis des Plugins deklariert MCP-Server ("mcpServers": { "<name>": { … } }), die mit der Sitzung starten. Die .mcp.json im Stammverzeichnis von Claude-Plugins und das mcpServers-Feld im Manifest werden ebenfalls berücksichtigt.

Ein Plugin installieren

Als Plugin-Quelle sind ein GitHub-owner/repo, eine Git-URL oder ein lokaler Pfad möglich:

# Von GitHub
devin plugins install acme/review-tools

# 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

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.

Plugins verwalten

# Installierte Plugins, ihre Versionen und ob welche durch eine Richtlinie blockiert sind, auflisten
devin plugins list

# Skills eines Plugins sowie seine Pflicht-/optionalen/verbotenen Listen 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 entfernen (automatisch installierte Pflicht-Plugins bleiben erhalten)
devin plugins remove review-tools

Lokale Plugins sind direkt mit ihrem Quellordner verknüpft, daher sind Änderungen sofort wirksam: devin plugins install ./my-plugin → skills/<name>/SKILL.md bearbeiten → Änderungen werden in der nächsten Sitzung übernommen, kein update erforderlich.

Das 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>:…).

{
  "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/*", "*"]
}

Unterstützte Metadatenfelder: name, version, description, author ({ name, email }), homepage, repository, license und keywords. Zwei weitere optionale Felder steuern, wo Assets geladen werden: skills — ein Pfad oder ein Array von Pfaden zu Skill-Verzeichnissen, das den Standard skills/ ersetzt — und mcpServers — Pfade zu MCP-Deklarationsdateien oder eine Inline-Serverzuordnung, die zusätzlich zu den Konventionen im Stammverzeichnis eingelesen wird. Ein Eintrag für eine Abhängigkeit ist eine Quelle – entweder eine Kurzschreibweise als String 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

Alle GitHub-Formen für dasselbe Repo (owner/repo, die HTTPS-URL, die .git-URL, die SSH-Form) verweisen auf dieselbe Plugin-Identität.

Abhängigkeiten und Governance

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 Admin konfiguriert wird.
Org — ein auf Organisationsebene verwaltetes Manifest, das unterhalb des zugehörigen Kontos liegt (eine Org kann ergänzen, was ihr Konto deklariert, es aber nicht außer Kraft setzen). Das gilt nur für Cloud-Devin-Sitzungen: Die CLI authentifiziert sich auf Kontoebene und hat keinen Org-Kontext, daher gelten Anforderungen und Verbote auf Organisationsebene nicht für CLI-Nutzer. Alles, was in der CLI erzwungen werden soll, muss im Enterprise-/Kontomanifest stehen.
Repo — die requiredPlugins / optionalPlugins / forbiddenPlugins in der .devin/config.json eines Checkouts, die ermittelt werden, indem vom Arbeitsverzeichnis aus nach oben traversiert wird.
User — Plugins, die Sie selbst mit devin plugins install installieren.

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 require und ein forbid 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 forbid 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 forbids ausgenommen, wie oben.)
Ein durch Governance blockiertes Plugin scheitert weich: Zu Sitzungsbeginn werden seine Skills mit einer Warnung übersprungen, die nennt, wer das forbid 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 forbid, das auf es zutrifft, und es übernimmt die höchste Autoritätsebene aller Plugins, die es voraussetzen.

Erste Schritte

Editor-Integrationen

Erweiterbarkeit

Enterprise

Referenz

Changelog

Ein Plugin installieren

Plugins verwalten

Das Manifest

Abhängigkeiten und Governance

`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

​Ein Plugin installieren

​Plugins verwalten

​Das Manifest

​Abhängigkeiten und Governance

​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

Ein Plugin installieren

Plugins verwalten

Das Manifest

Abhängigkeiten und Governance

`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