name: commit description: ALWAYS use this skill when creating any git commit, when user asks to commit work, or after completing a task. This skill is MANDATORY for all commits. allowed-tools: Bash(git status:), Bash(git diff:), Bash(git log:), Bash(git add:), Bash(git commit:), Bash(git commit --amend:) model: claude-sonnet-4-5-20250929

Git Commit Instructions

Create one or more git commits, splitting logically distinct changes into separate commits.

Workflow

1. Run git status to check the current branch
2. Run git diff, git diff --staged, and git log --oneline -5 to review changes
3. Analyze and categorize each changed file (see categories below)
4. For each category with changes, stage those files and create a focused commit
5. After each commit, run git log --oneline -1 to verify commit was created correctly

Change Categories (each gets its own commit)

Separate commits when changes span multiple categories:

• Refactor: Code restructuring without behavior change (rename, extract, reorganize)
• Feature: New functionality or capabilities
• Fix: Bug fixes
• Test: Adding or updating tests
• Config: Configuration, build, or dependency changes
• Docs: Documentation updates
• Style: Formatting, whitespace (only if significant)

Multi-Commit Process

When changes span categories:

1. Group files by category based on the nature of changes
2. Stage files for first category: git add <file1> <file2>
3. Commit with category-appropriate message
4. Repeat for remaining categories
5. Use git status between commits to track progress

Example for a refactor + feature change:

git add src/parser/utils.ts
git commit -m "Extract parsing helpers into utils module"
git add src/parser/newFeature.ts src/parser/index.ts
git commit -m "Add support for parsing fleet compositions"

Commit Message Rules

Format:

{task-type}: brief description of the big picture change

- Optional bullet points for complex changes
- Focus on additional context if needed

Task types: feat, fix, refactor, docs, style, test, build, chore

Guidelines:

• Focus on "why" and "what", not implementation details
• First line should be concise (50 chars or less)
• For complex changes, add bullet points after a blank line
• No emojis, no attribution lines, no "Generated with Claude Code", no "Co-Authored-By"

When to Combine (single commit is OK)

• All changes are tightly coupled to one logical change
• Splitting would create commits that don't stand alone

When NOT to Split

Keep these together in a single commit:

• Code and its tests - A new function and its unit tests belong together
• Interface and implementation - Type definitions and the code implementing them
• Refactor that enables a feature - If you refactored to make a feature possible, and then added the feature, that's one logical change
• Multi-file changes for one feature - Adding an API endpoint that touches router, service, and model files

Rule of thumb: If reverting one part without the other would leave the codebase broken or inconsistent, they belong in the same commit.

Amending Commits

Use git commit --amend when ALL of these conditions are met:

• The previous commit was created by you in the current session
• The commit has NOT been pushed to remote (verify with git status)
• The change is a small fixup to the previous commit (typo, missed file, formatting fix)
• You are on a feature branch (never amend on main/master)

Do NOT amend if:

• The commit was made by another developer
• The commit has been pushed to remote
• The change is logically distinct (create a new commit instead)