Skip to main content
Create Droid plugins to package skills, commands, hooks, and MCP configuration into shareable bundles for teams and projects.

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 the skills/ directory:

Skill format

Skill frontmatter

Adding commands

Commands are user-invoked via slash syntax. Create them in the commands/ directory:

Command format

A command at commands/review-pr.md becomes /review-pr.

Command arguments

Use $ARGUMENTS to capture user input:
Usage: /greet Alice

Adding agents

Define specialized subagents in the droids/ directory:

Agent format

See Custom Droids for full agent configuration options.

Adding hooks

Define lifecycle hooks in hooks/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 in mcp.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 name and description in 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’s source 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 the version 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.
Pin to a specific version or range:
Install from a private registry:
Authenticate with a private registry that requires a token (for example JFrog Artifactory, AWS CodeArtifact, or GitHub Packages):
Users must set the named environment variable before launching Droid:
Never commit tokens to source control or paste them into marketplace JSON. The authTokenEnvVar field stores only the variable name, not the secret itself.
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:
Set the files field in package.json so only the plugin payload ships:
Hardening. Droid runs 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 small marketplace.json to any folder. The folder name becomes the marketplace name.
Teammates add it like any other local marketplace:

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

Design plugins around a single purpose or workflow. Prefer several small plugins over one monolithic plugin that does everything.
Include a README with:
  • What the plugin does
  • Installation instructions
  • All available commands and their usage
  • Configuration options
  • Examples
Follow semver conventions so users know when updates might break their workflows.
Ensure your plugin works on macOS, Linux, and Windows if applicable. Use portable shell commands and avoid platform-specific paths.
Scripts should fail gracefully without blocking the user. Log errors but don’t crash sessions.
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.