split-to-prs

To split a large pull request, decompose the accumulated changes into smaller, well-scoped PRs for safer code review. This process involves planning the decomposition and staging only approved changes to create separate branches for each slice.

Breaking down a git branch requires decomposing the set of changes into smaller, well-scoped PRs. The workflow enforces saving a recoverable snapshot before moving work and prevents creating branches or pushing until explicit approval is granted.

Planning a split for code changes involves generating a decomposition plan that waits for explicit approval before execution. No branches are created, commits made, or pushes executed until you approve the proposed split plan.

You cannot automatically create branches and PRs when splitting work without explicit approval. Guardrails prevent creating branches, committing, pushing, or opening PRs until you explicitly approve the planned decomposition.

Saving a recoverable snapshot when splitting changes ensures work is backed up before moving or staging any slices. This snapshot provides a fallback point to recover your work if the decomposition or staging process encounters issues.

After approving a plan to split a PR, you create and push branches for each approved slice. The workflow stages only approved changes and provides concise PR titles and URLs while reporting remaining work.