pr-slicer

Splitting a large pull request involves breaking it into small, independently verifiable slices with specific goals and owned files. This approach applies prescriptive size budgets, enforces ordering rules to avoid cross-slice dependencies, and generates rollback plans to simplify verification and reduce review latency.

Creating stacked PRs requires sequencing changes into low-risk, independently verifiable slices. This method targets specific changed lines and file budgets per slice, extracts prerequisites first, applies behavior changes next, and generates per-slice verification commands and rollback plans for clear handoffs.

PR slicing handles verification by producing per-slice packets that include narrow checks for touched behavior, exact verification commands with expected outcomes, and project gate checks. It also generates specific rollback plans and risk levels to ensure safe, clear handoffs for each independent slice.

You should shrink a pull request using a slicing strategy when contributors request splitting to reduce review latency and rework. It is specifically designed for large, high-risk Git-based repository changes that need to be broken down into low-risk, independently verifiable modifications ready for review.

To avoid cross-slice dependencies in Git, the ordering rules extract prerequisites first, land mechanical refactors next, apply behavior changes after prerequisites are met, and finish with UI, docs, or polish. This ordered strategy minimizes merge conflicts and ensures each slice remains independently verifiable.