process-commit_skill

Overview

This skill automates splitting a large working diff into logical, atomic commits before creating a PR. It analyzes patch hunks, groups related changes, and runs git-sequential-stage to stage only the hunks that belong in each commit. The goal is clear, review-friendly commits that map to single intents like bugfix, refactor, or docs update.

How this skill works

It collects the current diff into a patch file, counts and inspects hunks per file, and decides which hunks belong in the next commit based on semantic grouping. The skill then invokes git-sequential-stage with explicit hunk selectors (or wildcards when appropriate) to stage those changes and runs git commit with the prepared message. Repeat until the working diff is fully split into planned commits.

When to use it

• Before opening a pull request that contains multiple unrelated changes
• When a working tree has large diffs that should be split into logical commits
• When you want deterministic, hunk-level control over what goes into each commit
• When preparing a changelog or separate tests/docs updates from code changes

Best practices

• Run from the repository root and create a patch file (git diff HEAD > .claude/tmp/current_changes.patch) before analysis
• Group hunks by intent (bugfix, feature, refactor, test, docs) rather than by file alone
• Prefer explicit hunk lists; use wildcards only for full-file, single-intent changes (new files or entire-file refactors)
• Keep each commit small and self-contained with a clear commit message
• Count hunks and review their content before staging to avoid accidental mixing of intents

Example use cases

• Separate a bugfix in one function from an unrelated refactor in another file into two commits
• Stage and commit unit test additions separately from implementation changes
• Create a single commit for documentation updates across multiple files using wildcards
• Split a large feature change into multiple logical commits: core logic, helper utilities, and tests