git-splitlisted

# Git split Before proposing a split, read from the project root in parallel: - `standards/branch.md`: format, types, length limit, and constraints - `standards/pr.md`: PR title format, body sections, and content rules Follow both exactly. ## Context Run these commands in parallel to gather git context: - `git status --porcelain 2>/dev/null || echo "NO_STATUS"` - `git branch --show-current 2>/dev/null || echo "NO_BRANCH"` - `git log main..HEAD --oneline --no-decorate --stat 2>/dev/null || echo "NO_COMMITS"` ## Guards - If working tree is dirty (non-empty `git status --porcelain`), stop: `❌ Working tree is dirty. Commit or stash changes before splitting.` - If current branch is `main` or `master`, stop: `❌ Already on main. Nothing to split.` - If no commits ahead of main, stop: `❌ No commits ahead of main. Nothing to split.` ## Grouping rules - Group commits by concern using both commit messages and file paths. - Prefer fewer branches: combine related commits into one branch. - Only split into separate branches when concerns are clearly independent. - Identify the primary concern of the current branch. Rename it using `git branch -m` if the current name does not already match. Skip the rename if it already matches. Secondary concerns are extracted as new focused branches via cherry-pick. - If no single concern dominates (dumping-ground branch with no clear primary), split all commits into new focused branches and add `git branch -d <current>` to delete the orig