Git Commit Skill#
Create a well-formed git commit by analyzing staged and unstaged changes.
Procedure#
- Inspect repository state (run in parallel):
git statusto see all untracked and modified files.git diff --cachedandgit diffto see staged and unstaged changes.git log --oneline -10to understand the commit message style of the repository.
- Analyze the changes:
- Classify the change type: new feature, enhancement, bug fix, refactoring, test, docs, chore.
- Identify files that should NOT be committed (secrets,
.env, credentials, large binaries). - If no changes exist, inform the user and do not create an empty commit.
- Stage relevant files:
- Prefer adding specific files by name rather than
git add -Aorgit add .. - Warn the user if any file appears to contain secrets.
- Prefer adding specific files by name rather than
- Draft the commit message:
- Follow the repository's existing commit message convention (conventional commits, imperative mood, etc.).
- Keep the subject line under 72 characters.
- Summarize the "why" rather than the "what".
- Add a body if the change is non-trivial.
- Create the commit:
- Use a HEREDOC to pass the message to ensure correct formatting.
- Never amend an existing commit unless the user explicitly requests it.
- Never use
--no-verifyor skip hooks unless the user explicitly requests it.
- Verify:
- Run
git statusafter committing to confirm success. - If a pre-commit hook fails, fix the issue, re-stage, and create a NEW commit.
- Run
Output#
Report what was committed, summarizing file changes and the commit message used.