commit
Stage, commit, and push changes to the current branch. Use when asked to commit changes, push code, or after completing a task.
When & Why to Use This Skill
This Claude skill automates the Git version control workflow by staging changes, generating standardized conventional commit messages, and pushing code to remote repositories. It streamlines the development lifecycle by ensuring that code changes are documented and synchronized efficiently while adhering to repository best practices and safety standards.
Use Cases
- Automated Task Completion: Use this skill to automatically stage, commit, and push code to a remote branch immediately after finishing a programming task or bug fix.
- Standardizing Repository History: Maintain a clean and professional project log by automatically generating 'Conventional Commits' (feat, fix, chore) that explain the 'why' behind changes.
- Safe Code Deployment: Ensure secure version control by utilizing built-in safety checks that prevent the accidental committing of secrets, environment variables, or unauthorized force-pushes.
- Workflow Integration: Bridge the gap between AI-generated code and remote collaboration platforms like GitHub or GitLab, allowing for seamless handoffs in agentic coding workflows.
| name | commit |
|---|---|
| description | Stage, commit, and push changes to the current branch. Use when asked to commit changes, push code, or after completing a task. |
| allowed-tools | Bash |
Commit and Push
Stage all changes, create a commit with a conventional commit message, and push to the remote.
Instructions
- Run
git statusto see what files have changed - Run
git diffto understand the changes (both staged and unstaged) - Run
git log --oneline -5to see recent commit message style - Stage relevant files with
git add - Create a commit with a descriptive message following conventional commits format
- Push to the current branch
Important: Git Identity
Do NOT modify the git author or add Co-Authored-By headers. The commit should use the user's existing git configuration (their name and email from git config user.name and git config user.email).
Commit Message Format
Use conventional commits style observed in the repository:
feat:for new featuresfix:for bug fixeschore:for maintenance tasksrefactor:for code refactoringdocs:for documentation changes
Keep subject line under 72 characters. Focus on the "why" rather than the "what".
Commit Command Format
Always use a HEREDOC to ensure proper formatting:
git commit -m "$(cat <<'EOF'
<type>: <description>
<optional body explaining why>
EOF
)"
Safety Rules
- NEVER commit files that contain secrets (.env, credentials.json, etc.)
- NEVER use
--forceor--no-verifyunless explicitly requested - NEVER amend commits that have been pushed to remote
- NEVER modify git config (user.name, user.email, etc.)
- If pre-commit hooks fail, fix the issues and create a NEW commit
Push
After committing, push to the current branch:
git push origin HEAD
If the branch doesn't have an upstream, use:
git push -u origin HEAD