Plugins

Plugins are the canonical extension unit in matic — org-scoped bundles that add tools, routines, channels, signal types, and CLI commands without modifying core. Third-party plugins load in isolated subprocesses so a misbehaving extension cannot destabilize the daemon or leak into another org, while first-party plugins ship in-tree and share the same manifest contract. This section covers the manifest format, the load path, the lifecycle a plugin participates in, and the first-party set that matic installs by default.

Manifest Schema

The YAML contract every plugin declares — capabilities, permissions, entrypoint, and the signal types it registers.

Loader and Registry

How the daemon discovers plugins at bootstrap and populates the per-org PluginRegistry that scopes admission and lookup.

Plugin Lifecycle

The install → load → register → activate → teardown sequence and the hooks a plugin can opt into at each stage.

Subprocess Isolation

The stdio protocol, resource limits, and fault boundary that keep third-party plugin code from crashing the daemon.

Custom Plugin Guide

A walkthrough for authoring, packaging, and installing your own plugin against the matic plugin interface.

First-Party Plugins

The plugins matic ships and maintains — approval gates, archetype sync, cost sentinel, git hooks, signal relay, and the Slack notifier.