How do I install the Split To Prs skill?

Run npx skillmds@latest add kritika810/split-to-prs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Split To Prs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Split To Prs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Split To Prs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Split To Prs?

kritika810 (@kritika810) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Split To Prs by kritika810 — Agent Skill

Name: Split To Prs
Author: kritika810

File contents

split-to-prs

Turn one pile of work into a few small PRs.

Hard rules

Do not create branches, commit, push, or open PRs until the user approves the split plan.
Never discard user work. No destructive git commands (reset --hard, clean -fdx, branch deletion, force-push, history rewrite) without explicit approval.
Always save a recoverable snapshot before moving work around. This often starts from dirty work on main, so do not assume there is already a safe branch.
Stage only named files or hunks. No git add . / git add -A.

1. Check the state

Compare the current work to the repo's default branch, including committed and uncommitted changes. Summarize the real slices you see, and use the chat history to recover intent.

Before proposing slices, find ownership signals for the touched paths (CODEOWNERS, nested ownership files, tools/ownership/PRODUCTOWNERS, or repo equivalents) and use them to identify natural reviewer boundaries.

2. Propose the split

Use judgment on detail. Usually PR titles are enough. Add a one-line scope note only when a title is unclear. Show a Mermaid diagram when there are multiple slices.

Optimize for reviewer-aligned PRs with minimal unrelated diff: split independent owners or concerns, keep tightly coupled changes together, and when stacking is necessary, order foundations before consumers.

Default to independent PRs off the default branch. Stack PRs only when the dependency is real.

Ask for approval before starting.

3. Execute the split

If there is uncommitted work, save a recoverable snapshot without changing the working tree:

SHA=$(git stash create "pre-split")
if [ -n "$SHA" ]; then
  git update-ref "refs/backup/pre-split-$(date +%s)" "$SHA"
fi

For each approved slice, create a branch from the right base, stage and commit only the planned files or hunks, then push and open the PR.

4. Report back

Keep it short: PR titles and URLs, plus anything left on the starting branch or working tree. Do not delete the backup ref or original branch unless the user asks.

---name: split-to-prsdescription: Split current work/changes/branch into a few small reviewable PRs while preserving user work. Use when asked to split work, a branch, or a PR.---# split-to-prsTurn one pile of work into a few small PRs.## Hard rules- Do not create branches, commit, push, or open PRs until the user approves the split plan.- Never discard user work. No destructive git commands (`reset --hard`, `clean -fdx`, branch deletion, force-push, history rewrite) without explicit approval.- Always save a recoverable snapshot before moving work around. This often starts from dirty work on `main`, so do not assume there is already a safe branch.- Stage only named files or hunks. No `git add .` / `git add -A`.## 1. Check the stateCompare the current work to the repo's default branch, including committed and uncommitted changes. Summarize the real slices you see, and use the chat history to recover intent.Before proposing slices, find ownership signals for the touched paths (`CODEOWNERS`, nested ownership files, `tools/ownership/PRODUCTOWNERS`, or repo equivalents) and use them to identify natural reviewer boundaries.## 2. Propose the splitUse judgment on detail. Usually PR titles are enough. Add a one-line scope note only when a title is unclear. Show a Mermaid diagram when there are multiple slices.Optimize for reviewer-aligned PRs with minimal unrelated diff: split independent owners or concerns, keep tightly coupled changes together, and when stacking is necessary, order foundations before consumers.Default to independent PRs off the default branch. Stack PRs only when the dependency is real.Ask for approval before starting.## 3. Execute the split- If there is uncommitted work, save a recoverable snapshot without changing the working tree: ```bash SHA=$(git stash create "pre-split") if [ -n "$SHA" ]; then git update-ref "refs/backup/pre-split-$(date +%s)" "$SHA" fi ```- For each approved slice, create a branch from the right base, stage and commit only the planned files or hunks, then push and open the PR.## 4. Report backKeep it short: PR titles and URLs, plus anything left on the starting branch or working tree. Do not delete the backup ref or original branch unless the user asks.

Frequently asked questions

Split To Prs