The /dr-plugin Command — Datarim Plugin System

Datarim ships with a fixed set of skills, agents, commands, and templates. The plugin system makes that set extensible without modifying the core installation. /dr-plugin is the CLI for managing those extensions.

All subcommands are implemented: list (which bootstraps the datarim-core entry on first run), enable, disable, sync, and doctor. Enabling a plugin from a git URL is the only path still deferred; today enable takes an absolute path.

Two-manifest architecture

Each plugin carries a static manifest — plugin-storage/<id>/plugin.yaml — committed alongside the plugin's source files in its own repository. That manifest describes what the plugin contains and requires. A second, runtime manifest lives in datarim/enabled-plugins.md inside the workspace and records which plugins are active for that project. The two layers are kept separate deliberately: the static manifest travels with the plugin; the runtime manifest belongs to the workspace.

Third-party plugins install as symlinks from datarim/plugin-storage/<id>/ into the project runtime, .datarim-runtime/local/{skills,agents,commands,templates}/<plugin-id>/; nothing is written under your home directory. The symlink approach means the plugin's source stays in one place and the runtime picks it up from the standard load path.

datarim-core on first run

Running /dr-plugin list for the first time bootstraps the datarim-core entry. The current Datarim shipping set — all skills, agents, commands, and templates installed alongside the framework — is registered as a single protected plugin. It cannot be disabled. This makes the boundary between core and third-party components explicit from the start.

The underlying implementation is a POSIX-friendly bash script at scripts/dr-plugin.sh, compatible with bash 3.2 and above. Plugin ID validation enforces kebab-case identifiers up to thirty-two characters. Source validation accepts absolute paths and HTTPS URLs; embedded credentials and path-traversal sequences are rejected.

Exit codes and environment overrides

Exit 0 means success. Exit 1 is a validation or conflict error. Exit 2 is an I/O or filesystem error. Exit 3 means a lock is held by a concurrent invocation. Exit 64 is a usage error from an unrecognized subcommand or missing argument.

Two environment variables allow test-time overrides: DR_PLUGIN_WORKSPACE points to an alternative workspace root, and DR_PLUGIN_RUNTIME_ROOT names the symlink target root, which defaults to ${DATARIM_RUNTIME}/local and must match the project runtime. The test suites (77+ cases plus four coverage gates) pass on macOS bash 3.2 and Linux bash 5.

Roadmap

Phases A3 through D are done: enable and disable with first-run inventory backfill for datarim-core, an overrides: mechanism with conflict pre-scanning, snapshot and rollback through sync, and doctor, which now runs ten diagnostic checks. Phase A4 — enabling a plugin straight from a git URL — remains deferred.

Read about extending the framework today with /dr-addskill, or see the broader context in what Datarim is.