Support branch parameter in marketplace source configuration

Resolved 💬 2 comments Opened Apr 15, 2026 by final-il Closed Apr 15, 2026

Feature Request

Problem

When developing plugins/skills for a marketplace, there's no way to test changes without affecting the production marketplace. The current extraKnownMarketplaces config only supports a git URL with no branch selection:

"maor-skills-marketplace": {
  "source": { "source": "git", "url": "https://github.com/org/marketplace.git" },
  "autoUpdate": true
}

To achieve dev/prod separation, we currently need to duplicate the entire repo — one for dev, one for prod — and manage two separate marketplace registrations pointing to two different GitHub repos. This means duplicate repos, manual syncing, path mismatches in SKILL.md files, and a cumbersome promotion process.

Proposed Solution

Add an optional branch (or ref) parameter to the marketplace source configuration:

"maor-skills-marketplace": {
  "source": { "source": "git", "url": "https://github.com/org/marketplace.git", "branch": "main" },
  "autoUpdate": true
},
"maor-skills-marketplace-dev": {
  "source": { "source": "git", "url": "https://github.com/org/marketplace.git", "branch": "dev" },
  "autoUpdate": true
}

Benefits

  • Same repo, different branches — no need to duplicate repos
  • Standard git workflow — develop on dev branch, promote to main via merge/PR
  • No path mismatches — SKILL.md files stay identical between branches
  • Per-project plugin override already works — project-level .claude/settings.json can enable plugin@marketplace-dev in dev directories and plugin@marketplace in prod directories
  • Clean two-terminal workflow — dev terminal uses dev branch plugins, prod terminal uses main branch plugins, no interference

Current Workaround

We maintain two separate GitHub repos (marketplace and marketplace-dev), register both in settings, and use git push prod main to promote. SKILL.md files that reference local paths need sed transformations during promotion. This works but adds significant overhead for plugin developers.

Use Case

Anyone building and iterating on plugins/skills needs a way to test changes without breaking their (or their team's) working environment. This is especially important for complex plugins like multi-agent systems where changes to agent instructions need thorough testing before release.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