split-to-prs

Splits uncommitted or committed changes into small reviewable pull requests.

3|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/ArangoGutierrez/claude-toolkit --skill split-to-prs-arangogutierrez
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: split-to-prs
Source: https://github.com/ArangoGutierrez/claude-toolkit/tree/main/.cursor/skills-cursor/split-to-prs
Command: npx skills add https://github.com/ArangoGutierrez/claude-toolkit --skill split-to-prs-arangogutierrez

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large piles of work on a single branch are hard to review and risky to merge. This Skill turns one set of changes into several small, reviewer-aligned pull requests without losing any work. ## Core Features & Use Cases - Safe snapshots: Saves a recoverable backup ref via git stash create before moving any work, so nothing is lost. - Ownership-aware slicing: Reads CODEOWNERS and ownership files to propose PR boundaries that match natural reviewer assignments. - Approval-gated execution: Proposes a split plan (with Mermaid diagrams for multiple slices) and waits for explicit approval before branching, committing, or opening PRs. - Use Case: You have a week of mixed changes on main spanning three teams. The Skill proposes three independent PRs aligned to each team's ownership, snapshots your work, and opens the PRs after you approve. ## Quick Start Ask the assistant to split the current branch's changes into small reviewable PRs and wait for the proposed plan before approving.

Frequently Asked Questions about split-to-prs

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

FAQPage Schema
How do I split a large branch into multiple pull requests?▼

Compare the current work against the default branch, group changes by ownership or concern, then create a branch per slice and commit only the planned files. This Skill proposes the split plan first and executes only after approval.

How to split uncommitted changes into separate PRs safely?▼

Save a recoverable snapshot first using git stash create and a backup ref, then stage only named files or hunks per slice. Never use git add . or destructive commands like reset --hard during the split.

Should split PRs be stacked or independent?▼

Default to independent PRs off the default branch. Stack PRs only when a real dependency exists, ordering foundational changes before the code that consumes them.

Does splitting PRs risk losing uncommitted work?▼

No, if a snapshot is taken first. The Skill creates a backup ref from git stash create before moving work and never deletes the backup or original branch unless explicitly requested.

When should I not split a branch into multiple PRs?▼

Avoid splitting when changes are tightly coupled and cannot build or pass tests independently. Keep coupled changes together in one PR rather than creating broken intermediate states.