| name | commit |
| description | Commits git changes by appropriately breaking them into atomic units. |
| llm-description | Use anytime the user asks to commit changes to the current repository. |
Make small, atomic commits with clear messages following Conventional Commits v1.0.
1. If you don't already understand the changes, review them first using the dedicated tools:
git -P diff --stat
git -P status
git -P diff
If needed run other batched more specific requests.
- Make small, atomic commits—each commit should address one logical change. If your work spans multiple concerns (e.g., a refactor and a bug fix), break it into separate commits.
- Follow this strict loop for each logical change:
git add <files-for-first-commit>
git commit -m "type(scope): description" -m "body"
git add <files-for-second-commit>
git commit -m "type(scope): description" -m "body"
IMPORTANT: Never stage all files at once before committing. Always follow the protocol.
For finer control, stage specific hunks:
git hunks list
git hunks add 'file:@-old,len+new,len'
<commit_message_format>
Follow Conventional Commits v1.0.
Title (first line):
- Format:
<type>[optional scope]: <description>
- Types:
feat, fix, docs, style, refactor, perf, test, build, ci, chore
- Limit to 60 characters maximum
- Use lowercase except for symbols or acronyms
- Use imperative mood ("add feature" not "adds feature")
- Add
! after type/scope for breaking changes: feat!: remove deprecated API
Body:
- Explain what the change does and why
- Use proper grammar and punctuation
- Use imperative mood throughout
Trailers:
- If fixing a ticket, add appropriate trailers
- If fixing a regression, add a "Fixes:" trailer with the commit id and title
- For breaking changes, add
BREAKING CHANGE: <description> trailer
</commit_message_format>