split-to-prs
Split current work into small reviewable PRs. Use when the user asks to split a chat, set of changes, branch, or PR.
- License 许可
- MIT
- 最近更新
- 2026-04-29
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- split-to-prs
- description
- Split current work into small reviewable PRs. Use when the user asks to split a chat, set of changes, branch, or PR.
03 SKILL.md 正文
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.
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.
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.
04 同仓库更多 Skills
update-cursor-settings
Modify Cursor/VSCode user settings in settings.json. Use when you want to change editor settings, preferences, configuration, themes, font size, tab size, format on save, auto save, keybindings, or any settings.json values.
update-cli-config
View and modify Cursor CLI configuration settings in ~/.cursor/cli-config.json. Use when the user wants to change CLI settings, configure permissions, switch approval mode, enable vim mode, toggle display options, configure sandbox, or manage any CLI preferences.
statusline
Configure a custom status line in the CLI. Use when the user mentions status line, statusline, statusLine, CLI status bar, prompt footer customization, or wants to add session context above the prompt.
shell
Runs the rest of a /shell request as a literal shell command. Use only when the user explicitly invokes /shell and wants the following text executed directly in the terminal.
migrate-to-skills
Convert 'Applied intelligently' Cursor rules (.cursor/rules/*.mdc) and slash commands (.cursor/commands/*.md) to Agent Skills format (.cursor/skills/). Use when you want to migrate rules or commands to skills, convert .mdc rules to SKILL.md format, or consolidate commands into the skills directory.
cursor-blame
Investigate how code was built with AI. Reveals which conversations produced the code, why it was implemented a certain way, what alternatives were considered, and the intent behind decisions. Use when the user asks about history, evolution, or authorship of code.