Use this skill when committing code changes, creating git commits, staging files for commit, or when the user asks to commit, save changes, or make a commit. Handles conventional commit format, explicit file staging, and commit message crafting.
Scanned 2/12/2026
Install to Claude Code
npx -y skills add gannonh/kata-agents --skill committing-changes --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Committing Changes?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/gannonh-committing-changes)More formats (shields.io, HTML) on the badges page.
---
name: committing-changes
description: Use this skill when committing code changes, creating git commits, staging files for commit, or when the user asks to commit, save changes, or make a commit. Handles conventional commit format, explicit file staging, and commit message crafting.
---
## Context
- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Recent commit messages (for style reference): !`git log --oneline -10`
- User-provided message override (optional): $ARGUMENTS
## Your task
Commit the work from this chat session using best practice conventions.
### Step 1: Identify Changed Files
Review the git status output above. Only stage files that were actually modified during this conversation. Do NOT use `git add -A` or `git add .` blindly.
### Step 2: Stage Files Explicitly
Add only the specific files that changed:
```bash
git add path/to/file1 path/to/file2
```
### Step 3: Craft the Commit Message
Follow conventional commits format:
- **feat**: New feature
- **fix**: Bug fix
- **refactor**: Code change that neither fixes nor adds
- **docs**: Documentation only
- **test**: Adding or updating tests
- **chore**: Maintenance tasks
Structure:
```
<type>(<scope>): <short description>
<optional body with details>
```
Guidelines:
- Keep the subject line under 72 characters
- Use imperative mood ("add" not "added")
- Focus on the "why" not just the "what"
- Reference any relevant context from the conversation
### Step 4: Create the Commit
If user provided a message override in $ARGUMENTS, use that instead of crafting one.
Use a HEREDOC for proper formatting:
```bash
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>
<optional body>
EOF
)"
```
### Step 5: Verify Success
After committing, run `git status` to confirm the commit succeeded.
## Important
- Never stage files that weren't part of this session's work
- Never commit secrets, credentials, or .env files
- If no changes exist to commit, inform the user instead of creating an empty commit
- You MUST complete all steps in a single response using parallel tool calls where appropriate
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!