Commit Tidy

Analyze staged/unstaged changes and recommend whether to split into multiple commits.

When to use

• - Before committing large changesets
• User asks "should I split this commit?"
• Reviewing changes that touch many files
• Ensuring atomic, reviewable commits

Split Decision Criteria

Split when

1. 1. Unrelated functionality changes

- Feature A + Bug fix B → 2 commits - UI change + API change (if independent) → 2 commits

1. 2. Wide file spread

- Changes span 5+ directories with no common purpose - Frontend + Backend + Config all modified

1. 3. Mixed change types

- Refactoring + New feature → 2 commits - Formatting + Logic change → 2 commits - Dependency update + Code change → 2 commits

1. 4. Large diff size

- 500+ lines changed across unrelated areas - Multiple components modified independently

1. 5. Different reviewers needed

- Changes require different domain expertise - Security-sensitive + general changes

Keep together when

1. 1. Single logical change

- Feature requires touching multiple files - Refactoring that must be atomic

1. 2. Dependent changes

- API change + caller updates - Schema change + migration + model update

1. 3. Related cleanup

- Feature + directly related tests - Bug fix + regression test

Squash Criteria

When analyzing multiple commits, recommend squashing as well as splitting.

Squash when

1. 1. Same type + same purpose

- test: A test + test: B test (tests for the same feature) → squash into 1 - fix: typo A + fix: typo B (same review feedback) → squash into 1

1. 2. Commits split per loop by automated agents

- Autonomous agents like Ralph commit per loop → squash if same purpose - Example: proxy test in loop 1, OIDC test in loop 2 → INLINECODE4

1. 3. Consecutive WIP commits

- wip: in progress + feat: complete → squash into one feat

Don't squash

1. 1. Commits with different types — keep test + chore + feat separate
2. Commits belonging to different PRs/issues
3. Independent changes that may need to be reverted

Output format (when recommending squash)

CODEBLOCK0

Instructions

Step 1: Analyze changes

CODEBLOCK1

Step 2: Categorize files

Group changed files by:

• - Feature/Component: Which feature does this belong to?
• Change type: feat, fix, refactor, style, test, docs, chore
• Directory: Are changes localized or spread out?

Step 3: Identify boundaries

Look for natural split points:

• - Different conventional commit types
• Independent functionality
• Separate test files from implementation (if tests are for different features)

Step 4: Recommend split strategy

Provide specific recommendations:

CODEBLOCK2

Step 5: Execute split (if requested)

CODEBLOCK3

Quick Reference

File spread heuristic

Files	Directories	Recommendation
1-5	1-2	Usually single commit
5-10

2-3 | Review for split | | 10+ | 4+ | Likely needs split |

Change type combinations to split

Combination	Split?
feat + feat (unrelated)	✅ Yes
feat + related test

❌ No | | fix + unrelated refactor | ✅ Yes | | refactor + style (same files) | ❌ No | | chore(deps) + feat | ✅ Yes |

Output Format

Analysis results should include:

1. 1. List of changed files with categories
2. Whether split is needed and why
3. Specific commit splitting plan
4. Suggested commit messages for each
5. Execution commands (if requested)