OpenPackage treats agent rules and skills as dependencies

A package manager for config, not for code

The scope is deliberately narrow, and the tagline says it plainly: the package manager for coding agent configs.

What it manages is the set of files that shape an agent's behaviour. Rules, slash commands, subagents, skills and MCP configurations, plus a platform root file and anything else a package chooses to carry. What it does not manage is application code, dependencies or builds.

The argument for it is that these files are powerful when set up properly and miserable when they are not. Modern AI coding tools behave well when rules, commands, subagents and skills are in place, and the complaint the project makes is organizational: the files are scattered and hard to keep track of. So the value being sold is install, uninstall and packaging with a single command, plus a record of where each file came from.

The comparison in the documentation is to Vercel Skills and Claude Code Plugins, described as the more universal and open-source version of both. The npm package is named opkg, and it publishes two binaries pointing at the same script: opkg and openpackage. Installing the tool and using it is two commands:

npm install -g opkg
opkg install <package-name>

Install targets are resolved per platform

One package, several conventions. An install takes the files from a resource, formats and converts them to the conventions of each target platform, and writes them into the directories that platform expects, relative to the current working directory.

That conversion is the feature that makes a shared package possible. The same rules file can land as a Cursor rule and as a Claude Code rule without you maintaining two copies, and a subagent definition can be installed into the layout whichever platform you are working in that day.

Two flags control where files go and where they are read from. The global flag installs to the home directory instead of the current workspace, which is the difference between a config that follows you and one that lives in a repository. The platforms flag restricts the install to named targets, with cursor, claudecode and opencode given as the examples, so you can install the same package into one platform and skip the rest.

Granularity is available too: separate flags select specific skills, agents, commands, rules or plugins by name, and an interactive flag lets you choose from a list instead of typing them.

Five ways to name a resource, one install command

The install command accepts several source syntaxes, which is what lets a package be shared from a registry, a repository, a subdirectory or a working copy.

A bare name resolves a package from the registry, and the documentation gives essentials as the worked example. The gh form takes an owner and repository, so a repository can be installed directly, with flags selecting just part of it such as plugins or agents. A full URL to a path inside a GitHub repository narrows that further to a subdirectory. A local path installs from a directory on disk, and that path may hold either a package or a Claude Plugin.

Git URLs are supported too, in HTTPS, SSH and ref-pinned forms, including hosts other than GitHub, so an internal GitLab mirror works the same way as a public repository.

Three resolution flags sit on top of that. Remote pulls from the remote registry and ignores local versions. Local resolves using only local registry versions. Dev adds the resource to dev-dependencies instead of the main set, which is the closest thing here to a lockfile discipline for agent configuration.

list separates tracked from untracked

Once files are installed, the question is what is actually present and what came from where. The list command answers both, at workspace level or per package.

Running it with no argument lists the resources installed into the workspace at the current directory. Running it with a package name lists the installed files belonging to that package. The options decide how much detail you get and which half of the tree you look at.

Tracked and untracked are separate filters. The tracked flag shows only tracked resources and skips the untracked scan entirely, which is the cheaper query when you know the answer is on disk. The untracked flag does the opposite. That distinction is the whole point of tracking file sources: it is how the tool tells a file it installed from a file a human added, and an install that overwrites the second kind is the failure mode worth avoiding.

The remaining options are presentation: a scope filter for project or global, a flat view that lists packages at the root without nesting, a files flag for individual paths, and a platforms filter.

A package is a manifest plus typed directories

Packages are created with a new command rather than assembled by hand, and the structure is fixed.

At the root of a package there is a manifest, openpackage.yml, which is required. Alongside it sit the ordinary repository files: README.md, LICENSE.md, CONTRIBUTING.md and anything else the package should carry. The new command takes a scope of root, project or global, defaulting to global, and a path that overrides the scope when you want the package somewhere specific.

The content is divided into directories by kind. Rules hold rule files, commands hold slash commands, agents hold subagents, and skills hold skills. Anything that does not fit goes into a root directory, which the documentation suggests using for things like specs, docs or tests. Two files sit at the top of the package rather than in a directory: AGENTS.md as the platform root file, and mcp.jsonc as the MCP configuration.

Two more commands edit a package after the fact. Add pulls files from the current directory into a package, either interactively or by naming a path such as a command file inside a platform directory. Remove takes files back out of a package. Uninstall is the third verb, and it removes every file belonging to a package from the workspace, with global and interactive variants.

Both of the package-editing commands name their target explicitly, which is what keeps an edit from landing in the wrong package:

opkg new <package>
opkg add .cursor/commands/clean.md --to <package>

Two workspaces, a schema directory, and tests on a ts-node loader

The published package is assembled from a monorepo with two workspaces, a core library and a CLI, and the manifest shows what actually ships.

Alongside the built JavaScript and its source maps, the published files include the two binaries, a platforms.jsonc file, a schemas directory and an assets directory, plus an examples directory. That matters for anyone extending it: the platform definitions and schemas are shipped to users rather than staying build-time only, so a custom target or a manifest change can be worked on outside the source tree.

The scripts are compact. A single build script builds both workspaces, a separate check runs the TypeScript compiler in no-emit mode over core and cli as a type check without emitting, publishing is gated on a build running first, and the test command runs a TypeScript test entry point through the ts-node ESM loader with transpile-only enabled.

The version in the manifest is 0.11.3, with 0.11.1, 0.11.2 and 0.11.3 all released between April and May 2026, and the last push to main is dated May 29, 2026. Documentation lives on the project site, with a Discord for questions.

Editorial conclusion

OpenPackage fits someone who has accumulated agent rules, subagents and skills across several repositories and platforms and wants to version them as one dependency rather than copy directories around. It does not fit anyone who has one hand-written config file, since the manifest and directory layout add structure that a single file does not need. Before you commit to a convention, read the install flags for remote versus local resolution and check the platform list your targets appear in, because that choice determines whether an install is reproducible on another machine.

Frequently asked questions

Official sources

1. enulus/OpenPackage on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases