By this point the book has taken the settings apart one by one: AGENTS.md, rules, skills, subagents, hooks, MCP. An agent plugin is a way to pack them into one installable bundle and hand it to a team or a community. The temptation is obvious: you found a ready-made plugin that "configures Devin the right way", installed it with one command - and got someone else's experience for free. Right here hides a question easy to skip past: you are installing not a list of conveniences but a chain of trust.
The naive reading equates a plugin with an editor extension: installed, tried, disliked, removed - zero risk. From it grows the habit of installing a plugin for one command that caught your eye, without looking at what else arrives with it. That habit breaks on the fact that an agent plugin is far more, by composition, than a set of commands, and part of its content starts acting at once and silently.
What exactly a plugin packs is worth knowing by name. Skills sit in the skills/ directory in the standard format and are invoked as slash commands of the form /plugin:skill. The AGENTS.md file works as an always-on rule in every session, while conditionally triggered rules live in the rules/ folder. Custom subagents are agents/<name>.md profiles, available as <plugin>:<name>. The hooks.json file registers lifecycle hooks that run in every session where the plugin is installed. And, finally, a plugin can carry MCP servers that start with the session. The last two lines are about executable code, not about convenience.
A plugin installs whole and from various sources: by the short GitHub name owner/repo, by a git URL, from a subfolder of a repository (git-subdir), or from a local folder. The manifest essentially requires only a unique name, but it also supports declaring dependencies - requiredPlugins, optionalPlugins and forbiddenPlugins - meaning one plugin can pull others along. That is convenient and at the same time widens the very chain: you trust not only this bundle but everything it declares as its dependencies.
The feature is in closed beta, and it has a subtlety about the install scope that matters in practice. Plugins install at the user level and are available across all of your projects. In stable 3.7.16, installing through the Customizations panel by default puts a plugin into personal plugins - so it is available both in the Cloud and on your other devices; a separate Install locally option limits it to the current machine. The difference is not cosmetic: a personal plugin extends its trust surface to the cloud and to all of your sessions at once, while a local one stays with a single machine.
There is one more boundary tied to the cloud that the documentation draws directly. A plugin's custom subagents load only in local agents - the CLI and Devin Desktop - and do not come up in cloud Devin sessions. Command hooks in the cloud run on the session's machine and only work while it is up. So the same plugin gives a different set of capabilities depending on the surface, and "the plugin is installed" does not equal "everything from the plugin works here".
Why this deserves to be treated as a question of trust rather than convenience. A plugin is at once a supply-chain link (code from someone else's repository), a set of always-on instructions (AGENTS.md and rules act without your renewed consent), and executable hooks (code that stands on the path of tool calls). Each of the three parts already calls for caution on its own; together they mean that installing a plugin is delegating to someone else's author the right to influence the agent's behavior and to run code in your sessions. The cost of a mistake here is not an "inconvenient command" but a silent change in what the agent does by default.
Hence the practice of review before installation, not after. Pin the source and the version so you do not drift after someone's update unnoticed. Read the manifest and the dependency list - what exactly arrives and what gets pulled along. Study what the plugin puts into AGENTS.md and rules, because that will start acting in every session. Look at hooks.json as executable code and at MCP servers as external endpoints with their permissions and data. This is the same audit as for a single setting, only multiplied by the number of the bundle's components.
You verify the result of an installation not by the fact that "it installed" but by the fact that "I can see what exactly loaded". After installing, open the Customizations panel and confirm which rules, skills, subagents, hooks and MCP servers the plugin brought and whether they are active on the surface you need. Match the pinned version against the source. If a plugin's subagent "did not appear" in the cloud, that is documented behavior, not a breakage. One such check separates the actually working set from the list of promises in the plugin's README.
The typical failures are predictable and almost all a consequence of skipped review. A plugin is installed for one command, and along with it comes an always-on rule that quietly rewrites the agent's way of working. The source is not pinned - and someone else's release changes behavior unasked. Personal instead of Install locally is chosen thoughtlessly - and the hooks and MCP extend to the cloud and all devices. A plugin's subagent is sought in a cloud session, where it does not load by definition. The sign in every case is the same: the bundle was installed before what is in it and how far it reaches were read. The manifest, the source and the composition first - then the installation.