version-bumper
Automatically handles semantic version updates across plugin.json and marketplace catalog when user mentions version bump, update version, or release. Ensures version consistency in claude-code-plugins repository.
- License 许可
- MIT
- 最近更新
- 2026-11-13
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- version-bumper
- description
- Automatically handles semantic version updates across plugin.json and marketplace catalog when user mentions version bump, update version, or release. Ensures version consistency in claude-code-plugins repository.
- allowed-tools
- Read, Write, Edit, Grep, Bash
03 SKILL.md 正文
Version Bumper
Purpose
Automatically manages semantic version updates for Claude Code plugins, ensuring consistency across plugin.json, marketplace catalog, and git tags - optimized for claude-code-plugins repository workflow.
Trigger Keywords
- "bump version" or "update version"
- "release" or "new release"
- "major version" or "minor version" or "patch version"
- "increment version"
- "version update"
Semantic Versioning
Format: MAJOR.MINOR.PATCH (e.g., 2.1.3)
Rules:
- MAJOR (2.x.x) - Breaking changes, incompatible API changes
- MINOR (x.1.x) - New features, backward compatible
- PATCH (x.x.3) - Bug fixes, backward compatible
Examples:
1.0.0→1.0.1(bug fix)1.0.0→1.1.0(new feature)1.0.0→2.0.0(breaking change)
Version Bump Process
When activated, I will:
-
Identify Current Version
# Read plugin version current=$(jq -r '.version' .claude-plugin/plugin.json) echo "Current version: $current" -
Determine Bump Type
- From user request (major/minor/patch)
- Or suggest based on changes
- Or ask user which type
-
Calculate New Version
# Example for patch bump: 1.2.3 → 1.2.4 IFS='.' read -r major minor patch <<< "$current" new_version="$major.$minor.$((patch + 1))" -
Update Files
- Update
.claude-plugin/plugin.json - Update
.claude-plugin/marketplace.extended.json - Sync to
marketplace.json
- Update
-
Validate Consistency
- Verify all files have same version
- Check no other plugins use this version
- Validate semver format
-
Create Git Tag (Optional)
git tag -a "v$new_version" -m "Release v$new_version"
Update Locations
1. Plugin JSON
// .claude-plugin/plugin.json
{
"name": "plugin-name",
"version": "1.2.4", // ← Update here
...
}
2. Marketplace Extended
// .claude-plugin/marketplace.extended.json
{
"plugins": [
{
"name": "plugin-name",
"version": "1.2.4", // ← Update here
...
}
]
}
3. Sync CLI Catalog
npm run sync-marketplace
# Regenerates marketplace.json with new version
Bump Types
Patch Bump (Bug Fix)
When to use:
- Bug fixes
- Documentation updates
- Minor improvements
- No new features
Example: 1.2.3 → 1.2.4
Minor Bump (New Feature)
When to use:
- New features
- New commands/agents/skills
- Backward compatible changes
- Enhanced functionality
Example: 1.2.3 → 1.3.0
Major Bump (Breaking Change)
When to use:
- Breaking API changes
- Incompatible updates
- Major refactor
- Removed features
Example: 1.2.3 → 2.0.0
Validation Checks
Before bumping:
- ✅ Current version is valid semver
- ✅ New version is higher than current
- ✅ No other plugin uses new version
- ✅ All files have same current version
- ✅ Git working directory is clean (optional)
After bumping:
- ✅ plugin.json updated
- ✅ marketplace.extended.json updated
- ✅ marketplace.json synced
- ✅ All versions consistent
- ✅ CHANGELOG.md updated (if exists)
Changelog Management
If CHANGELOG.md exists, I update it:
# Changelog
## [1.2.4] - 2025-10-16
### Fixed
- Bug fix description
- Another fix
## [1.2.3] - 2025-10-15
...
Git Integration
Option 1: Version Commit
# Update version files
git add .claude-plugin/plugin.json
git add .claude-plugin/marketplace.extended.json
git add .claude-plugin/marketplace.json
git add CHANGELOG.md # if exists
# Commit version bump
git commit -m "chore: Bump plugin-name to v1.2.4"
Option 2: Version Tag
# Create annotated tag
git tag -a "plugin-name-v1.2.4" -m "Release plugin-name v1.2.4"
# Or for monorepo
git tag -a "v1.2.4" -m "Release v1.2.4"
# Push tag
git push origin plugin-name-v1.2.4
Multi-Plugin Updates
For repository-wide version bump:
# Bump marketplace version
jq '.metadata.version = "1.0.40"' .claude-plugin/marketplace.extended.json
# Update all plugins (if needed)
for plugin in plugins/*/; do
# Update plugin.json
# Update marketplace entry
done
Version Consistency Check
I verify:
# Plugin version
plugin_v=$(jq -r '.version' plugins/category/plugin-name/.claude-plugin/plugin.json)
# Marketplace version
market_v=$(jq -r '.plugins[] | select(.name == "plugin-name") | .version' .claude-plugin/marketplace.extended.json)
# Should match
if [ "$plugin_v" != "$market_v" ]; then
echo "❌ Version mismatch!"
echo "Plugin: $plugin_v"
echo "Marketplace: $market_v"
fi
Release Workflow
Complete release process:
-
Determine Bump Type
- Review changes since last version
- Decide: patch/minor/major
-
Update Version
- Bump plugin.json
- Update marketplace catalog
- Sync marketplace.json
-
Update Changelog
- Add release notes
- List changes
- Include date
-
Commit Changes
git add . git commit -m "chore: Release v1.2.4" -
Create Tag
git tag -a "v1.2.4" -m "Release v1.2.4" -
Push
git push origin main git push origin v1.2.4 -
Validate
- Check GitHub release created
- Verify marketplace updated
- Test plugin installation
Output Format
? VERSION BUMP REPORT
Plugin: plugin-name
Old Version: 1.2.3
New Version: 1.2.4
Bump Type: PATCH
✅ UPDATES COMPLETED:
1. Updated .claude-plugin/plugin.json → v1.2.4
2. Updated marketplace.extended.json → v1.2.4
3. Synced marketplace.json → v1.2.4
4. Updated CHANGELOG.md
? CONSISTENCY CHECK:
✅ All files have version 1.2.4
✅ No version conflicts
✅ Semantic versioning valid
? CHANGELOG ENTRY:
## [1.2.4] - 2025-10-16
### Fixed
- Bug fix description
? NEXT STEPS:
1. Review changes: git diff
2. Commit: git add . && git commit -m "chore: Bump to v1.2.4"
3. Tag: git tag -a "v1.2.4" -m "Release v1.2.4"
4. Push: git push origin main && git push origin v1.2.4
✨ Ready to release!
Repository-Specific Features
For claude-code-plugins repo:
- Handles both plugin and marketplace versions
- Updates marketplace metadata version
- Manages plugin count in README
- Syncs both catalog files
- Creates proper release tags
Examples
User says: "Bump the security-scanner plugin to patch version"
I automatically:
- Read current version: 1.2.3
- Calculate patch bump: 1.2.4
- Update plugin.json
- Update marketplace.extended.json
- Sync marketplace.json
- Validate consistency
- Report success
User says: "Release version 2.0.0 of plugin-name"
I automatically:
- Recognize major version (breaking change)
- Update all version files
- Update CHANGELOG.md with major release notes
- Create git commit
- Create git tag v2.0.0
- Provide push commands
User says: "Increment version for new feature"
I automatically:
- Detect this is a minor bump
- Calculate new version (1.2.3 → 1.3.0)
- Update all files
- Add changelog entry
- Report completion
04 同仓库更多 Skills
Docs Research
Use MCP Central Docs server to search, ask, and retrieve documentation (FastMCP, standards, packaging).
wrappee-drift
Read-only, single-repo audit of a repo's tool coverage against the software it wraps (its current real API/docs, not training-data memory) and against comparable/competing wrappers. Trigger when the user says "wrappee drift" followed by a repo name, "capability audit" followed by a repo name, or asks whether a repo is missing features the wrapped software or a competitor now has. Always scoped to one named repo per invocation -- never trigger this fleet-wide or unprompted; that is explicitly against the SOP. Do NOT trigger for internal fleet-standard compliance (that is drift-scan) or strategic worth/archive decisions (that is quality-check) -- this is specifically about the gap between the repo's tool list and the wrapped software's/competitors' actual current capabilities.
modules
暂无简介
mcp-standards
Use when developing MCP servers to access comprehensive standards for scaffolding, packaging, sampling, documentation, testing, error handling, monitoring, and CI/CD workflows.
webapp-cua-test
Run the pre-Tauri CUA click-through test (real browser, dev stack, OCR "Connected" wait, sidebar nav walk) for a fleet MCP server repo under D:\Dev\repos. Trigger when the user says "cua webapp test" or "webapp clickthrough" followed by a repo name, asks for an e2e click-through of a webapp, or asks whether a webapp boots and connects in a real browser. Not for the installed NSIS app (that is the nsis-build skill / cua-nsis-test) and not for DOM assertions (Playwright), and not for hunting fake data or dead buttons (fakefind).
ship
Final release gate for a fleet MCP server repo under D:\Dev\repos -- run all quality gates, build the release artifact, verify it, commit, push, and cut a GitHub release. Trigger this whenever the user says "ship it", "ship" followed by a repo name, "release" followed by a repo name, or asks to finalize and publish work that's already been done in a repo. This is the terminal step after assfix/nsis-build, not a substitute for them -- if the repo hasn't been assessed recently, say so before shipping rather than shipping blind.