stacklok / toolhive-release
Install for your project team
Run this command in your project directory to install the skill for your entire team:
mkdir -p .claude/skills/toolhive-release && curl -L -o skill.zip "https://fastmcp.me/Skills/Download/3804" && unzip -o skill.zip -d .claude/skills/toolhive-release && rm skill.zip
Project Skills
This skill will be saved in .claude/skills/toolhive-release/ and checked into git. All team members will have access to it automatically.
Important: Please verify the skill by reviewing its instructions before using it.
Creates ToolHive release PRs by analyzing commits since the last release, categorizing changes, recommending semantic version bump type (major/minor/patch), and triggering the release workflow. Use when cutting a release, preparing a new version, checking what changed since last release, or when the user mentions "release", "version bump", or "cut a release".
Skill Content
---
name: toolhive-release
description: Creates ToolHive release PRs by analyzing commits since the last release, categorizing changes, recommending semantic version bump type (major/minor/patch), and triggering the release workflow. Use when cutting a release, preparing a new version, checking what changed since last release, or when the user mentions "release", "version bump", or "cut a release".
---
# ToolHive Release
Automates the ToolHive release process by analyzing changes and triggering the release PR workflow.
## When to Use
- When cutting a new ToolHive release
- When checking what's changed since the last release
- When deciding between patch, minor, or major version bump
- When the user says "release", "cut a release", "new version", or "version bump"
## Instructions
### Step 1: Find the Last Release
```bash
git tag --sort=-v:refname | head -1
```
This returns the most recent version tag (e.g., `v0.8.3`).
### Step 2: List Commits Since Last Release
```bash
git log <last-tag>..HEAD --oneline --no-merges
```
Count the commits:
```bash
git log <last-tag>..HEAD --oneline --no-merges | wc -l
```
### Step 3: Categorize Changes
Analyze each commit and categorize into:
| Category | Description | Version Impact |
|----------|-------------|----------------|
| **New Features** | New functionality, new commands, new APIs | Minor bump |
| **Bug Fixes** | Fixes to existing functionality | Patch bump |
| **Breaking Changes** | API changes, removed features, incompatible changes | Major bump |
| **Improvements** | Enhancements to existing features, refactoring | Patch or Minor |
| **Tests/CI** | Test additions, CI/CD changes | No impact |
| **Documentation** | Doc updates, README changes | No impact |
| **Dependencies** | Dependency updates (Renovate PRs) | Patch bump |
### Step 4: Recommend Version Bump
Based on the categorization:
- **Major** (`X.0.0`): Any breaking changes present
- **Minor** (`0.X.0`): New features without breaking changes
- **Patch** (`0.0.X`): Only bug fixes, dependency updates, improvements
Present the recommendation with justification to the user.
### Step 5: Trigger the Release Workflow
**IMPORTANT**: Present the analysis and recommendation to the user and WAIT for explicit confirmation before proceeding.
After user confirms the bump type, use the GitHub MCP tool to trigger the workflow:
```
mcp__github__run_workflow(
owner: "stacklok",
repo: "toolhive",
workflow_id: "create-release-pr.yml",
ref: "main",
inputs: { "bump_type": "<patch|minor|major>" }
)
```
### Step 6: Monitor and Report
1. Get the workflow run status:
```
mcp__github__list_workflow_runs(
owner: "stacklok",
repo: "toolhive",
workflow_id: "create-release-pr.yml",
per_page: 1
)
```
2. Poll until completion (check the `status` field until it shows "completed"):
```
mcp__github__get_workflow_run(
owner: "stacklok",
repo: "toolhive",
run_id: <run_id from step 1>
)
```
3. Find the created PR:
```
mcp__github__list_pull_requests(
owner: "stacklok",
repo: "toolhive",
state: "open",
sort: "created",
direction: "desc",
per_page: 5
)
```
Look for the PR with title matching "Release v<new-version>".
Report the PR URL to the user.
## Release Workflow Chain
For reference, here's what happens after the PR is merged:
1. **create-release-pr.yml** (manual) → Creates PR with version bumps
2. **create-release-tag.yml** (auto on VERSION change) → Creates git tag + GitHub Release
3. **releaser.yml** (auto on release publish) → Builds binaries, images, Helm charts
See [WORKFLOW-REFERENCE.md](references/WORKFLOW-REFERENCE.md) for detailed workflow documentation.
## Example Output
```
## Commits since v0.8.3 (24 commits)
### New Features
- OAuth Authorization Server (#3531, #3513, #3520, #3488)
- ExcludeAll for VirtualMCPServer (#3499)
- Generic PrefixHandlers (#3524)
### Bug Fixes
- OAuth token refresh context cancellation (#3539)
- Custom YAML unmarshalers for registry metadata (#3545)
### Improvements
- Logging updates (#3546, #3547)
### Tests/CI/Docs
- E2E tests for secrets management (#3485)
- Dependency updates
**Recommendation: Minor release (0.9.0)**
New features (OAuth auth server, ExcludeAll) warrant a minor version bump.
```
## Error Handling
- **No tags found**: Repository may not have any releases yet. Check `git tag` output.
- **Workflow trigger fails**: Ensure GitHub MCP server is configured and has proper permissions. The token needs `actions:write` scope.
- **PR not found**: The workflow may still be running. Poll `mcp__github__get_workflow_run` until status is "completed", then search for the PR.
- **Workflow run failed**: Use `mcp__github__get_workflow_run` to check the `conclusion` field. If "failure", use `mcp__github__get_job_logs` to investigate.