Git commit chunker

Git Commit Chunker

Organise the user's uncommitted changes into a sequence of clean, atomic commits with conventional commit messages, then push.

How to work

This skill is about performing real git operations, not describing them. Every git command in this workflow must be run through the Bash tool, and each decision you make must be based on the actual output that tool returns. If you write a command as text in your reply instead of invoking the tool, nothing happens on the user's machine and the workflow has failed. Never invent, predict, or paraphrase command output; if you have not seen real output for a command, you have not run it.

Work one stage at a time: run the inspection commands, read their real output, then decide on the commit plan. Do not announce a plan of numbered steps before doing anything; just start with the inspection and keep the user informed as real results come back.

Step 1: Inspect the current state

Using the Bash tool, run:

• git status to see all changed files
• git diff --cached to see staged changes
• git diff to see unstaged changes

Read the real output before continuing. If there are no changes at all, tell the user and stop. If the diffs are very large, git diff --stat is an acceptable first pass, drilling into individual files only where the category is unclear.

Step 2: Categorise the changes

Group the files you actually saw in Step 1 into logical categories:

Category	Typical files	Commit type
Documentation	README, markdown docs, API docs	docs:
Removals and cleanup	Deleted files, dead code	chore:
Reorganisation	Moves and renames	chore:
Configuration	Rules files, indexes, package.json, tsconfig, build configs	feat: if it adds functionality, otherwise chore:
Source code	New features feat:, restructuring refactor:, bug fixes fix:, performance perf:	varies
Build output	Generated JS, sourcemaps, dist/	build:
Tests	Test files, test data and output	test:

Group related changes together rather than creating many tiny commits, but never mix unrelated changes in one commit. Keep deletions separate from additions.

Step 3: Create the commits

Commit in this order, because later commits often depend on earlier ones (for example, config should land before the code that uses it):

1. Removals
2. Reorganisation (moves, renames)
3. Configuration
4. Core source changes
5. Dependency updates
6. Build output
7. Tests

For each group, invoke the Bash tool with a single command of the form:

git add <files> && git commit -m "type: description"

After each commit, check the tool's real output to confirm it succeeded before starting the next one. If a commit fails (for example a pre-commit hook rejects it), stop, show the user the actual error output, and resolve it with them before continuing.

Commit message rules

Format: <type>: <description> as a single line passed with -m. No heredocs, no multi-line messages, no commit body.

• Description is lowercase, no trailing full stop, under 72 characters
• Describe what changed, not why
• Never add Co-Authored-By lines or a "Generated with Claude Code" footer unless the user explicitly asks

Types: feat, fix, refactor, chore, build, test, docs, style, perf, ci.

Example 1 Change: new JWT login flow in src/auth.ts Message: feat: implement jwt authentication

Example 2 Change: deleted deprecated src/legacy-auth.ts Message: chore: remove deprecated auth module

Step 4: Push

Once all commits are created, run git branch --show-current to confirm the branch, then push with git push origin <branch> via the Bash tool. Verify from the real output that the push succeeded and report the result to the user. If the push is rejected (for example the remote is ahead), show the user the actual error and ask how they want to proceed rather than force-pushing.

Customisation

The user can adjust the workflow by saying:

• "Don't push" to skip Step 4
• "Add descriptions" to include commit body text (multi-line is then allowed)
• "Add co-author" to include Claude attribution
• "Squash X and Y" to combine specific changes into one commit

Troubleshooting

Nothing to commit: git status shows a clean tree. Tell the user there are no uncommitted changes and stop.

Detached HEAD or no upstream: confirm the intended branch with the user before pushing; use git push -u origin <branch> for a new branch only after they confirm.

Hook failures: show the real hook output and fix the underlying issue with the user; do not bypass hooks with --no-verify unless explicitly asked.