Skip to main content
プラグインはベータ版です。動作や設定は今後のリリースで変更される場合があります。
プラグインは、スキルをまとめたバンドルで、GitHub リポジトリ、git URL、またはローカルフォルダーからインストールし、複数のプロジェクトで再利用できます。プラグインをインストールすると、そのスキルを /<plugin>:<skill> スラッシュコマンドとして利用でき、依存する他のプラグインも自動的に取り込まれます。 プラグインとは、次の内容を含むソースのことです:
skills/ ディレクトリには通常のスキルが格納されます。プラグインによって新しいスキルの 形式が追加されることはありません。SKILL.md の形式については、Creating Skills を参照してください。 スキルに加えて、プラグインには次のものを含めることができます:
  • ルール — プラグインのルートにある AGENTS.md は、プロジェクト独自のルールとあわせて、すべてのセッションで常時適用 ルールとして読み込まれます。rules/ フォルダー内の Markdown ファイルも読み込まれ、 Windsurf rules と同じ trigger frontmatter と activation types を使用します。
  • カスタムサブエージェントagents/<name>.md または agents/<name>/AGENT.md プロファイル (プロジェクトの サブエージェントと同じ custom subagent format) で、 <plugin>:<name> として利用できます。現在、プラグインのサブエージェントが読み込まれるのはローカルの Devin エージェント のみ、つまり CLI と Devin Desktop で、cloud Devin セッションでは読み込まれません。
  • フック — プラグインのルートにある hooks.json は、 プラグインがインストールされているすべての セッションで実行される ライフサイクルフック を登録します。
  • MCPサーバー — プラグインのルートにある mcp_config.json は、 セッションの開始時に起動する MCPサーバー ("mcpServers": { "<name>": { … } }) を宣言します。Claude プラグインのルート .mcp.json とマニフェストの mcpServers フィールドも有効です。

プラグインのインストール

プラグインのソースには、GitHub の owner/repo、git URL、またはローカルパスを指定できます。
インストール前に、Devin はそのプラグインで追加される内容 (提供される スキル、自動的にインストールされる必要なプラグイン、追加されるポリシー (たとえば、他のプラグインを禁止するポリシーなど) ) を表示します。確認 プロンプトをスキップするには、-y / --yes を指定します。 プラグインは ユーザー レベルでインストールされ、すべての プロジェクトで利用できます。

プラグインの管理

ローカルプラグインはソースフォルダに直接リンクされているため、編集内容はすぐに反映されます: devin plugins install ./my-pluginskills/<name>/SKILL.md を編集 → 変更内容は 次のセッションで反映されるため、update は不要です。

マニフェスト

.devin-plugin/plugin.json はプラグインを定義します。必須なのは name のみで、 インストール済みプラグイン内で一意である必要があります (/<name>:… 名前空間になります) 。
サポートされるメタデータ フィールドは、nameversiondescriptionauthor ({ name, email }) 、homepagerepositorylicensekeywords です。 さらに 2 つのオプション フィールドで、アセットの読み込み元を制御できます。skills はスキル ディレクトリへのパスまたは パスの配列で、デフォルトの skills/ を置き換えます。mcpServers は MCP 宣言ファイルのパスまたはインラインのサーバー マップで、ルートの規約とあわせて 読み込まれます。 依存関係のエントリは ソース で、文字列の省略記法またはオブジェクトで指定します。 同じリポジトリを指すすべての GitHub 形式 (owner/repo、HTTPS URL、.git URL、SSH 形式) は、同じプラグインの識別子として扱われます。

依存関係とガバナンス

プラグインでは3つのリストを定義でき、これにより1つのプラグインを、他のプラグインを厳選して管理するコレクションとして機能させることができます。

requiredPlugins

プラグインのインストール時に、自動的に (再帰的に) インストールされます。必須プラグインがポリシーによってブロックされている場合、インストール全体が失敗し、部分的にインストールされることはありません。

optionalPlugins

このプラグインが許可するプラグインの許可リストです。これらが自動的にインストールされることはありません。このリストが意味を持つのは、禁止項目に対する例外としてのみです (以下を参照) 。

forbiddenPlugins

プラグイン ID と glob パターンの禁止リストです。 forbiddenPlugins の各エントリは、プラグインの識別子に対して照合されます。
  • 完全一致の識別子owner/repo または git URL 形式で記述します。同じリポジトリを指す GitHub の各形式 (owner/repo、HTTPS URL、.git URL、SSH 形式) は、いずれも同じ識別子として扱われます。
  • glob パターン* を含む任意のエントリです。*/ を含む任意の文字列に一致します。たとえば、acme/*acme の GitHub リポジトリすべてに一致し、*/secrets は任意のオーナー配下の secrets という名前のリポジトリに一致し、https://gitlab.com/acme/* はそのパス配下の任意のリポジトリに一致します。
  • 単独の "*"。これはそれ以外のすべてに一致します (完全なロックダウン) 。
