OpenPackage (opkg): a package manager for coding agent configs
The open, universal, coding agent skills, agents, rules, and commands organizer and package manager.
At a glance
- What is it?
- OpenPackage installs rules, commands, agents, skills and MCPs from packages, GitHub repos or local paths into a codebase, converting them per platform. It is useful if you juggle several AI coding tools; the README is thinner on versioning and rollback than on install.
- Who is it for?
- OpenPackage suits engineers who keep the same rules, agents and skills in more than one AI coding tool and want a single install and uninstall path instead of copying files by hand. It is the wrong tool if you only use one platform and edit its config files directly, or if you need a documented rollback story before adopting.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 110 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenPackage solves for people running several coding agents
AI coding tools each store their own configuration: rules, slash commands, subagents, skills, and MCP server definitions. The formats differ, the directories differ, and nothing keeps them in sync when you work across two or three editors. OpenPackage, published on npm as opkg, is a CLI that installs those files into the right per-platform locations and converts them to the conventions each platform expects. The README frames the problem directly: these files "remain difficult to organize and manage."
The intended user is an engineer who already has agent configs worth reusing. The README lists four use cases: installing agents, skills and Claude plugins to any coding platform; syncing rules, commands, agents, skills and MCPs across platforms; reusing files across multiple codebases; and modular install and uninstall of configs. If you configure one editor and never switch, the value proposition is weaker, because the tool's main job is translation and placement across targets.
How opkg resolves a resource and where it writes files
The README describes OpenPackage as "a lightweight CLI package manager that performs installs and uninstalls of config files," with tracking of file sources and dependencies plus packaging. An install takes a resource reference, resolves it, and writes the files into the current working directory, "formatted and converted to per platform conventions and into their respective dirs." The repository is a TypeScript monorepo: package.json declares workspaces under packages/*, with packages/cli and packages/core as the two build targets, and the bin entry maps both opkg and openpackage to ./bin/openpackage.
Resolution is broader than a registry. The README's examples cover OpenPackage local or remote packages, GitHub repos via gh@<owner>/<repo>, GitHub URLs pointing at a path inside a repo, local directories including Claude plugins, and plain Git URLs over HTTPS, SSH or .git#ref. Platform targeting is a flag: --platforms accepts values such as cursor, claudecode and opencode. A platforms.jsonc file ships at the root of the published package, which is where the platform conventions the CLI applies are likely defined, though the README does not document its schema. Dependency bookkeeping exists in the sense that packages declare files in an openpackage.yml manifest, and --dev adds a resource to dev-dependencies.
Installing opkg and installing your first skill
The README gives one install path: a global npm install. Node and npm must already be present, since the package ships a bin script rather than a standalone binary.
npm install -g opkgAfter that, opkg is on your PATH. The quick start installs a resource into the codebase at the current working directory:
opkg install gh@vercel-labs/agent-skills --skills react-best-practicesThis pulls the named skill from that GitHub repository and writes it into the platform directories for the workspace. To confirm what landed, list installed resources:
opkg list
opkg list <package> --filesThe first form lists resources installed to the workspace at cwd; the second shows individual file paths for a named resource. If you want the files in your home directory instead of the project, add -g, and use --platforms to restrict the target set:
opkg install essentials -g --platforms cursor claudecodeRemoval follows the same shape: opkg uninstall <package> removes all files for a package from the codebase at cwd, with -g and -i (interactive selection) as the documented options.
Composing your own package with opkg new
Installing other people's configs is half the tool. The other half is packaging your own so a team can pull them. opkg new <package> scaffolds a package directory, with --scope root, project or global (the README says global is the default) and --path to override the location entirely. The README then shows the structure you fill in by hand, starting with an openpackage.yml manifest at the package root, followed by the files themselves.
The design is deliberately plain: a manifest plus files, no build step described. That makes packages reviewable in a pull request, which matters when the contents are instructions an agent will follow. It also means package quality depends entirely on what the author put in the manifest; the README does not describe validation rules for it, so a malformed or incomplete openpackage.yml is a risk you carry until the CLI rejects it.
Where OpenPackage is the wrong tool
The README is explicit that the CLI installs and uninstalls files and tracks sources and dependencies. It does not document a rollback command, a lockfile format, or version pinning for installed resources beyond --remote (ignore local registry versions) and --local (use only local registry versions). If your requirement is reproducible configs across machines at an exact revision, the README does not show how to express that, and you should treat it as unverified rather than assume a lockfile exists.
There is a second boundary. OpenPackage writes into directories owned by other tools. Uninstall removes "all files for a package", which is clean only if the tool wrote every file it is removing. A config file you edited by hand after installing is a case the README does not address. The untracked scan in opkg list (--tracked and --untracked) suggests the CLI distinguishes files it recorded from files it found, which is a hint that drift is expected, but the README does not say what happens to an edited file on uninstall. Test that on a scratch repository before running it against a workspace you care about.
How it differs from Vercel Skills and Claude Code plugins
The README positions OpenPackage as "a much more powerful, universal, and open source version of Vercel Skills and Claude Code Plugins." The concrete difference is scope of targets. Claude Code plugins are Claude Code's own distribution format; Vercel Skills serve their own ecosystem. OpenPackage installs from either of those sources and from generic GitHub repos, local paths and Git URLs, then resolves the install target per platform through --platforms and the platforms.jsonc shipped with the package.
That is a real difference in approach: the others are first-party distribution for one tool, while OpenPackage is a translation and placement layer across tools. The trade-off is that correctness depends on its platform mappings staying current with each editor's config format. The README does not describe how platforms.jsonc is updated or how quickly new platform conventions land, so if you depend on a niche platform, check that it is listed before committing to the workflow.
Editorial conclusion
OpenPackage suits engineers who keep the same rules, agents and skills in more than one AI coding tool and want a single install and uninstall path instead of copying files by hand. It is the wrong tool if you only use one platform and edit its config files directly, or if you need a documented rollback story before adopting. Verify first that your target platform appears in platforms.jsonc, that opkg list shows the install you just made, and that the package you pull declares its own files in openpackage.yml.
Frequently asked questions
How do you install OpenPackage?
Install it globally with npm install -g opkg, which puts the opkg command on your PATH. The README gives this as the only install method, so Node and npm need to be available first.
What is OpenPackage?
It is a TypeScript CLI package manager for coding agent configs: rules, commands, agents, skills and MCPs. It installs, uninstalls and packages those files, converting them to the conventions of each target platform.
Where does OpenPackage get skills from?
The README lists OpenPackage packages, GitHub repos via gh@<owner>/<repo>, GitHub URLs pointing at a path in a repo, local directories including Claude plugins, and Git URLs over HTTPS, SSH or .git#ref. A single install can be narrowed with --skills, --agents, --commands, --rules or --plugins.
Can OpenPackage install into the home directory instead of a project?
Yes. The -g, --global flag installs to the home directory rather than the current workspace, and opkg uninstall accepts the same flag. The --scope option on opkg new controls whether a package you create is root, project or global.
How do you see what OpenPackage installed?
Run opkg list for resources installed to the workspace at cwd, or opkg list <package> for the files of a specific resource. Adding --files shows individual file paths, and --tracked or --untracked filters to tracked or untracked resources.
Community notes