commit

name	commit
description	This skill should be used when the user asks to "commit my changes", "create a commit", "commit this", "make a commit", "git commit", or otherwise requests creating a git commit from current changes.

Git Commit

Create a well-crafted git commit from the current working tree changes.

Workflow

1. Gather Context

Run all four commands to understand the current state:

• git status — see tracked/untracked files
• git diff HEAD — see all staged and unstaged changes
• git branch --show-current — identify current branch
• git log --oneline -10 — match existing commit message style

2. Check Agent Docs

If the project has an AGENTS.md or CLAUDE.md, review it against the current changes. If changes introduce new conventions, commands, architecture, or patterns that should be documented (or invalidate existing docs), update the relevant file as part of this commit. Only update if clearly warranted — avoid adding noise.

Things worth documenting:

• Non-obvious conventions or patterns not apparent from code structure alone
• Surprising behaviors, gotchas, or workarounds discovered during development
• Implicit dependencies or ordering constraints between components
• Environment-specific quirks (platform differences, tool version sensitivities)
• Undocumented requirements or constraints found through trial and error

3. Branch Safety

If the user asks to commit on a new branch, first inspect the current branch.

• If on main, master, or the repository's default/protected branch, create a new branch with git checkout -b <descriptive-name>. Never rename these branches.
• Only use git branch -m <descriptive-name> when already on a non-main branch whose name appears generated, random, or unrelated to the current work, such as UUIDs, hex strings, meaningless sequences, or 1-3 unrelated words.
• If the branch name is meaningful or user-provided, keep it.

4. Create the Commit

Stage all relevant changes and create a single commit with a conventional commit message (e.g., feat:, fix:, refactor:). Lead the message with why over what — the diff shows what changed; the message explains motivation and purpose. The commit body should start with the reason for the change; technical overview and implementation notes come after. Make the problem, context, or reason for the change clear before describing implementation details when that reason is supported by the available evidence. If the rationale is unclear, do not guess; ask the user.

If the reason behind a change is not clear from context, ask the user before committing.

Never stage or commit files ignored by git unless the user explicitly asks. Do not use git add -f, git add --force, or equivalent to include ignored files.

Staged-Only Mode

When asked to commit only staged changes:

1. Run git diff --staged to see exactly what is staged
2. Base the commit message solely on those changes
3. Do NOT stage additional files

Guidelines

• Prefer conventional commits format, but defer to project conventions
• Pass commit messages via a heredoc to avoid shell interpretation of backticks and other special characters in multi-line messages
• Minimize text output — focus on tool calls
• Call multiple tools in parallel when there are no dependencies between them
• Treat .gitignore and other git exclude rules as authoritative for default commit scope