| name | split-pr |
| description | Safely split changes from the current branch into a separate pull request. Use when asked to "split this PR", "extract changes into a separate PR", "create a separate PR for X", or when a PR is too large and needs to be broken up. |
Split PR Skill
Safely extracts a subset of changes from your current branch into a separate, focused pull request.
Safety Rules (CRITICAL)
Never Do This
- NEVER run
git stash, git checkout -- ., or git reset --hard when there are staged or unstaged changes
- NEVER use
git checkout <ref> -- <path> to investigate other branches - this modifies the working tree
Always Do This
- USE READ-ONLY COMMANDS to investigate:
git show, git diff, git log
- COMMIT or confirm clean state before any branch operations
- CREATE new branch before modifying files
Workflow
Phase 1: Analyze (Read-Only)
-
Check current state
git status
git branch --show-current
-
Understand what's in the PR (compare to target branch, usually development or main)
git log origin/development..HEAD --oneline
git diff origin/development --stat
-
Identify split candidates - Look for:
- Independent features or fixes
- Backend vs frontend changes
- Changes that don't share file dependencies
- Self-contained refactors
-
Investigate specific changes (READ-ONLY - use git show, not git checkout)
git show origin/development:path/to/file.ts
git diff origin/development -- path/to/file.ts
Phase 2: Plan
Present the user with:
- Recommended files/changes to split out
- Reasoning (independence, reviewability, CI compatibility)
- Any concerns about dependencies between changes
Get user approval before proceeding.
Phase 3: Execute
-
Ensure clean state on source branch
git status
-
Create new branch from target base
git checkout -b <new-feature-branch> origin/development
-
Apply changes using git checkout from source branch
git checkout <source-branch> -- path/to/file1.ts path/to/file2.ts
-
Handle renames/deletions
git rm path/to/old-name.js
git checkout <source-branch> -- path/to/new-name.ts
-
Make necessary adjustments for independence
- Add backward-compatible exports if splitting breaks imports
- Update types if needed
- Ensure the split changes work standalone
Phase 4: Verify
-
Check TypeScript compiles
npx tsc --noEmit
-
Check linting passes
yarn lint:eslint:fix
-
Run tests
yarn test
-
Review the diff
git diff origin/development --stat
git diff origin/development
Phase 5: Complete
-
Commit with clear message
git commit -m "refactor: descriptive message about the split changes"
-
Push and create draft PR
git push -u origin <new-feature-branch>
gh pr create --draft --base development --title "..." --body "..."
-
Report back with:
- PR URL
- Summary of what was split out
- Any notes about the remaining changes on the original branch
Handling Problems
If you need to abort
git checkout <original-branch>
git branch -D <new-feature-branch>
If something goes wrong
git reflog
git reset --soft <commit-hash>
Example Session
User: This PR is too big. Can we split out the TypeScript controller changes?
Claude: Let me analyze the PR to identify what can be split...
[Uses git diff origin/development --stat to see all changes]
[Uses git log to understand commit structure]
[Identifies controller files as independent]
Claude: I found 12 controller files that can be split. They have no
dependencies on the other 300+ component files. Want me to proceed?
User: Yes
Claude: Creating new branch and applying changes...
[Creates branch, applies changes safely, verifies compilation]
Claude: Done! Draft PR created: https://github.com/...
- 12 files, +459/-161 lines
- TypeScript compiles ✓
- Tests pass ✓