Skip to main content

Split To Prs

Split large local changes into small reviewable PRs.

Skill metadata​

SourceBundled (installed by default)
Pathskills/software-development/split-to-prs
Version1.0.0
AuthorVibeOS
LicenseMIT
Platformslinux, macos, windows
Tagscursor, git, pr, split, review, workflow
Related skillsgit-local-workflow, github-pr-workflow, plan, project-kanban-worktrees

Reference: full SKILL.md​

info

The following is the complete skill definition that VibeOS loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

Split to PRs

Turn one pile of work into a few small, reviewer-aligned changes — the Cursor split-to-prs recipe on VibeOS. Plan first; do not create branches, commits, or PRs until the user approves the split.

When to Use​

  • Dirty tree or one giant branch that should be several PRs
  • User asks to “split into PRs”, “нарежь на PR”, or reduce review risk
  • CODEOWNERS / ownership boundaries suggest natural cuts

Skip when: change is already small; user wants a single PR; no git repo.

Prerequisites​

  • Inside a git repository
  • Ability to inspect git status, git diff, and default-branch history
  • For GitHub open/push: same policy gate as pr-babysit / VIBEOS_POLICY_ALLOW_GITHUB=1 after explicit approval
  • Prefer local commits first (git-local-workflow); push/PR only when asked

How to Run​

  1. Inventory committed + uncommitted work vs the default branch.
  2. Propose slices (titles + one-line scope). Wait for approval.
  3. Snapshot recoverably before moving work (git stash create when dirty).
  4. Apply slices: named paths only — never git add . / git add -A.
  5. Open PRs only if the user asked and policy allows.
git status --short
git diff
git log --oneline "$(git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo origin/main)"...HEAD

# Recoverable snapshot of dirty work (does not change the tree)
SHA=$(git stash create "pre-split")
echo "snapshot=$SHA"

Quick Reference​

RuleDetail
Approve firstNo branch/commit/push/PR before the user OKs the plan
No destroyNo reset --hard, clean -fdx, force-push without explicit ask
Stage named pathsNever blanket git add .
Prefer independent PRsStack only when a real dependency exists
OwnershipSplit on CODEOWNERS / concern boundaries when present

Procedure​

1. Check state​

  • Diff against the repo default branch (committed + uncommitted).
  • Recover intent from chat history when the tree is messy.
  • Note ownership files (CODEOWNERS, nested owners) for reviewer cuts.

2. Propose the split​

  • Usually PR titles are enough; add a one-line scope when unclear.
  • Use a short Mermaid diagram when there are 3+ slices or a real stack.
  • Default: independent branches off the default branch.
  • Stack only when slice B truly needs slice A.

Ask for approval before executing.

3. Execute​

  • If uncommitted: keep the stash create SHA noted so work is recoverable.
  • For each approved slice: branch → stage listed paths → commit (why-focused HEREDOC) → optional push/PR via github-pr-workflow.
  • Leave leftover files listed explicitly; never discard them silently.

4. Hand-off​

  • Summarize: branch names, commit SHAs, remaining uncommitted paths.
  • Offer pr-babysit if CI/comments need a loop after open.

Pitfalls​

  • Never update git config.
  • Never force-push to main/master.
  • Do not invent slices that mix unrelated owners “for speed”.
  • Do not open GitHub PRs while no-github policy is active.
  • Do not rewrite history the user did not ask to rewrite.

Verification​

  • User approved the plan before any branch/commit.
  • Each slice builds/tests in isolation where practical.
  • No silent data loss: leftover paths listed or committed on purpose.
  • git status matches the expected remainder after the split.