Перейти к основному содержимому

Перевод: оболочка страницы на русском; тело навыка (SKILL.md) пока на английском — это исходные инструкции агента.

Split To Prs

Split large local changes into small reviewable PRs.

Метаданные навыка​

ИсточникВстроенный (установлен по умолчанию)
Путьskills/software-development/split-to-prs
Версия1.0.0
АвторVibeOS
ЛицензияMIT
Платформыlinux, macos, windows
Тегиcursor, git, pr, split, review, workflow
Связанные навыкиgit-local-workflow, github-pr-workflow, plan, project-kanban-worktrees

Справка: полный SKILL.md​

к сведению

Ниже полное определение навыка, которое VibeOS загружает при активации. Это инструкции, которые видит агент.

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.