After adding the vendor-specific files, wire up the new vendor into the release pipeline:
-
release-please-config.json— add an entry toextra-filesfor each JSON field that should be bumped on release. At minimum this is theversionfield in the vendor's manifest. If the vendor's MCP config includes anX-Source-Versionheader, add that field too. -
.github/workflows/release.yml— add the new vendor to thearchivesassociative array in the "Create vendor archives" step, mapping the archive filename to the space-separated list of files to include. Then add the new archive filename to thegh release uploadcommand. -
.release-please-manifest.json— this file is managed automatically by release-please. Do not edit it by hand; it will be updated when the next release PR is merged.
Before opening a PR, test the plugin locally on the surfaces you've changed. Follow the instructions below to test the plugin for every vendor supported:
- Claude Code — Create your first plugin
- Cursor — Test plugins locally
- Codex — Install a local plugin manually
- GitHub Copilot — Extending Copilot Chat in your organization
- Gemini CLI — Link your extension
Releases are managed automatically by release-please via .github/workflows/release.yml. The workflow runs on every push to main and decides whether to open or update a release PR based on commit message types (Conventional Commits):
| Commit type | Release effect |
|---|---|
feat: |
Patch bump (minor pre-1.0, per config) |
fix: |
Patch bump |
feat!: / BREAKING CHANGE |
Major bump |
chore:, docs:, refactor:, ci:, etc. |
No release |
When a release PR is merged, release-please creates a GitHub release and the workflow builds and uploads the vendors archives, each containing the vendor manifest, MCP adapter, shared skills/, and assets/.
Version numbers are bumped automatically across all vendor plugin.json files and MCP config headers — do not edit them by hand.