Proposal: Set up as a Claude Code plugin marketplace

[dannon]

Proposal: Set up galaxy-skills as a Claude Code plugin marketplace

Motivation

Users currently install galaxy-skills by cloning into ~/.claude/skills/. Claude Code's plugin system offers a cleaner path — /plugin marketplace add galaxyproject/skills followed by /plugin install <name> — with versioning, auto-updates, and scoped installation (user-wide vs per-project). As the skill collection grows, this becomes increasingly useful.

The separate galaxyproject/claude-galaxy-plugins repo already serves as a marketplace for Galaxy core developer plugins (architecture review commands, etc.). These repos serve different audiences — galaxy-skills targets tool authors, workflow builders, and bioinformaticians — so they should be independent marketplaces.

The constraint

The plugin system discovers skills at skills/<name>/SKILL.md within a plugin root (or at a custom path). This matters because our current layout puts skills at the repo root:

galaxy-skills/
├── tool-dev/SKILL.md
├── nf-to-galaxy/SKILL.md
├── galaxy-integration/SKILL.md
├── collection-manipulation/SKILL.md
└── hub-news-posts/SKILL.md

For a single all-in-one plugin, setting "skills": "." in plugin.json works — the system finds tool-dev/SKILL.md, nf-to-galaxy/SKILL.md, etc. at the root. But if we want individual skill installation (just tool-dev, or just nf-to-galaxy), each skill family needs to be its own self-contained plugin, and each plugin needs the skills/<name>/SKILL.md nesting internally.

Users install individual plugins from a marketplace — they pick what they want, not everything. So the question is really about how granular we want installation to be, and whether the directory restructuring is worth it.

Options

Option A: Single plugin, all skills bundled

Minimal change. The repo is one plugin, the marketplace has one entry. Users install everything or nothing.

galaxy-skills/
├── .claude-plugin/
│   ├── plugin.json           # "skills": "."
│   └── marketplace.json      # one entry: "galaxy-skills"
├── tool-dev/SKILL.md
├── nf-to-galaxy/SKILL.md
└── ...

Install: /plugin install galaxy-skills@galaxy-skills

Pros:

• Minimal change from current structure
• No cross-reference issues (tool-dev/references/ is used by other skills)
• Simple to maintain

Cons:

• All or nothing — someone who just wants tool-dev gets everything
• As the collection grows, this becomes increasingly wasteful

Option B: Individual plugins, restructure now

Each skill family becomes its own plugin within the marketplace. Requires moving content into skills/<name>/ subdirectories within each top-level directory.

galaxy-skills/
├── .claude-plugin/
│   └── marketplace.json      # lists all plugins individually
├── tool-dev/
│   ├── .claude-plugin/plugin.json
│   └── skills/
│       └── tool-dev/
│           ├── SKILL.md
│           └── references/
├── nf-to-galaxy/
│   ├── .claude-plugin/plugin.json
│   └── skills/
│       └── nf-to-galaxy/
│           ├── SKILL.md
│           └── nf-process-to-galaxy-tool/
│           └── ...
└── ...

Install: /plugin install tool-dev@galaxy-skills

Pros:

• Granular installation from day one
• Each plugin is self-contained and independently versioned
• Right long-term structure

Cons:

• Significant restructure — every skill moves down a level
• Deeper nesting (tool-dev/skills/tool-dev/SKILL.md)
• Cross-reference problem: tool-dev/references/ is used by nf-to-galaxy — with separate plugins, those references wouldn't be available unless duplicated
• Breaks existing installations for anyone currently cloning into ~/.claude/skills/

Option C: Move skills under skills/, single plugin, split later

Restructure the repo so skills live at skills/<name>/SKILL.md (matching the plugin system's default discovery path), but keep it as a single plugin for now. This gets the directory layout right without the full complexity of individual plugins.

galaxy-skills/
├── .claude-plugin/
│   ├── plugin.json           # default discovery (skills/)
│   └── marketplace.json
├── skills/
│   ├── tool-dev/
│   │   ├── SKILL.md
│   │   └── references/
│   ├── nf-to-galaxy/
│   │   ├── SKILL.md
│   │   └── ...
│   └── ...
├── AGENTS.md
├── CONTRIBUTING.md
└── README.md

Install: /plugin install galaxy-skills@galaxy-skills (all skills)

Pros:

• Matches the plugin system's default layout (no custom "skills" path needed)
• Splitting into individual plugins later requires less restructuring — the skills/<name>/ nesting is already in place
• Cleaner separation between skill content and repo metadata

Cons:

• Still all-or-nothing for now
• Moderate restructure (moving directories, updating internal cross-references and AGENTS.md)
• Breaks existing clone-based installations

Option D: Keep current structure, add plugin config only, restructure later

Same as Option A but explicitly framed as a stepping stone. Add the minimal plugin.json and marketplace.json now so the repo is installable via the plugin system, defer any restructuring until we have a clearer picture of how the collection grows.

galaxy-skills/
├── .claude-plugin/
│   ├── plugin.json           # "skills": "."
│   └── marketplace.json
├── tool-dev/SKILL.md
├── nf-to-galaxy/SKILL.md
└── ...                       # nothing else changes

Pros:

• Smallest possible change
• Doesn't break anything
• Gets the repo into the plugin ecosystem immediately

Cons:

• All or nothing
• Custom "skills": "." path (works, but non-standard)
• Restructure still needed later for individual installation

Cross-reference problem

Worth calling out: tool-dev/references/ contains standalone testing and tool placement guides that are referenced by other skills (notably nf-to-galaxy). If we split into individual plugins, installed plugins are cached independently and can't reference files outside their own directory. Options for handling this:

1. Duplicate the shared references into each plugin that needs them (maintenance burden)
2. Make shared references a separate "base" plugin that others depend on (the plugin system doesn't support plugin dependencies, so this would just be documentation telling users to also install the base)
3. Inline the referenced content into each skill that uses it (removes the cross-reference entirely)
4. Accept the gap — the references are supplementary, not critical. A skill works without them, it just has less context.

Recommendation

Option D (minimal config now) or Option C (restructure into skills/) seem like the practical choices. Option D gets us into the plugin ecosystem immediately with zero risk. Option C is more work but sets up the right layout for eventual splitting.

The cross-reference issue is the main argument for not splitting into individual plugins prematurely — better to figure out the right shared-resource pattern first.

Related

• galaxyproject/claude-galaxy-plugins — existing marketplace for Galaxy core developer plugins (separate audience)
• galaxyproject/galaxy-mcp — complementary MCP server for programmatic Galaxy interaction

[arash77]

I’ve been prototyping a similar setup but only for galaxy development in my own repo: https://github.com/arash77/galaxy-claude-marketplace
It’s not an exact 1:1 match for the proposed options, but the structures there could be useful as a reference or a starting point to fast-track the implementation.