| name | release |
| description | Release the v1 or v2 Flipt MCP server package — bump version, commit, tag with the correct per-package tag scheme, push, and monitor the npm + ghcr publish. Use when the user asks to release, publish, cut a version, or tag either @flipt-io/mcp-server-flipt (v1) or @flipt-io/mcp-server-flipt-v2. |
Release a package
Releases one package per invocation. Arguments (ask if missing): which package (v1 or v2) and the bump (patch | minor | major | explicit X.Y.Z).
| v1 | v2 |
|---|
| npm package | @flipt-io/mcp-server-flipt | @flipt-io/mcp-server-flipt-v2 |
| directory | packages/mcp-server-flipt | packages/mcp-server-flipt-v2 |
| git tag | vX.Y.Z | mcp-server-flipt-v2@X.Y.Z |
| docker image | ghcr.io/flipt-io/mcp-server-flipt | ghcr.io/flipt-io/mcp-server-flipt-v2 |
Tags drive .github/workflows/publish.yml (npm + ghcr, each image also tagged :latest).
CRITICAL — tag scheme: a vX.Y.Z tag ALWAYS publishes the v1 package, regardless of what was bumped. Never create a v* tag for a v2 release, and never let pnpm version auto-tag (its default tag is v*). Always pass --no-git-tag-version and create the tag by hand.
Procedure
1. Preflight
git switch main && git pull --ff-only
git status --short
pnpm install
pnpm -r check && pnpm lint && pnpm -r test && pnpm -r build
All gates must pass before bumping. Also confirm CI is green on origin/main (gh run list --branch main --limit 3). If releasing a fix that just merged, make sure it's actually in main.
2. Bump
Run inside the package directory (the version lifecycle script regenerates src/version.ts and git adds it — a test fails if it drifts, so never edit version fields by hand):
cd packages/<dir>
pnpm version <patch|minor|major|X.Y.Z> --no-git-tag-version
cd ../..
Confirm packages/<dir>/src/version.ts matches the new package.json version and both are staged/modified. Set NEW_VERSION from the package.json.
3. Commit and tag
git add packages/<dir>/package.json packages/<dir>/src/version.ts
git commit -m "chore(release): mcp-server-flipt v${NEW_VERSION}"
git tag "v${NEW_VERSION}"
git commit -m "chore(release): mcp-server-flipt-v2 ${NEW_VERSION}"
git tag "mcp-server-flipt-v2@${NEW_VERSION}"
Double-check with git tag --points-at HEAD that exactly one tag exists and it matches the intended package's scheme before pushing.
4. Push
Confirm with the user before pushing — this publishes to npm and ghcr and cannot be unpublished cleanly.
git push origin main
git push origin <tag>
5. Monitor the publish
gh run list --workflow=publish.yml --limit 1
gh run watch <run-id> --exit-status
If it fails: gh run view <run-id> --log-failed. Common causes: npm auth (NPM_API_KEY secret), Docker build. To retry after a fix that requires a code change, delete the tag locally and remotely (git tag -d <tag> && git push origin :refs/tags/<tag>), land the fix, and re-tag — only safe if nothing published; if npm already published, bump a fresh patch version instead (npm versions are immutable).
Verify the artifacts:
npm view @flipt-io/<package> version
docker manifest inspect ghcr.io/flipt-io/<dir>:${NEW_VERSION} > /dev/null && echo ok
6. GitHub release
gh release create <tag> --title "<tag>" --generate-notes --notes-start-tag <prev-tag-same-package>
--notes-start-tag matters: tags from the other package are interleaved in history, so let-GitHub-guess would produce notes spanning the wrong package. Find the previous tag with git tag --list 'v*' --sort=-v:refname | head (v1) or git tag --list 'mcp-server-flipt-v2@*' --sort=-v:refname | head (v2). For a package's first release, omit --notes-start-tag.
7. Report
Summarize to the user: new version, tag, npm + ghcr links, release URL, and anything skipped or failed.
Notes
- v1 releases also serve the Smithery listing (root
smithery.yaml — v1 only); no extra step, but if env var names changed since last release, verify that file was kept in sync.
- Never run
pnpm publish locally; publishing is CI-only via the tag.
- If both packages need releasing, do two full passes (two commits, two tags) — the workflow parses one package per tag.
