pr-stacker

PR Stacker

Mindset

A large PR fails reviewers because it mixes concerns — infrastructure sits next to business logic sits next to test cleanup. Reviewers cannot build a mental model of any single change when everything changes at once.

The fix is to group commits by what kind of thing changed, not by when they were written or what ticket they belong to. Each group becomes its own PR targeting the previous one (stacked branches), so changes can be reviewed and merged in order without blocking unrelated work.

Two failure modes to avoid:

1. The monolith — one PR with everything, reviewers give up or rubber-stamp
2. The over-split — one PR per commit, stacked 10 deep, merge overhead exceeds the benefit

The sweet spot is 2–4 PRs where each one can be understood by a reviewer who only knows that domain.

When to use

• A PR has more than ~15 files changed across unrelated concerns
• A reviewer says "this is too big to review"
• Commits already have phase or step markers in their messages
• Changes span infrastructure, application code, and cleanup in a single branch

When not to use

• The branch has 2–4 commits that all touch the same component — keep it together
• All files are test files for a single feature — one PR is correct
• The work is already in review and splitting restarts the cycle with more overhead than benefit
• Commits are tightly coupled (each depends on the previous for tests to pass) — cherry-pick reordering will produce broken intermediate branches

Trigger phrases

• "This PR is too big"
• "Split this PR"
• "Break this into smaller PRs"
• "Decompose the branch"
• "Too many changes for reviewers"

Workflow

Load Workflow Steps for full commands. Summary: analyse → group → propose (table, wait for approval) → name → stack (cherry-pick) → describe (What/Why) → remind about target branches.

Consider adapting concern labels to the codebase — if there is no infrastructure layer, you may optionally collapse to two groups (application logic + tests).