Plugins

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # The plugin manifest
├── AGENTS.md           # Optional always-on rule
├── rules/              # Optional triggered rules
├── agents/
│   └── reviewer.md     # Optional custom subagent (reviewer/AGENT.md also works)
├── hooks.json          # Optional lifecycle hooks
├── mcp_config.json     # Optional MCP servers
└── skills/
    └── review/
        └── SKILL.md    # An ordinary skill

• Rules — an AGENTS.md at the plugin root is injected as an always-on rule in every session, alongside your project’s own rules. Markdown files in a rules/ folder are loaded too, with the same trigger frontmatter and activation types as Windsurf rules.
• Custom subagents — agents/<name>.md or agents/<name>/AGENT.md profiles (the same custom subagent format as project subagents), available as <plugin>:<name>. Plugin subagents currently load in local Devin agents only — the CLI and Devin Desktop — not in cloud Devin sessions.
• Hooks — a hooks.json at the plugin root registers lifecycle hooks that run in every session where the plugin is installed.
• MCP servers — an mcp_config.json at the plugin root declares MCP servers ("mcpServers": { "<name>": { … } }) that start with the session. Claude plugins’ root .mcp.json and manifest mcpServers field are also honored.

​

Installing a plugin

# From GitHub
devin plugins install acme/review-tools

# From any git host
devin plugins install https://gitlab.com/acme/review-tools.git

# From a local folder (great for authoring)
devin plugins install ./my-plugin

​

Managing plugins

# List installed plugins, their versions, and whether any are blocked by policy
devin plugins list

# Show a plugin's skills and its required/optional/forbidden lists
devin plugins info review-tools

# Re-fetch a plugin (or all plugins) at the latest version
devin plugins update review-tools
devin plugins update

# Remove a plugin (auto-installed required plugins are left in place)
devin plugins remove review-tools

​

The manifest

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

​

Dependencies and governance

​

requiredPlugins

​

optionalPlugins

​

forbiddenPlugins

• An exact identity, written as owner/repo or a git URL. All GitHub forms of the same repo (owner/repo, the HTTPS URL, the .git URL, the SSH form) refer to the same identity.
• A glob pattern — any entry containing *. The * matches any sequence of characters, including /: acme/* matches all of acme’s GitHub repos, */secrets matches a repo named secrets under any owner, and https://gitlab.com/acme/* matches any repo under that path.
• The lone "*", which matches everything else (a full lockdown).

• Deny wins. A plugin is blocked if any active manifest or installed plugin forbids it. If nothing forbids anything, nothing is blocked.
• Self-override. A manifest’s (or plugin’s) own requiredPlugins and optionalPlugins — and, for a plugin, the plugin itself — are exempt from its own forbidden list, so "forbiddenPlugins": ["*"] plus "optionalPlugins": ["acme/approved"] means “allow only what this manifest lists; forbid everything else.” The carve-out covers only those direct entries, not a required plugin’s transitive dependencies — list those explicitly under a lockdown.
• No cross-scope re-permitting. One manifest’s or plugin’s allow-list cannot re-permit what another forbids. A "forbiddenPlugins": ["*"] lockdown can’t be defeated from a lower scope.

• Install time — installing a blocked plugin (or one whose required plugins can’t be satisfied, or whose name collides with an installed plugin) is refused.
• Load time — a plugin blocked after it’s already installed stays on disk, but its skills are skipped at session start with a warning naming the forbidder.

​

Inheritance and levels

1. Enterprise — the account-wide managed manifest, configured by an admin.
2. Org — an org-level managed manifest, layered below its account (an org can add to what its account declares, but can’t overrule it). This applies only to cloud Devin sessions: the CLI authenticates at the account level and has no org context, so org-level requires and forbids don’t reach CLI users. Put anything you need enforced in the CLI in the enterprise/account manifest.
3. Repo — the requiredPlugins / optionalPlugins / forbiddenPlugins in a checkout’s .devin/config.json, discovered by walking up from your working directory.
4. User — plugins you install yourself with devin plugins install.

​

Higher authority wins

• A lower level can never re-permit what a higher level forbids.
• A lower level can never forbid what a higher level requires — the forbid is ignored and the plugin still loads.

​

A denylist is only overridden at its own level

// Enterprise-level managed manifest
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

​

Conflicts and dependencies

• A require and a forbid for the same plugin at the same level but from different manifests (for example two separately installed user-level plugins) resolve to the forbid — an allow-list only exempts entries in its own manifest, so it can’t rescue a plugin another manifest forbids. (Within a single manifest, its own required/optional stay exempt from its own forbids, as above.)
• A plugin blocked by governance soft-fails: at session start its skills are skipped with a warning naming the forbidder, rather than aborting the session.
• Being depended upon grants no exemption. A plugin pulled in only as a transitive dependency is still subject to every forbid that applies to it, and it inherits the highest authority level of any plugin that requires it.