Menú
Analyzes current changes and suggests how to split them into smaller, reviewable PRs
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Guide for using ToolHive CLI (thv) to run and manage MCP servers and skills. Use when running, listing, stopping, building, or configuring MCP servers locally. Covers server lifecycle, registry browsing, secrets management, client registration, groups, container builds, exports, permissions, network isolation, authentication, and skill management (install, uninstall, list, info, build, push, validate). NOT for Kubernetes operator usage or ToolHive development/contributing.
Validates operator chart contribution practices (helm template, ct lint, docs generation) before committing changes.
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".
Implements a GitHub user story from planning through PR creation, with research, codebase analysis, and structured commits.
Generates polished GitHub release notes for a ToolHive release by analyzing every merged PR, cross-referencing linked issues, dispatching expert agents to assess breaking changes, and producing a formatted release body. Use when the user provides a GitHub release URL, tag name, or says "release notes".
Finds flaky tests on the main branch by analyzing GitHub Actions failures, ranks them by frequency, and enters parallel plan mode to design deflake strategies. Use when you want to find and fix the flakiest tests.
| name | split-pr |
| description | Analyzes current changes and suggests how to split them into smaller, reviewable PRs |
Help developers break down large changesets into logical, reviewable pull requests. This skill analyzes the current diff and proposes a splitting strategy that keeps changes atomic and reviewable.
Run these commands to understand the scope:
# Get detailed file statistics
git diff main...HEAD --stat
# List all changed files
git diff main...HEAD --name-only
# Show commit history for context
git log main...HEAD --oneline
# Count non-generated files changed
git diff main...HEAD --name-only | grep -v 'vendor/' | grep -v '\.pb\.go$' | grep -v 'zz_generated' | grep -v '^docs/' | wc -l
# Count lines changed (excluding generated code)
git diff main...HEAD --stat -- . ':(exclude)vendor/*' ':(exclude)*.pb.go' ':(exclude)zz_generated*' ':(exclude)docs/*' | tail -1
Assess whether the changes exceed recommended limits:
If changes exceed these limits or mix multiple concerns, proceed to split analysis.
Examine the changed files and identify natural boundaries:
Use these commands to help:
# Group changed files by directory
git diff main...HEAD --name-only | grep -v 'vendor/' | grep -v '\.pb\.go$' | cut -d'/' -f1-2 | sort | uniq -c
# Show changes by package
git diff main...HEAD --name-only | grep '\.go$' | grep -v '_test\.go$' | cut -d'/' -f1-3 | sort | uniq -c
Create a structured plan with multiple PRs:
For each proposed PR, specify:
Determine the optimal order for creating PRs:
Provide a clear, actionable plan:
## Proposed PR Split
### Summary
Currently [X] files changed with [Y] lines modified. Recommend splitting into [N] PRs:
### PR 1: [Name] (Create First)
**Purpose**: [What and why]
**Files**:
- path/to/file1.go
- path/to/file2.go
**Size**: ~100 LOC
**Dependencies**: None
**Tests**: Includes unit tests for new functionality
### PR 2: [Name] (After PR 1)
**Purpose**: [What and why]
**Files**:
- path/to/file3.go
**Size**: ~150 LOC
**Dependencies**: Requires PR 1 (uses new interface)
**Tests**: Integration tests
[... continue for each PR ...]
## Next Steps
1. Would you like me to help create PR 1 first?
2. Should I create a tracking issue for the overall work?
3. Any changes to this split strategy?
Refactoring + Feature:
Multi-layer Feature:
Package Restructuring:
Kubernetes Operator Changes:
Current state: 8 files changed, 450 lines
Split strategy:
pkg/ package (3 files, 200 lines)Rationale: Business logic is independently testable and reusable
Current state: 15 files changed, 800 lines
Split strategy:
Rationale: Each PR is independently valuable and testable
Current state: 12 files changed, 600 lines
Split strategy:
Rationale: Each PR represents a complete vertical slice of functionality
After presenting the split strategy: