| name | git-commit |
| description | Create logically grouped, atomic git commits with well-formatted commit messages following best practices. Use when user says "/commit", "commit changes", "create commits", asks about conventional commits format, needs to split changes into multiple commits, or wants help with git add -p partial staging. |
| allowed-tools | ["Bash(git:*)","Read","Edit"] |
Git Commit Skill
This skill helps you create well-structured, atomic git commits with properly formatted commit messages.
Task Overview
Based on the current git status and changes, create a set of logically grouped, atomic commits.
Be specific with each grouping, and keep scope minimal. Leverage partial adds to
make sure that multiple changes within a single file aren't batched into
commits with unrelated changes.
Process
-
Analyze Current State
- Run
git status and git diff HEAD to see all staged and unstaged changes
- Check recent commits (
git log --oneline -20) to learn the project's commit style: whether it uses conventional commits (e.g., feat:, fix:, docs:), typical subject line length, capitalization, and formatting
-
Group Changes Logically
- Identify related changes that should be committed together
- Separate unrelated changes into different commits
- Use
git add -p for partial adds when a file contains multiple logical changes
-
Create Commits
- Stage the appropriate changes for each commit
- Write commit messages following the best practices below, matching the project's style
- Verify each commit with
git show
- After all commits, run
git status to confirm nothing was missed
Commit Message Format Detection
- If 80% or more of recent commits follow conventional commits, use that format
- Match the capitalization, punctuation, and structure of existing commits — consistency matters more than personal preference
Conventional Commits Format
If the project uses conventional commits, follow this structure:
<type>[(optional scope)]: <description>
[optional body]
[optional footer(s)]
Common types:
feat: A new feature
fix: A bug fix
docs: Documentation changes
style: Code style changes (formatting, missing semicolons, etc.)
refactor: Code changes that neither fix bugs nor add features
perf: Performance improvements
test: Adding or updating tests
build: Changes to build system or dependencies
ci: Changes to CI configuration
chore: Other changes that don't modify src or test files
Examples:
feat: add user authentication
fix: resolve null pointer in login handler
docs: update API documentation
refactor(auth): simplify token validation logic
Git Commit Message Best Practices
Follow these seven rules for excellent commit messages (adjust for conventional commits if used):
- Separate subject from body with a blank line - Critical for readability
- Limit subject line to 50 characters - Forces concise summaries
- Capitalize the subject line - Consistent formatting
- Do not end subject line with a period - It's a title, not a sentence
- Use imperative mood in subject - "Add feature" not "Added feature"
- Test: Subject should complete "If applied, this commit will _____"
- Wrap body at 72 characters - Ensures readability in terminals
- Use body to explain what and why vs. how - Code shows how, commit explains why
Message Structure
<subject: concise summary, imperative, capitalized, no period>
<body: explain the motivation for the change and contrast with previous behavior>
<footer: references to issues, breaking changes, etc.>
Key Principles
- Atomic commits: Each commit should represent one logical change
- Context is king: Explain why the change was made, not just what
- Future-proof: Write for someone (including future you) reading this months later
- Consistency: Maintain uniform style across the project
Examples
Good Examples (Traditional Style):
Refactor subsystem X for readability
Remove deprecated methods from UserService
Fix null pointer exception in login handler
Add user authentication middleware
Good Examples (Conventional Commits):
feat: add user authentication middleware
fix: resolve null pointer exception in login handler
refactor: improve subsystem X readability
chore: remove deprecated methods from UserService
Bad Examples:
fixed stuff
Changes
wip
Update file.js
feat added new feature (incorrect format - missing colon)
Reference Documentation
For detailed information on conventional commits, see:
Notes
- Don't push to remote unless explicitly asked
- Verify authorship and commit details before amending