Quick start
1
Create the plugin directory
2
Create the manifest
Create
my-plugin/.factory-plugin/plugin.json:3
Add a command
Create
my-plugin/commands/hello.md:4
Test your plugin
Install from local directory to test:Then run
/hello to test.Plugin manifest
The manifest file at.factory-plugin/plugin.json defines your plugin’s metadata:
Required fields
Optional fields
Adding skills
Skills are model-invoked capabilities. Create them in theskills/ directory:
Skill format
Skill frontmatter
Adding commands
Commands are user-invoked via slash syntax. Create them in thecommands/ directory:
Command format
commands/review-pr.md becomes /review-pr.
Command arguments
Use$ARGUMENTS to capture user input:
/greet Alice
Adding agents
Define specialized subagents in thedroids/ directory:
Agent format
Adding hooks
Define lifecycle hooks inhooks/hooks.json:
Hook configuration
Environment variables
Plugin hooks cannot be imported via
/hooks import. They only function within installed plugins where the plugin root path can be resolved.Adding MCP servers
Configure MCP servers inmcp.json at the plugin root:
Testing plugins
Local testing
Install from a local directory to test during development:Validation checklist
Before sharing your plugin:- Manifest has required fields (
name,description,version) - All skills have
nameanddescriptionin frontmatter - Commands work with and without arguments
- No hardcoded paths or machine-specific config
- README documents all commands and features
Distributing plugins
Creating a marketplace
A marketplace is a Git repository with a manifest listing available plugins:Marketplace manifest
Create.factory-plugin/marketplace.json:
Plugin sources
Each plugin entry’ssource field tells Droid where to fetch the plugin from. The default form, a relative path string like "./plugin-one", points at a directory inside the marketplace repository. For plugins that live elsewhere, use a source object.
Pinning behavior depends on the source type. Git-based sources (github, url, git-subdir) are pinned per-plugin via ref (branch or tag) or sha. Relative-path plugins are pinned by pinning the marketplace source they live in. npm plugins are pinned via the version field, which follows npm version resolution.
npm packages
Distribute plugins as npm packages when you already ship to a private registry (Artifactory, CodeArtifact, GitHub Packages, Verdaccio, and so on) and want to reuse that channel for your Droid plugins. Public packages on the npm registry work the same way. For npm sources, pinning and updates follow npm version resolution via theversion field; the git commit-hash guidance in Version management applies to git-based sources only.
Requires npm to be installed and available on PATH. The CLI surfaces a clear error if it is not.
Layout requirements. The published package root must contain a plugin manifest. Both the native Droid layout (
.factory-plugin/plugin.json, droids/, mcp.json) and the Claude Code layout (.claude-plugin/plugin.json, agents/, .mcp.json) are accepted. Claude Code layouts are translated into Droid form when the package is copied into the plugin cache.
A typical published package looks like this:
files field in package.json so only the plugin payload ships:
npm install in a per-plugin scratch directory with --ignore-scripts, --no-save, --no-audit, and --no-fund. Lifecycle scripts (postinstall, preinstall, and so on) are not executed, and your global npm configuration is not consulted or mutated. Because lifecycle scripts are skipped, packages that rely on a postinstall build step won’t ship usable contents. Publish prebuilt artifacts (run your build before npm publish) so the package contents under the files allowlist are ready to use as-is.
npm: is not a valid marketplace source. Droid only accepts npm as a per-plugin source inside a marketplace’s marketplace.json. To ship a single npm-published plugin to your team without standing up a full marketplace repo, publish a thin wrapper marketplace (see below).Wrapper marketplace for a single npm plugin
To distribute one npm-published plugin without a dedicated marketplace repo, commit a smallmarketplace.json to any folder. The folder name becomes the marketplace name.
Version management
Use semantic versioning in your plugin manifest for documentation purposes:- Major (1.0.0 → 2.0.0): Breaking changes
- Minor (1.0.0 → 1.1.0): New features, backward compatible
- Patch (1.0.0 → 1.0.1): Bug fixes
For git-based plugin sources (relative path,
github, url, git-subdir), Droid tracks plugin versions by Git commit hash, not semantic version. By default, updating a plugin fetches the latest commit from the marketplace. To pin a plugin to a specific version, pin the marketplace it lives in by setting ref (branch or tag) or sha (full commit SHA) on the marketplace source — see Pinning a marketplace to a ref or commit. For npm plugin sources, pinning follows npm version resolution via the per-plugin version field instead.Claude Code compatibility
Droid is fully compatible with Claude Code plugins. If you find a Claude Code plugin, you can install it directly and Droid will automatically translate the format.Best practices
Keep plugins focused
Keep plugins focused
Design plugins around a single purpose or workflow. Prefer several small plugins over one monolithic plugin that does everything.
Document thoroughly
Document thoroughly
Include a README with:
- What the plugin does
- Installation instructions
- All available commands and their usage
- Configuration options
- Examples
Use semantic versioning
Use semantic versioning
Follow semver conventions so users know when updates might break their workflows.
Test across environments
Test across environments
Ensure your plugin works on macOS, Linux, and Windows if applicable. Use portable shell commands and avoid platform-specific paths.
Handle errors gracefully
Handle errors gracefully
Scripts should fail gracefully without blocking the user. Log errors but don’t crash sessions.
Respect user privacy
Respect user privacy
Don’t collect telemetry or send data without explicit consent. Document any network requests your plugin makes.
Example: Complete plugin
Here’s a complete example of a code review plugin:.factory-plugin/plugin.json:
commands/review.md:
skills/review-patterns/SKILL.md:
droids/reviewer.md:
Next steps
Plugins overview
Learn about installing and managing plugins.
Skills
Deep dive into creating powerful skills.
Custom commands
Create user-invoked slash commands.
Custom Droids
Create specialized subagents for your plugins.
