Distribute as a plugin
When packaging your team's skills as a plugin is the better choice, and what you give up.
A Git repository is the simplest way to get skills to a team. Packaging them as a Claude Code plugin is the other option.
Choosing
| Your goal | Reach for |
|---|---|
| A shared folder of instructions the team edits and pulls | A Git repository |
| A published, versioned artifact for people outside the team | A plugin |
| Both | The repository first; publish it as a plugin once it has settled |
claude plugin marketplace add https://github.com/your-org/team-skills.git --sparse .claude-plugin plugins--sparse downloads only the folders it names, here the marketplace file and the plugins. Without it, every install downloads the whole repository, which gets slow once the repository holds more than its plugins. Name the folders your plugins read.
What a plugin costs
Plugin skills are read-only here, and getting one into a second tool forks it.
Every install destination offered for a plugin skill makes one real copy first, at the first location picked, and points the rest at that copy. That happens even when someone only wanted the skill in a second editor. The copy is shared across their tools normally, but it no longer follows the plugin's updates.
The reason is ownership: the plugin folder belongs to the harness, which replaces its files whenever the plugin updates. A link into it would break on the next update, and OpenKnowledge could neither version nor edit what it points at.
So anyone adapting a plugin skill, or spreading it across their tools, quietly leaves the channel you set up. With a repository they stay on it.
Authoring is the same either way: you open the repository as an OpenKnowledge project. The plugin adds distribution, not a place to edit.