split-prs

Splits large changes into stacked branches and links them as GitHub PR stacks using gh stack.

Updated Dec 25, 2021
One-click install
npx skills add https://github.com/kotahashihama/dotfiles --skill split-prs-kotahashihama
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: split-prs
Source: https://github.com/kotahashihama/dotfiles/tree/main/home/.claude/skills/split-prs
Command: npx skills add https://github.com/kotahashihama/dotfiles --skill split-prs-kotahashihama

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large changes crammed into a single pull request stall reviews and make feedback hard to track. This Skill helps you decide whether a change should be split before you start, split it into branches, and organize the resulting PRs as a dependency stack on GitHub. ## Core Features & Use Cases - Split Decision Criteria: Judges whether to split based on whether a reviewer can read the change in one pass, not on file independence, with concrete signals like multiple purposes or growing file counts. - Dependency Verification: Uses git diff, merge-base, and merge-tree to determine real merge-order dependencies between PRs, including the special case of lint/type-check PRs that depend on all others. - Stack Management with gh stack: Adopts branches bottom-up with gh stack init, pushes and links with gh stack submit --auto, and retroactively stacks already-opened PRs with gh stack link without touching PR bodies or review comments. - Use Case: You realize mid-feature that your branch mixes a refactor and a new feature. Use this Skill to split them into two branches, stack them with gh stack, and annotate each PR with its merge order. ## Quick Start Ask the assistant to evaluate whether your current branch should be split into a stacked set of PRs and set up the stack with gh stack.

Frequently Asked Questions about split-prs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large pull request into stacked PRs on GitHub?

Decide the split before starting based on whether a reviewer can read the change in one pass, then create branches bottom-up and run gh stack init followed by gh stack submit --auto. This pushes branches, updates PR bases, and creates the stack in one step.

How do I stack pull requests that are already open?

Use gh stack link with the PR numbers ordered from bottom to top. This creates only the GitHub-side stack without local tracking, pushes, or any changes to PR bodies, draft state, or review comments.

When should I split a change into multiple PRs?

Split when a reviewer cannot read the change in one pass, when it mixes multiple purposes like a refactor plus a feature, or when the changed file count keeps growing. Independent mergeability alone is not a reason to split.

How do I determine the merge order of stacked PRs?

Check real dependencies: compare changed files with git diff --name-only, test ancestry with git merge-base --is-ancestor, and detect conflicts with git merge-tree. Check every pair of PRs, not just a sample, before declaring them independent.

Why does gh stack unstack fail on my stack?

gh stack unstack fails when the chain contains an already-merged PR. Instead of unstacking, re-link only the remaining open PRs with gh stack link to rebuild the ordering.

Should I rename an existing branch to match team naming conventions?

No. Renaming a branch that is already pushed or has an open PR forces recreating the PR and loses review comments and history. Apply the type/kebab-case-slug convention only to new branches.