Claude Code plugins, or Hubskillz
Claude Code installs plugins from a marketplace, a Git repo that declares a list of plugins. A plugin bundles skills, commands, subagents, hooks and MCP servers.
The plugin is the right format for shipping skills, commands, hooks and MCP servers as one block, and a Team or Enterprise organization can push its own marketplace. The version belongs to the bundle, auto-update applies the next one with nobody reading the diff, and nothing reports the real state of the machines. Take the plugin for one coherent internal tool. Take Hubskillz when each skill has to be approved and tracked on its own.
Last updated: August 30, 2026
At a glance
| Criterion | Claude Code plugins | Hubskillz |
|---|---|---|
| Unit shipped | A bundle: skills, commands, subagents, hooks, MCP | One skill at a time, with its history |
| Distribution | A Git marketplace. Personal scope, project scope in .claude/settings.json, or pushed by the organization | One directory per organization, laid on every machine by the CLI |
| Updates | Auto-update, per marketplace. Off, machines drift; on, the next version lands with no review | One version approved after review, applied by hubskillz sync |
| Approval before release | The pull request on the marketplace repo | Draft, diff and approval in the browser |
| Central view | An admin sets the marketplaces and the enabled plugins. The real state of the machines never comes back | State per machine and per project, reported by the CLI |
| Granularity | One version per bundle | One version per skill |
| Reach | Claude Code, including organization-pushed distribution | Claude Code through the CLI, claude.ai through a ZIP export |
| Locally edited skill | Untracked | Flagged as customized, never overwritten without --force |
What a plugin solves
The plugin is the right format for shipping a complete tool: the skill, the command that calls it, the hook that triggers it and the MCP server it depends on arrive together, in one install.
For a team that publishes an internal tool and evolves it slowly, a private marketplace does the job.
What the marketplace cannot tell you
A Team or Enterprise organization can push its own marketplace and pre-enable plugins, and a project can declare them in .claude/settings.json. What stays out of reach is the readback: nothing reports what the machines actually load, and “who is still on the previous version” has no answer inside the tool.
The version belongs to the bundle. Fixing one sentence in a skill bumps the number of every other one, and the diff a maintainer reviews mixes unrelated files.
Auto-update picks between two discomforts. Off, everyone updates when they think of it and the machines drift apart. On, the next version of a skill lands in the background, hands your agents new instructions, and nobody read the diff.
A locally tweaked skill exists for nobody except the person who tweaked it, who will watch their work disappear or block the update.
A plugin also installs into Claude Code. Colleagues working on claude.ai stay outside the whole scheme.
When plugins are enough
One coherent internal tool, maintained by one person, used by developers who live inside Claude Code: the plugin is the simplest answer, and it costs nothing.
The need changes as soon as skills evolve at their own pace, or compliance asks you to prove who runs which version.
Both together
Nothing forces a choice. The plugin keeps shipping the team’s commands, hooks and MCP servers. Hubskillz governs the skills: one approved version each, a state per machine, one command to bring everyone in line.
The CLI adopts the skills already sitting on a machine with hubskillz sync --adopt, so nothing has to be reinstalled during the move.
Frequently asked questions
Does Hubskillz replace commands and hooks?
No. The directory versions skills, meaning SKILL.md folders and their companion files. Commands, hooks and MCP servers keep shipping the way they do today, through a plugin or through the project repo.
Can we keep a private marketplace alongside?
Yes. The two write to different places, and the CLI simply reports a skill it does not know as unmanaged, without touching it.
Is a shared .claude/settings.json not enough for a team?
It aligns the configuration, which is already a lot: same marketplaces, same enabled plugins for whoever opens the repo. It does not report what each machine actually loaded, does not spot a locally edited copy, adds no review step before a new version of a skill applies, and only covers the people who open that repo in Claude Code.
Next steps
Other comparisons
- A Git repo of skills, or HubskillzVersion the skills in a repo, copy them onto each machine by hand.
- A skills.sh alternative, or a companionInstall public skills from a registry, one machine at a time.
- skills.sh vs Claude Code pluginsThe two ways to distribute skills without copying anything, compared against each other.
- Hubskillz alternatives