release

Context

By the time this skill runs, the git wrapup protocol should have already handled: changelog entry, version bumps, README updates, atomic commits, and an annotated tag. This skill is the final verification gate before irreversible publish commands. Its job is to catch anything the wrapup missed or got wrong — not to redo the work.

Steps

1. Confirm the Target Version

Read package.json to get the version. This is the source of truth. If the user hasn't decided on the bump level yet (patch/minor/major), ask now — but usually this was already set during wrapup.

2. Verify Version Consistency

The wrapup protocol bumps versions, but sometimes a file gets missed. Search for the old version string across the repo and verify the new version appears in all required locations:

Fix any mismatches. A grep for the old version is the fastest way to find stragglers.

3. Verify CHANGELOG.md

Confirm the changelog entry:

• Uses a concrete version number and date (never [Unreleased])
• Groups changes correctly: Added, Changed, Fixed, Removed
• Accurately reflects what actually shipped — cross-reference with git log since the last tag

4. Verify README.md

Beyond the version badge, confirm:

• Feature counts (tool count, resource count, etc.) match reality if the surface area changed
• Descriptions and capability lists reflect new features
• MCP SDK version badge is current if the dependency was bumped
• Code examples still match current APIs

5. Verify Skill Versions

For any skills whose SKILL.md was modified in this release cycle, confirm metadata.version in their YAML frontmatter was bumped. This is how the maintenance skill detects updates — if the version didn't bump, consumers won't get the new content on bun update.

6. Verify docs/tree.md

If the file structure changed, regenerate and confirm it's current:

bun run tree

Skip if no structural changes occurred.

7. Run Final Checks

All must pass:

bun run devcheck
bun run test
bun run build

8. Verify Commit and Tag

Confirm a clean release commit and annotated tag exist:

• Commit message: chore: release v{{VERSION}}
• Annotated tag: v{{VERSION}} with a concise summary of key changes

If the wrapup created the commit and tag already, verify they're correct. If not, create them now.

Tag message examples:

v0.2.0: Cloudflare Workers support, task tools, Graph service
v0.1.7: OTel instrumentation refactor, lighter semconv
v0.1.6: Error factory functions, auto-classification patterns

9. Stop and Present Publish Commands

The following commands are irreversible. Present them to the user for manual execution:

# Push commit and tag
git push && git push --tags

# Publish to npm
bun publish --access public

# Build and push Docker image
docker buildx build --platform linux/amd64,linux/arm64 \
  -t ghcr.io/cyanheads/mcp-ts-core:{{VERSION}} \
  -t ghcr.io/cyanheads/mcp-ts-core:latest \
  --push .

# Publish MCP listing (if applicable)
mcp-publisher publish

Pre-Publish Checklist

• Version consistent across all files (package.json, server.json ×3, CLAUDE.md, README.md, templates)
• No stale old-version references found in repo
• CHANGELOG.md has concrete version and date, content matches actual changes
• README.md current — feature counts, badges, descriptions, examples
• Modified skill versions bumped in YAML frontmatter
• docs/tree.md current (if structure changed)
• bun run devcheck passes
• bun run test passes
• bun run build succeeds
• Clean release commit exists
• Annotated git tag exists with summary message
• User presented with publish commands (push, npm, Docker, mcp-publisher)