| name | default-commit |
| description | Commit changes by splitting into logical units. Defaults to Conventional Commits but adapts to the repo's existing format if consistently different. Auto-detects commit message language from git history. |
| argument-hint | [short] [co] [single] [one] |
| model | sonnet |
Commit Changes
Commit changes from HEAD by splitting them into logical commits.
User directive: $ARGUMENTS
Options
| Keyword | Rule |
|---|
| short | Title-only commit messages without body. |
| co | Include Co-Authored-By trailer. |
| single | Create a single commit without splitting. |
| one | Commit only one of the split changes. |
Process
1. Unstage all currently staged files
To avoid accidentally including unwanted changes:
git reset
2. Undo WIP commit if present
If the previous commit message starts with WIP, undo it:
git reset HEAD~1
3. Review diff for false positives
Run git diff and check for unintended changes unrelated to the task:
- Formatting-only changes (whitespace, trailing commas, line breaks)
- Unrelated import additions/removals
- Auto-generated file modifications not relevant to the task
Revert any such changes before proceeding using git checkout -- <file> or git restore -p.
4. Check for documentation gaps
Review the changes and verify that related documentation is up to date:
- README, CLAUDE.md, or other docs that reference changed behavior
- Inline comments that describe logic which has been modified
- Configuration examples if defaults or options have changed
Update any stale documentation before proceeding.
5. Determine commit message language and format
Run git log --oneline -20 and analyze recent commit messages for:
- Language: Detect the dominant language. Use it for new commits. User directives take precedence.
- Format: Check whether commits consistently follow a non-Conventional format (e.g., no
type: prefix, capitalized sentences, emoji prefixes, ticket-ID prefixes). If a clear, consistent pattern exists, adopt that format instead of Conventional Commits.
6. Split and commit
Split changes into logical units by type and scope.
If the repo uses Conventional Commits (or has no consistent alternative):
- type:
feat, fix, docs, style, refactor, perf, test, chore
refactor: Use only when the change has zero effect on user-facing behavior (no API, CLI, UI, or output changes). If any external behavior changes, use feat, fix, or another appropriate type instead.
- scope: The feature or area affected (e.g.,
utils, api, web, cli)
Commit Message Format
Default: Follow Conventional Commits, unless step 5 detected a different consistent format in the repo history.
Subject line (Conventional Commits default)
- Imperative mood:
fix: resolve memory leak (not resolved / resolves)
- Lowercase after type:
feat: add parser (not Add)
- No trailing period
- Max 72 characters
Subject line (repo-specific format)
If the repo uses a different consistent format, mirror its conventions for capitalization, prefixes, punctuation, and structure.
Body
Explain why this change was made, what problem it solves, and how it affects the system.
Granularity
- One commit, one purpose — don't mix features with fixes or unrelated refactoring
- Each commit should be self-contained and buildable
