Commit Tidy

Analyze staged/committed changes and recommend splitting or squashing strategy. Use when the user says "commit split", "split commits", "should I split this...

Security Scan

The skill's instructions, required permissions, and actions are coherent with its stated purpose (analyzing and splitting/squashing commits); it has no external dependencies or unexplained credential requests.

Purpose & Capability

Name and description match the actual instructions: the SKILL.md analyzes git diffs/status and recommends commit splits/squashes. No unrelated env vars, binaries, or installs are requested.

Instruction Scope

The instructions explicitly read repository state (git diff, git status) and, when requested, modify history with git reset/git add/git commit. This is expected for a commit-splitting tool, but the commands can alter the working tree/history and should only be run with user consent (especially if commits are already pushed).

Install Mechanism

Instruction-only skill with no install spec and no code files; nothing is written to disk by an installer. Low install risk.

Credentials

No environment variables, credentials, or filesystem paths outside the repo are requested. The access the skill needs (read/write in the git repo) is proportional to its function.

Persistence & Privilege

Skill is not set to always: true and uses normal autonomous-invocation defaults. It does not request persistent system-wide configuration or modify other skills.

Assessment

This skill is coherent for advising and performing commit splits/squashes, but be cautious: its Step 5 commands (git reset/git add/git commit) change your local repository and can rewrite history. Only allow execution when you explicitly request it, ensure commits aren't already pushed (or coordinate with collaborators), and consider making a backup branch before running destructive operations. If you only want recommendations, decline the execution step and apply changes manually after review.

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. Unrelated functionality changes

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

2. Wide file spread

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

3. Mixed change types

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

4. Large diff size

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

5. Different reviewers needed

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

Keep together when

1. Single logical change

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

2. Dependent changes

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

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. 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

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 → test: add unit tests

3. Consecutive WIP commits

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

Don't squash

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)

### Recommendation: Squash 2 commits → 1

**Before** (2 commits):
- 441b966a test(dt): OIDC auth, proxy, SSO tests
- e2b6503a test(dt): OIDC route tests (login, callback, me)

**After** (1 commit):
- test(dt): add OIDC auth unit tests

**Reasoning**: Same type (test), same feature (OIDC auth), agent loop split

Instructions

Step 1: Analyze changes

# Check staged changes
git diff --cached --stat
git diff --cached --name-only

# Check unstaged changes
git diff --stat
git status

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:

## Analysis Results

### Changed Files (N files)
- src/api/... (3 files) - API endpoints
- src/components/... (2 files) - UI components
- tests/... (2 files) - Tests

### Recommendation: Split into N commits

**Commit 1**: feat: add user profile API
- src/api/user.ts
- src/api/types.ts
- tests/api/user.test.ts

**Commit 2**: feat: add profile UI component
- src/components/Profile.tsx
- src/components/Profile.css
- tests/components/Profile.test.tsx

### Reasoning
- API and UI can function independently
- Each can be reviewed by different reviewers

Step 5: Execute split (if requested)

# Unstage all
git reset HEAD

# Stage first commit files
git add src/api/ tests/api/
git commit -m "feat: add user profile API"

# Stage second commit files
git add src/components/ tests/components/
git commit -m "feat: add profile UI component"

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. 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)