Chained PR Splitter
Break oversized PRs over 400 lines into chained, reviewable pull requests to preserve reviewer focus.
The skill provides clear procedures for splitting PRs, including requesting maintainer approval (size:exception) and asking the user at key decision points (choosing chain strategy). It emphasizes protecting review focus and providing rollback scope, but does not specify permissions or data-flow details. Since this is a static review, actual permissions or execution cannot be verified. Deductions for lack of permission guidance and data-flow disclosure.
Provides clear steps and decision gates, but key paths (e.g., Git commands) are untested and unverified. In static review, command correctness or behavior cannot be confirmed. Error handling and failure feedback are limited, e.g., no specification of behavior when commands fail. Deductions for lack of execution validation and limited error handling.
Clear definition of trigger conditions and applicable scenarios, including explicit thresholds (400 lines). But limited evidence of non-fit boundaries, and no mention of environment fit (e.g., Chinese language support or network requirements). Deductions for incomplete boundaries and lack of environment fit evidence.
Documentation is well-structured with clear activation contract, hard rules, and decision gates. But missing version changes or update path information, and no install/dependency notes or troubleshooting sections. Deductions for unclear versioning and maintenance responsibility.
The skill's logic is clear and may improve review efficiency, but no actual output examples or verification results are provided. Direct usability cannot be confirmed in static review. Deductions for lack of operational output validation and comparative advantage evidence.
No test cases or independent execution evidence provided. Reference document provides some details, but cannot be independently verified. Deductions for lack of third-party execution evidence and reproducible verification.
- The skill depends on external GitHub commands (gh) and features which may not be available in all environments.
- No details on permissions and data-flow transparency, potentially implying permission issues.
- Error handling or troubleshooting not covered, leaving users without guidance when things go wrong.
- Versioning and update paths are not declared; maintenance responsibility is unclear.
- Environment fit (e.g., Chinese language support and network reachability) is not addressed, potentially affecting usability for Chinese users.
What does this skill do, and when should you use it?
This skill handles large or stacked pull requests. When a change exceeds 400 lines or needs review slicing, it splits the work into smaller, independently mergeable PRs with dependency diagrams and clear boundaries, ensuring each PR can be reviewed within an hour. It supports two chain strategies: stacked PRs (direct to main) and feature branch chains (with a tracker PR). Part of the gentle-ai repository, distributed under the MIT license, installable via official scripts.
The skill assesses PR change size and triggers when exceeding 400 lines. It guides the user to choose a chain strategy (stacked or feature branch), create branches, and generate PRs with chain context including start/end, dependencies, follow-up work, and out-of-scope items. It produces dependency diagrams for each child PR, marking the current one. It ensures PRs stay within a 60-minute review budget and validates each PR's CI, tests, docs, and rollback scope. The output includes chosen strategy, PR order, boundary, budget, and verification plan.
- A developer preparing a PR with over 400 lines wants to split it into independently mergeable chunks to reduce review burden.
- A team working on a large feature needs phased reviews without blocking main integration, using a feature branch chain with a tracker.
- A developer must verify integration before main, using a feature branch chain to stage the feature.
- A reviewer wants to quickly grasp context through dependency diagrams and clear PR boundaries.
- When SDD forecasts high risk or recommends chained PRs, a developer follows the skill's directives for splitting.
What are this skill's strengths and limitations?
- Clear 400-line threshold and 60-minute review time budget for quick decisions.
- Two well-defined chain strategies: stacked and feature branch, accommodating different integration needs.
- Mandates dependency diagrams and chain context, reducing reviewer cognitive load.
- Supports size:exception for justified deviations.
- Assumes Git workflow and requires branch management skills.
- May not cleanly split generated/vendor/migration diffs, requiring human judgment.
- Provides guidance only, no automation; actual splitting and PR creation remain manual.
- No documented test suite or platform coverage; examples only.
How do you install this skill?
This skill is bundled in the gentle-ai repository. To install the collection, run the official installer:
macOS/Linux: curl -fsSL https://raw.githubusercontent.com/Gentleman-Programming/gentle-ai/main/scripts/install.sh | bash
Windows (PowerShell): irm https://raw.githubusercontent.com/Gentleman-Programming/gentle-ai/main/scripts/install.ps1 | iex
After installation, the skill is located at internal/assets/skills/chained-pr/. Requires the gentle-ai CLI.
How do you use this skill?
After installation, the skill activates automatically when conditions are met, such as a planned PR exceeding 400 lines or SDD forecasting high risk. Users can also explicitly request it. The skill guides you through selecting a strategy and creating branches and PRs, generating PR descriptions with chain context. Ensure each PR stays under 400 changed lines and includes a dependency diagram. Before creating PRs, run /sdd-init to initialize project context and gentle-ai skill-registry refresh to register the skill.