Commit Skill

Create semantically correct, granular git commits by analyzing staged and unstaged changes.

Auto-staging: All tracked changes are staged automatically. Use --dry-run to preview first.

Model

Use haiku for all operations unless complex reasoning is required.

Arguments

• (none): Auto-commit without confirmation
• -v or --verify: Show plan and ask for confirmation before committing
• --dry-run: Show commit plan without executing
• --amend: Amend last commit (always requires -v verification for safety)
• push: After committing, push to current remote branch
• push -v / push --verify: Push with verification prompt

Workflow

1. Check for merge conflicts – abort if found
2. Check current branch – warn if committing to main/master
3. Run git status and git diff to understand current changes
4. Run git diff --cached to see already staged changes
5. Analyze changes and group them logically
6. Create atomic commits with clear messages
7. If push argument: push to remote

Grouping Strategy

Prefer more commits over fewer. Group by:

• Feature/functionality: Related changes that implement one thing
• File type: Config changes, test files, types, etc.
• Scope: Single module/component changes together
• Nature: Refactors separate from features separate from fixes

Never combine unrelated changes. When in doubt, split.

Commit Message Format

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

Types

• feat: New feature
• fix: Bug fix
• refactor: Code restructuring without behavior change
• chore: Maintenance, deps, config
• docs: Documentation only
• test: Adding/updating tests
• style: Formatting, whitespace
• perf: Performance improvement

Rules

• Subject line: max 72 chars, imperative mood, no period
• Body: only if necessary to explain why, not what
• No body for obvious changes (typos, simple additions, config tweaks)

Good Examples

feat(auth): add JWT refresh token rotation
fix(api): handle null response from payment provider
refactor(utils): extract date formatting helpers
chore: upgrade typescript to 5.4
test(cart): add edge cases for discount calculation

Execution Steps

1. Check safety: Detect conflicts, warn on protected branches (main/master)
2. Analyze: git diff --stat and git diff for full context
3. Plan: Determine commit groups with files and messages
4. Verify (if -v/--verify/--dry-run/--amend): Show plan, wait for confirmation
   • --dry-run: Exit after showing plan
   • --amend: Modify last commit instead of creating new
5. Execute: For each commit:

   git add <files>
   git commit -m "<message>"
   # or for --amend:
   git add <files>
   git commit --amend -m "<message>"
   

6. Push (only if push argument): Run git push origin HEAD
   • On failure: show git error, stop (user handles manually)

Example Session

User: /commit

Claude: Analyzing 7 changed files...

✓ feat(api): add user preferences endpoint
  - src/routes/preferences.ts, src/types/preferences.ts

✓ test(api): add preferences endpoint tests
  - tests/preferences.test.ts

✓ chore: add zod dependency
  - package.json, package-lock.json

4 commits created.

With -v: Shows plan, asks “Proceed? (y/n/edit)” before executing

With --dry-run: Shows plan, exits without executing

With --amend -v: Shows plan to amend last commit, asks for confirmation

With push: Adds “Pushing to origin/main… ✓ Pushed successfully.” at end

Edge Cases

• Protected branches: Warn if committing directly to main/master
• Merge conflicts: Abort and instruct user to resolve first
• Single file: Still analyze if it contains multiple logical changes
• Large refactors: May warrant a single commit if truly atomic
• Mixed changes: Always split features from fixes from refactors
• Already staged files: Respect existing staging, offer to commit separately or include