Foundation for Bamboo's local plugin system.
A plugin is a locally-installed bundle that can provide any of:
skills, MCP servers, prompt presets, and (future) workflows. It is
installed to ~/.bamboo/plugins/<id>/ (see
bamboo_config::paths::plugin_dir), keeping the plugin's own files
together (manifest, skills, prompts, workflows, optional per-platform
binaries), then REGISTERED into Bamboo's existing capability locations:
| Capability | Registered into | Discovery model |
|---|---|---|
| MCP servers | config.json (Config.mcp) + mcp_manager.start_server |
copied into shared config |
| Skills | N/A — discovered in place | ~/.bamboo/plugins/*/skills is an additional SkillDiscoveryDir (see bamboo-skills) |
| Prompt presets | prompt-presets.json |
copied into shared store |
| Workflows | ~/.bamboo/workflows/*.md |
copied into shared dir (no discovery-dir mechanism exists yet) |
This crate defines the shared skeleton three things build on:
- [
manifest::PluginManifest] — theplugin.jsonschema, with validation and the${plugin_dir}/${platform_bin}token-substitution contract for MCP stdio commands (see themanifestmodule docs for the full contract). - [
registry::InstalledPlugins] — the~/.bamboo/plugins/installed.jsonprovenance registry (load/save/add/remove), recording exactly what each plugin registered so uninstall/upgrade is precise. - [
installer::PluginInstaller] — the trait later agents implement to actually wire capability registration (that wiring needsAppState, which thisinfra-layer crate intentionally does not depend on).
See the repo-root PLUGIN_PLAN.md (temporary, deleted before final merge)
for how the remaining work is split across parallel agents, and
examples/hello-plugin/ for a minimal end-to-end reference plugin
(one skill + one prompt preset, no binary, no MCP server).