commit

name	commit
description	Create git commits with no Claude attribution. NEVER adds co-author information—commits appear as if user wrote them. Use when user asks to "commit", "make a commit", save work to git, says "wrap up" or "finish" after completing work, asks "what's next?" or "are we done?" after coding, or mentions staging changes or commit messages.

Commit Changes

Create clean, professional git commits that appear as if the user wrote them directly. No AI attribution, no co-author tags, no "generated by" messages.

Process

1. Assess Changes

• Review the entire conversation context to understand the full scope of work done
• Run git status to see all modified, added, and deleted files
• Run git diff (and git diff --staged if applicable) to see actual changes
• Determine if changes should be grouped into one commit or split into multiple logical commits
• Consider the semantic relationship between changes (related features, fixes, refactors)

2. Plan Commits

• Group related files logically by feature, fix, or refactor
• Draft commit messages in imperative mood (e.g., "Add feature" not "Added feature")
• Focus messages on why the change matters, not just what changed
• Keep commits atomic and focused on a single logical change
• If multiple unrelated changes exist, plan separate commits for each
• Follow conventional commit format if the project uses it (check recent git log)

3. Execute Commits

• Use git add with specific file paths (NEVER use -A, ., or --all)
• Create each commit with the planned message
• After all commits, show results with git log --oneline -n [number]
• Confirm completion: "Created [N] commit(s)"

Critical Rules

Attribution Rules (NEVER VIOLATE THESE):

• NO co-author information of any kind
• NO "Generated with Claude" or similar messages
• NO "Co-Authored-By" lines
• NO AI attribution in commit messages or metadata
• Write messages as if the user wrote them directly

Commit Quality Rules:

• Always use specific file paths with git add, never wildcards or "add all"
• Imperative mood for commit messages (e.g., "Fix bug" not "Fixed bug")
• Focus on why, not just what (e.g., "Fix race condition in auth" not "Update auth.py")
• Keep commits atomic - one logical change per commit
• Review conversation context fully before planning commits

Execution Rules:

• Execute commits immediately without asking for permission
• Briefly inform the user what commits were created after completion
• Split unrelated changes into multiple atomic commits automatically
• Use best judgment for commit organization based on change context

Sub-Agent Recommendations

This skill does NOT require sub-agents. Execute directly because:

• Commits require conversation context that sub-agents don't have access to
• Git operations are straightforward and don't require specialized reasoning