Git Commit Workflow
When the user asks to create a commit:
- Run
shellwithgit statusto see what files are staged and unstaged. - Run
shellwithgit diff --cachedto see the exact changes that will be committed. - Run
shellwithgit log --oneline -5to understand the repo's commit message style. - Analyze the staged changes and draft a commit message:
- Summarize the nature of the change (new feature, bug fix, refactor, etc.)
- Keep it concise: 1-2 sentences focusing on why, not what
- Match the repo's existing commit message style
- Do not commit files that likely contain secrets (
.env,credentials.json, API keys). Warn the user if such files are staged. - Show the proposed commit message to the user and ask for confirmation before running
git commit. - Stage any requested files with
git add <specific files>(never usegit add -Aorgit add .).
Commit Message Format
If the repo doesn't have a clear style, use:
<type>: <concise description>
<optional body explaining why>
Where type is: fix, feat, refactor, test, docs, chore.