Git Commit Assistant
Analyze git changes and create logical, well-structured commits using conventional commit format.
When to Use
-
User asks to commit changes
-
Multiple unrelated changes need separate commits
-
Changes need conventional commit formatting
Workflow
Step 1: Review Current State
Run git status to see all changes:
git status
Review both staged and unstaged changes. Identify modified, added, and deleted files.
Step 2: Analyze and Plan Commits
Group changes into logical commits based on:
-
Feature boundaries: Files that implement the same feature together
-
Type of change: Separate fixes from features from refactors
-
Scope: Group by component, module, or area of the codebase
Present the commit plan to the user before proceeding:
I see the following logical commits:
- feat(auth): Add password reset - auth/reset.rb, auth/mailer.rb
- fix(api): Handle null responses - api/client.rb
- docs: Update README - README.md
Step 3: Execute Commits One by One
For each planned commit:
Stage specific files only:
git add <file1> <file2>
Verify staging:
git status
Create commit with conventional format:
git commit -m "<type>[scope]: <description>" -m "<body>"
Verify commit succeeded:
git status
Only proceed to the next commit after verifying the current one completed.
Conventional Commit Types
Type Description
feat New feature
fix Bug fix
docs Documentation only
style Formatting, no code change
refactor Code change, no new feature or fix
perf Performance improvement
test Adding or fixing tests
chore Build process, auxiliary tools
Commit Message Format
<type>[optional scope]: <description>
[optional body]
[optional footer]
-
Description: Imperative mood, lowercase, no period ("add feature" not "Added feature.")
-
Body: Explain what and why, not how
-
Scope: Component or area affected (auth, api, db, ui)
Rules
-
Never mix unrelated changes in a single commit
-
Always verify staging before committing
-
Always verify success after committing
-
Explain the plan before executing
-
Never use git add . or git add -A without explicit approval
-
Never include "Generated with Claude Code" or Co-Authored-By footers
Example Session
$ git status
Modified: auth/login.rb, auth/signup.rb, README.md, api/client.rb
Plan:
- feat(auth): Improve login validation - auth/login.rb, auth/signup.rb
- fix(api): Handle timeout errors - api/client.rb
- docs: Add authentication guide - README.md
Executing commit 1... $ git add auth/login.rb auth/signup.rb $ git status # verify only auth files staged $ git commit -m "feat(auth): improve login validation" -m "Add email format check and rate limiting" $ git status # verify commit succeeded
Executing commit 2... [continues...]