claude/skills/commit-change/SKILL.md

---

name: commit-change version: 1.0.0 description: | Analyze all changes since the last commit (staged, unstaged, untracked files) and create well-structured commits grouped by logical unit. Use this skill whenever the user says "commit my changes", "smart commit", "auto commit", "commit everything", "analyse et commit", or any variation of wanting to commit their pending work intelligently. Also trigger when the user has been working on multiple things and wants to create clean, atomic commits from their messy working directory. Works in any git repository. allowed-tools:

• Bash
• Read
• Grep
• Glob
• Agent
• AskUserQuestion ---

Git Smart Commit

Create clean, atomic commits from a messy working directory. The goal is to turn a pile of mixed changes into a well-organized git history that tells a clear story — each commit focused on one logical change.

Workflow

Phase 1: Gather context

Run these commands to understand the full picture:

git status
git diff                    # unstaged changes
git diff --cached           # staged changes  
git diff HEAD --stat        # summary of all changes vs last commit
git log --oneline -5        # recent commit style

Also check for untracked files that should be included. Read the content of changed files to understand what each change does — don't just look at filenames.

Phase 2: Analyze and group changes

Read the actual diffs and file contents to understand the intent behind each change. Group changes into logical commits based on:

• Purpose: what problem does this change solve or what feature does it add?
• Scope: files that work together toward the same goal belong together
• Type: separate concerns (a bug fix shouldn't be bundled with a new feature)

Common groupings:

• Feature code + its tests + its docs = one commit
• Config/dependency changes = separate commit
• Unrelated bug fixes = each gets its own commit
• Formatting/style changes = separate from logic changes

Phase 3: Present the plan

Before committing anything, present a clear plan to the user:

Proposed commits (in order):

1. fix(auth): handle expired tokens in refresh flow
   - src/auth/refresh.ts (modified)
   - src/auth/refresh.test.ts (modified)

2. feat(api): add pagination to /users endpoint  
   - src/routes/users.ts (modified)
   - src/routes/users.test.ts (new)

3. chore: update eslint config
   - .eslintrc.json (modified)

Ask the user to confirm, modify the grouping, or adjust commit messages before proceeding.

Phase 4: Execute commits

For each approved commit group, in order:

1. Stage only the files for that commit: git add <specific-files>
   • For partially changed files that belong to multiple commits, use git add -p is not available (interactive), so if a single file has changes belonging to different logical groups, mention it to the user and ask how they want to handle it (commit together, or split manually).
2. Create the commit with the agreed message
3. Verify with git status that the right files were committed

Commit message format

Follow Conventional Commits and match the repo's existing style:

<type>(<scope>): <short description>

<optional body — what and why, not how>

Co-Authored-By: Claude <noreply@anthropic.com>

Types: feat, fix, refactor, chore, docs, test, style, perf

Keep the first line under 72 characters. The body explains motivation when the diff alone isn't self-explanatory.

Edge cases

• No changes: tell the user there's nothing to commit
• Only staged changes: respect what's already staged — ask if the user wants to commit just those, or also include unstaged/untracked changes
• Merge conflicts: don't try to commit — tell the user to resolve first
• Large number of changes: still group logically, but warn the user if the working directory looks like it has many unrelated changes mixed together
• Single logical change: don't force multiple commits — one commit is fine if all changes serve the same purpose
• Sensitive files (.env, credentials, keys): warn the user and exclude them from commits by default