これらのリストは、deny 優先で組み合わされます。
  • Deny wins. アクティブなマニフェストまたはインストール済みプラグインのいずれかで禁止されている場合、そのプラグインはブロックされます。何も禁止されていなければ、何もブロックされません。
  • Self-override. マニフェスト (またはプラグイン) 自身の requiredPluginsoptionalPlugins、およびプラグインの場合はそのプラグイン自身は、その自身の禁止リストの適用対象外です。したがって、"forbiddenPlugins": ["*"]"optionalPlugins": ["acme/approved"] を組み合わせると、「このマニフェストに列挙されたものだけを許可し、それ以外はすべて禁止する」という意味になります。この例外が適用されるのは、それらの直接のエントリだけであり、required plugin の推移的な依存関係には適用されません。ロックダウン時は、それらも明示的に列挙してください。
  • No cross-scope re-permitting. あるマニフェストまたはプラグインの許可リストで、別のマニフェストまたはプラグインが禁止したものを再び許可することはできません。"forbiddenPlugins": ["*"] によるロックダウンは、より低いスコープからは回避できません。
適用は次の 2 つの時点で行われます。
  • Install time — ブロックされたプラグイン (または required plugin の要件を満たせないプラグイン、あるいはインストール済みプラグインと名前が競合するプラグイン) のインストールは拒否されます。
  • Load time — プラグインがすでにインストールされた後でブロックされた場合でも、ディスク上には残りますが、そのスキルはセッション開始時にスキップされ、どの禁止元によるものかを示す警告が表示されます。
禁止対象の ID には、上記の owner/repo 形式や git URL 形式に加えて、ローカルパス (ローカルフォルダからインストールするプラグイン用) も指定できます。

継承とレベル

プラグインは1か所で宣言されるわけではありません。自身でインストールしたものに加えて、プラグインはリポジトリや組織の管理者によって 必須、推奨、または禁止にされることがあります。 それぞれのソースはレベルであり、レベルは権限の強さに従って 高いものから順に並びます。
  1. Enterprise — 管理者が設定する、アカウント全体で管理されるマニフェスト。
  2. Org — accountの下位に重ねられる、orgレベルの管理マニフェスト (orgは accountが宣言した内容に追加できますが、それを上書きすることはできません) 。これは cloud Devin セッションにのみ適用されます。CLIはaccountレベルで認証され、 orgの前提情報を持たないため、orgレベルの必須設定や禁止設定はCLI ユーザーには適用されません。CLIで必ず適用したいものは、enterprise/account マニフェストに記載してください。
  3. Repo — checkoutの.devin/config.json内にあるrequiredPlugins / optionalPlugins / forbiddenPluginsで、 作業ディレクトリから上位へたどって検出されます。
  4. Userdevin plugins installを使って自身でインストールするプラグイン。
どのレベルでも同じ3つのlistを宣言し、同一レベル内では 単一のマニフェストと同様に、同じdeny優先・自身による上書きルールで結合されます。 レベルによって追加されるルールは1つだけです。より高い権限が優先される ということです。

より高い権限が優先されます

  • 下位レベルでは、上位レベルで禁止されているものを再び許可することはできません。
  • 下位レベルでは、上位レベルで必須とされているものを禁止することはできません — その禁止は 無視され、プラグイン は引き続き読み込まれます。
したがって、管理者 は リポジトリ や user がオプトアウトできない プラグイン を必須にでき、また、 下位レベルでは再度有効にできない プラグイン を禁止できます。

denylist は定義されたレベルでのみ上書きできます

allowlist はレベルをまたいで適用されないため、denylist に例外を設ける唯一の方法は、 それを定義したのと同じレベルで設定することです。あるレベルの forbiddenPlugins は、 同じマニフェスト内の optionalPlugins (または requiredPlugins) によってのみ上書きでき、下位レベルのリストで上書きされることはありません。 たとえば、Enterprise レベルの管理対象マニフェストを使うと、アカウントで利用できる プラグインを承認済みの 1 つのみに制限できます。
これは、“アカウント全体で acme/approved のみを許可し、それ以外の すべてのプラグインを禁止する。“という意味です。org、リポジトリ、user のいずれも、この許可リストを 広げることはできません。プラグインをインストールしても、下位レベルの optionalPlugins に追加しても 同様です。 この例外は、このマニフェストに直接記載されているエントリにしか適用されません。必須 プラグイン自体の推移的依存関係は免除されないため、ロックダウン下ではそれらも 明示的に列挙してください。

競合と依存関係

  • 同じプラグインに対する require と 禁止する が同じレベルで、しかも 異なるマニフェスト (たとえば個別にインストールされた 2 つのユーザーレベル プラグイン) から指定されている場合は、禁止する が優先されます。許可リスト が除外できるのは そのマニフェスト自身 のエントリだけなので、別のマニフェストで 禁止する された プラグインを覆すことはできません。 (1 つのマニフェスト内では、そのマニフェスト自身の required / optional は、前述のとおり、そのマニフェスト自身の forbids の 対象外のままです。)
  • ガバナンスによってブロックされたプラグインは soft-fails します。セッション開始時に、その スキルは 禁止する を指定した主体を示す警告とともにスキップされ、セッションは中断されません。
  • 依存先であることによる除外はありません。推移的依存関係としてのみ取り込まれた プラグインであっても、それに適用されるすべての 禁止する の対象であり続け、さらにそれを require するプラグインのうち、最も高い権限レベルを継承します。