Beyond the Basics
This guide covers advanced patterns for capability plugins beyond the basics in Creating Capabilities. These patterns handle real-world complexity: dependencies, long-running operations, state management, and multi-tool plugins.Plugin Dependencies
Add apackage.json next to your SKILL.md to declare npm dependencies. The cerebellum installs them lazily on first load:
Dependencies are installed with
npm install --production in the capability folder. The cerebellum runs this once and caches the result. Delete node_modules/ to force a reinstall.Skill Dependencies
Use therequires field in SKILL.md frontmatter to declare that your capability depends on other capabilities being loaded:
shell isn’t loaded, cerebellum logs a warning and skips your capability.
Long-Running Tools with Cancellation
Use thesignal (AbortSignal) from context to support cancellation. The motor cortex passes this when the user clicks Stop or a task timeout fires:
Background Processes
Plugins can spawn detached child processes for dev servers, watchers, or other long-running programs. Return the PID so the agent can reference it later:File I/O Patterns
Usecontext.workspaceRoot to read/write workspace files and context.pluginDir for plugin-local configuration:
Multi-Tool Plugins
A single plugin can export multiple tools. Route bytoolName in execute():
Error Handling
Always return aToolResult with success: false and an error message on failure. Never throw — the motor cortex catches exceptions but retries 3x, which wastes tokens if the error is deterministic:
The motor cortex retries failed tool calls up to 3 times with exponential backoff (2s, 6s, 18s). Return clear error messages so the LLM can adjust its approach on the next attempt.
Stateful Plugins
init() runs once on load, destroy() on shutdown. Store state in closures or module scope:
Tool Result Formatting
The output string is shown to the LLM for its next turn. Make it informative but concise — the LLM has limited context:Inter-Plugin Communication
Plugins cannot call other plugins directly. If your plugin needs another capability’s output, emit the need as part of your result and let the LLM orchestrate:file_read next. This keeps the architecture clean — the LLM is the orchestrator, plugins are tools.
Security Model
Plugins run with full Node.js access in the main Electron process. They can do anything: file system, network, child processes, native modules. The amygdala is the only gate — it decides whether the LLM is allowed to invoke a tool based on danger patterns.Testing Plugins
Two approaches for testing:- Isolated Testing
- Live Testing
Create a mock context and call
execute() directly: