> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Plugin marketplace

> Install and require bundles of skills for everyone in your org or enterprise from the Devin web app

<Note>
  Plugins are in **closed beta**. To request access, contact [support@cognition.ai](mailto:support@cognition.ai). Behavior and configuration may change in future releases.
</Note>

## What are plugins?

A **plugin** is a bundle of [skills](/product-guides/skills) — and optionally rules, hooks, and MCP servers — packaged together so it can be installed and reused as a unit. Where a skill lives in a single repo, a plugin is a portable source (a GitHub repo, a git URL, a subfolder of a repo, or an uploaded `.zip`) that you can require across your whole org or enterprise.

**Managed plugins** let an admin install plugins centrally, from the Devin web app, so they apply to **everyone in the org or enterprise** — no per-user setup. This covers cloud Devin sessions **and** [Devin CLI](/cli/index) users logged into the account (enterprise/account-level config reaches the CLI too — see [cloud sessions vs. the CLI](#cloud-sessions-vs-the-cli)). When a plugin is installed, its skills become available to Devin automatically as `/<plugin>:<skill>` commands.

This page covers the cloud (web app) side of plugins. For the plugin file format and the CLI's per-user install flow, see the [CLI plugins reference](/cli/extensibility/plugins/overview).

## Where to configure them

Go to [**Settings → Marketplace**](https://app.devin.ai/settings/marketplace). The page has two tabs:

* **Marketplace** — browse plugins (the Devin official catalog plus any your org or enterprise has added) and install them. Installing a plugin **adds it to the manifest of the chosen scope as a required plugin**, so it's installed for everyone in that scope.
* [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) — edit the raw plugin **manifest** as JSON, and upload your own plugin as a folder or `.zip` (or build one in the editor).

Access is permission-gated:

* **Org admins** (organization settings access) manage the **org** manifest.
* **Enterprise admins** (enterprise settings access) additionally manage the shared **enterprise** manifest.

## The manifest

The manifest is a single JSON document with three lists:

```jsonc theme={null}
{
  "requiredPlugins": [
    // GitHub owner/repo
    "acme/review-tools",

    // any git URL
    "https://gitlab.com/acme/secure-base.git",

    // object form
    { "source": "github", "repo": "acme/audit-logging" },

    // a plugin living in a subfolder
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}
```

* **`requiredPlugins`** — installed for everyone in scope (recursively, including any plugins they depend on).
* **`optionalPlugins`** — an allow-list that endorses plugins without auto-installing them; used to carve out exceptions to a forbidden entry.
* **`forbiddenPlugins`** — a deny-list of plugin identities or glob patterns (e.g. `acme/*`, or `"*"` for a full lockdown).

Each entry in `requiredPlugins` / `optionalPlugins` is a **source** — either a string shorthand or an object:

| Form                                                               | Meaning                                         |
| ------------------------------------------------------------------ | ----------------------------------------------- |
| `"owner/repo"`                                                     | GitHub repository                               |
| `"https://…"`, `"git@…"`, `"ssh://…"`                              | any git URL                                     |
| `{ "source": "github", "repo": "owner/repo" }`                     | GitHub, object form                             |
| `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }` | git URL, object form                            |
| `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`        | a plugin living in a subfolder of a shared repo |

All GitHub forms for the same repo (`owner/repo`, the HTTPS URL, the `.git` URL, the SSH form) refer to the same plugin identity.

The manifest is stored verbatim; the agent validates the full source at install time.

### Governance rules

`forbiddenPlugins` entries are matched against plugin identities:

* 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).

The lists combine deny-wins:

* **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.

Enforcement happens at two points:

* **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.

On top of these rules, managed manifests are **tiered** — **enterprise/account** above **org** above repo- and user-level plugin config. Higher authority wins: a lower tier can never forbid a plugin a higher tier requires, and can never re-permit one a higher tier forbids. So an org forbid can't block an enterprise-required plugin, but an enterprise forbid overrides an org require.

## Adding your own plugins

A plugin is just a directory containing a `.devin-plugin/plugin.json` manifest and a `skills/` folder of ordinary [skills](/product-guides/skills):

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, and optional dependency lists
├── AGENTS.md           # optional always-on rule
├── rules/              # optional triggered rules
├── hooks.json          # optional lifecycle hooks
├── mcp_config.json     # optional MCP servers
└── skills/
    └── review/
        └── SKILL.md    # an ordinary skill
```

Beyond skills, a plugin can ship:

* **Rules** — an `AGENTS.md` at the plugin root is injected as an always-on rule in every session — in cloud sessions and the CLI alike. Markdown files in a `rules/` folder are loaded too, honoring their `trigger` frontmatter — see the [CLI plugins reference](/cli/extensibility/plugins/overview).
* **Hooks** — a `hooks.json` at the plugin root registers [lifecycle hooks](/cli/extensibility/hooks/lifecycle-hooks) that run in the session. Cloud sessions run `command` hooks for every event except `SessionStart` and `SessionEnd` — so `PreToolUse`, `PostToolUse`, `PermissionRequest`, `UserPromptSubmit`, `Stop`, and `PostCompaction` all work; `prompt`-type hooks are CLI/local-only.
* **MCP servers** — an `mcp_config.json` at the plugin root declares [MCP](/work-with-devin/mcp) servers (`"mcpServers": { "<name>": { … } }`) that load in every session where the plugin is installed. They don't yet appear in the MCP settings UI, but their tools are available to Devin. A plugin's MCP config may set an OAuth client ID and scopes, but never an OAuth client secret — a server config carrying one is rejected at activation.
* **Custom subagents** — `agents/<name>.md` (or `agents/<name>/AGENT.md`) profiles. These currently load only in local Devin agents — the [Devin CLI](/cli/extensibility/plugins/overview) and Devin Desktop — not in cloud sessions.

The **plugin is the unit of installation**: installing it installs all of its skills (plus anything in its `requiredPlugins`) — you can't install individual skills from a plugin. To offer skills separately, split them into separate plugins. See the [CLI plugins reference](/cli/extensibility/plugins/overview) for the full `plugin.json` format and local authoring flow.

Depending on where the plugin lives, add it in one of these ways:

| Where it lives                                       | How to add it                                                                                                   |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Public git repo**                                  | Add `"owner/repo"` (or the git URL) to the manifest, or install from the Marketplace tab if it's in the catalog |
| **Private git repo**                                 | Same manifest entry — see [using a private skills repo](#using-a-private-skills-repo) for how auth works        |
| **Subfolder of a repo** (e.g. a monorepo of plugins) | `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` — each subfolder is its own plugin                  |
| **Not in a repo at all**                             | Upload it as a bundle (below)                                                                                   |

One repo (or one `git-subdir` subfolder) is one plugin. A single repo can host many plugins as subfolders, each referenced with its own `git-subdir` entry.

### Uploading a plugin bundle

On the [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) tab, the **Uploaded plugin** section lets you upload a plugin as a folder or `.zip`, or build one directly in the editor. Saving it adds it to the manifest as a required plugin (installing it for everyone in scope); deleting it removes the reference. This is a good option for a plugin you don't want to (or can't) host in a git repo.

### Using a private skills repo

Point the manifest straight at the private repo — you generally don't need to bake it into your [environment snapshot](/onboard-devin/environment/blueprints). Any private repo Devin can already reach through your Git integration installs automatically. Use the git URL form, or `git-subdir` to install a plugin from a subfolder of a shared repo. (CLI users covered by the same manifest fetch with their own local git credentials, so they'll need access to the repo too.)

If the repo isn't reachable through your Git integration, either **upload it as a bundle** (above) or clone it during environment setup and reference it with a local path.

## How updates roll out

* **Manifest changes** (Settings → Marketplace) apply to the **next session**.
* **Plugin changes** — merging to the branch a plugin tracks reaches new sessions automatically, within a few hours. Pin the plugin to a commit SHA to control updates yourself; on the CLI, `devin plugins update` refreshes immediately.
* Running sessions keep what they loaded at start — updates never change a session mid-flight.

## Compatibility

Claude plugins work too: if there's no `.devin-plugin/plugin.json`, Devin falls back to a `.claude-plugin/plugin.json`. When both manifests are present, the Devin one wins.

## Scope and inheritance

Managed manifests exist at up to two levels:

* **Standalone accounts** have a single **account** manifest that applies to everyone.
* **Enterprises** have a shared **enterprise** manifest that is **inherited by every child org**, plus a per-**org** manifest layered below it. The Marketplace view shows both, and enterprise admins can choose to install a plugin at the enterprise scope (applies everywhere) or an org admin can install it at just their org.

These sit at the top of the overall plugin hierarchy, above any per-repo or per-user plugin configuration:

1. **Enterprise / account** manifest (this page)
2. **Org** manifest (this page)
3. **Repo**-level plugin config (a repo's `.devin/config.json`)
4. **User**-level plugins — a person's own [CLI](/cli/extensibility/plugins/overview) installs, which apply only to their local Devin agent and never load in cloud sessions

Higher authority wins: a lower level can never permit a plugin a higher level forbids, or forbid one a higher level requires (see [governance rules](#governance-rules)).

### Cloud sessions vs. the CLI

Both cloud Devin sessions and the [Devin CLI](/cli/index) enforce the **enterprise/account** manifest — required plugins are installed and forbids are enforced for CLI users logged into the account too.

The **org** manifest applies only to **cloud 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 (or account-wide) in the enterprise/account manifest, and use the org manifest for org-specific additions to cloud sessions.

## Learn more

* [Skills](/product-guides/skills) — the `SKILL.md` procedures that plugins bundle
* [CLI plugins reference](/cli/extensibility/plugins/overview) — plugin file format, authoring, and per-user install
* [Playbooks](/product-guides/creating-playbooks) — reusable prompt templates attached to sessions