The /dr-plugin Command — Datarim Plugin System
How /dr-plugin manages opt-in extensions for Datarim: the two-manifest architecture, datarim-core bootstrap, symlink-based installation, and the phased roadmap for enable/disable and rollback.
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.
The current phase covers listing active plugins and bootstrapping the datarim-core entry on first run. The enable, disable, sync, and doctor subcommands are implemented in subsequent phases.
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 ~/.claude/local/{skills,agents,commands,templates}/<plugin-id>/. 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 redirects the symlink target. The test suite covers twenty-eight cases across macOS bash 3.2 and Linux bash 5.
Roadmap
Phase A3 adds the enable and disable happy paths with first-run inventory backfill for datarim-core. Phase B introduces an overrides: mechanism with conflict pre-scanning. Phase C adds snapshot and rollback through sync. Phase D introduces doctor with eight diagnostic checks. Phase E brings the plugin system to the public surface — CLAUDE.md, README, and datarim.club documentation. Phase F adds an author guide and raises test coverage to eighty percent or above.
Read about extending the framework today with /dr-addskill, or see the broader context in what Datarim is.