Pr Split

---
name: pr-split
description: Check if a pull request is too large and guide splitting it into focused PRs.
license: MIT
compatibility: claude cursor opencode
metadata:
  version: "1.0.0"
  languages: all
  audience: developers
  workflow: analysis
  since: "2026-02-24"
---

## What I do

I help you assess whether a PR is too large and guide you through splitting it if needed:

1. **Size Assessment** — Evaluate the PR by lines changed and number of distinct logical concerns
2. **Threshold Check** — Evaluate size and cohesion together: >1 concern is always too large; >400 lines is a review-risk signal that requires an atomicity check
3. **If OK**: Confirm the PR is appropriately sized
4. **If Too Large**: Identify distinct concerns, propose a logical split, and guide branch strategy
5. **If Unsplittable**: Help you document and annotate the PR for easier review despite size

Oversized PRs slow review, increase risk of missed issues, and frustrate reviewers. This skill prevents that.

## When to use me

Use when you want to:
- Check if your PR exceeds recommended size limits
- Get guidance on splitting an oversized PR
- Identify logical groupings for a large changeset
- Document why a large PR cannot be split
- Plan a sequence of dependent PRs

## PR lifecycle focus

Stage: **Scope sizing and split planning** (usually before requesting review).

## Use Instead [if available]

- Use `pr-self-review` for a full author checklist beyond PR size/scope.
- Use `pr-create` to draft and open the PR once scope is settled.
- Use `pr-review` for reviewer-side feedback on an already-open PR.

## Example usage

"Is this PR too big?"
"Help me split this PR into smaller ones"
"Check my PR size and suggest a split strategy"

---

## Workflow

Here's how I guide you through PR size assessment and splitting:

### Step 1: Size Assessment
I'll ask for your PR stats if not provided in context:
- How many files changed?
- How many lines added?
- How many lines deleted?
- Rough breakdown by area (auth, API, UI, database, etc.)

Alternatively, you can paste the PR diff or provide a link to an open PR.

### Step 2: Threshold Check
I'll evaluate against the standard threshold:
- **Too big if**: changes span >1 distinct logical concern (regardless of line count)
- **Needs atomicity check if**: >400 lines but still one concern
  - If the change is cleanly splittable: treat as too large and split
  - If the change is truly atomic/unsplittable: keep as one PR and use Step 3c review guidance
- **Clearly OK if**: <=400 lines and focused on one concern

Examples:
- ✅ 300 lines adding auth validation → Within threshold (single concern)
- ❌ 250 lines of auth + 200 lines of payment changes → Over threshold (2 separate concerns)
- ⚠️ 500 lines adding a complete new API endpoint with routes, handlers, and tests → Single concern; run atomicity check (split if possible, otherwise Step 3c)
- ⚠️ 600 lines refactoring one module → Single concern; run atomicity check (split if possible, otherwise Step 3c)
- ❌ 600 lines refactoring + 100 lines new feature → Over threshold (2 concerns: refactor + feature)

### Step 3a: If Within Threshold
**✅ Your PR is appropriately sized!**
- Proceed to request review
- No split needed
- Use your regular review process

### Step 3b: If Above Threshold
**⚠️ Your PR is too large.**

I'll help you split it:

1. **Identify distinct concerns**: Read the diff and group changes by concern
   - "Concern A: Add authentication"
   - "Concern B: Refactor payment logic"
   - "Concern C: Update documentation"

2. **Order by dependency**: Determine the sequence for splitting
   - Core functionality first (what other concerns depend on?)
   - Dependent changes later (what depends on the core?)
   - Standalone refactors last (no dependencies)

   Example order:
   ```
   PR-1: Add auth validation (core)
   PR-2: Update payment to use auth (depends on PR-1)
   PR-3: Documentation and cleanup (independent)
   ```

3. **Guide branch strategy**: Create a plan for splitting
   - Create a feature branch for each concern
   - Base each branch on `main` or previous PR branch (if dependent)
   - Keep commits organized: one PR per concern

4. **Walk through execution**: Help you execute the split
   - Which files go in which PR?
   - What order to open them?
   - How to test each one independently?

### Step 3c: If Unsplittable
**🔒 Large but can't be split**

Some changes are genuinely atomic and can't be split (e.g., auto-generated files, schema migrations, large renames). I'll help you handle this:

1. **Document in PR description**:
   ```
   NOTES: This PR is larger than our standard threshold because:
   [Explain why it cannot be split]
   ```

2. **Guide review strategy**:
   - Use "file-by-file review" mode with the reviewer
   - Schedule a walkthrough to discuss the change
   - Highlight the most critical files for review focus

3. **Suggest alternatives**:
   - Can any preparatory work be split into a separate PR?
   - Can any cleanup be deferred to a follow-up PR?
   - Can the change be phased over multiple PRs in a different way?

---

## Size Threshold Details

**Why 400 lines?**
- Industry research (Google, SmartBear): 400 lines is where review effectiveness drops significantly
- Beyond this, reviewers miss 50% more defects
- Aligns with "fits in one review session" (30–45 minutes)

**Why "concern-based" splitting?**
- Lines changed can be misleading (auto-generated files, large renames)
- What matters is logical cohesion: one concern per PR
- Concern-based PRs are easier to review, test, and revert if needed

## Tips for Success

- **Split early**: Before requesting review, check the size
- **Be specific about concerns**: "auth + refactor" is clearer than "various changes"
- **Test each PR independently**: After splitting, verify each PR works in isolation
- **Order carefully**: Base dependent PRs on each other, not all on main
- **Communicate**: If you can't split, explain why in the PR description
- **Ask for help**: If unsure about splitting strategy, run this skill first