Skip to main content

toolhive-release

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".

소스 정보

저장소
stacklok/toolhive
최근 소스 활동
2026년 4월 28일 17:06
감지된 SKILL.md 언어
영어
스타
2,311
포크
323

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기