Build on it guides
Build on it
Plugins
Register a plugin manifest with tools and triggers that still go through governance.
Updated September 6, 2026 2 min read
A plugin is a tenant-scoped registration: tools, triggers, required capabilities, and optional MCP server URL. registerPlugin in src/lib/revenue-os/plugins.ts upserts the manifest, registers capabilities, and registers autonomy policies. Status starts at pending_review until a human approves it. Enabled and revoked are explicit later states.
This is different from a module. A module is compile-time JSON in extensions/ that turns a cluster of pages on and off. A plugin is runtime data for extra tools a workspace has accepted.
Manifest shape
Required: pluginKey, name, description. Optional: version, author, homepage, required capabilities, permissions, config schema, MCP server URL, tools, triggers.
Each tool declares toolName, label, description, input schema, impact (read, internal_write, external_action), whether confirmation is required, and an autonomy level (prohibited, always_ask, ask_until_trusted, standing_permission, autonomous).
What still applies
Plugin tools flow through the autonomy policy engine. Mutating tools still stage into action_queue. MCP tools discovered from an external server must be registered as plugin_tools before use; they do not bypass Accelerate governance. Isolate execution (QuickJS) is the host for untrusted plugin code, with measured bounds. A plugin does not get a raw database handle.
What not to do
Do not treat a plugin as a way to skip approval. Do not document a plugin as autonomous if its policy is always_ask. Do not load plugin code from the extensions/ JSON directory; that directory is data.
Document the plugin before release
Every plugin needs an operator guide covering setup, configuration, permissions,
costs, a worked example, disabling, recovery and verified limitations. Bundled
plugins keep plugins/<id>/README.md and a public docsUrl in their manifest.
npm run verify:extensions rejects missing guides and documentation links.
Runtime/MCP submissions supply the same documentation in their review packet;
the current runtime registry does not enforce a documentation field.
Follow the plugin documentation contract. A reviewer must follow the task against the current implementation; structural checks cannot establish that the guide is accurate. See the Collections guide for a business workspace and the Radar guide for its daily review workspace, source-backed relationship context, model budgets and current release limits.