# Committing Changes

> 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.

- Skill: `majiayu000/committing-changes` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/committing-changes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/committing-changes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/committing-changes

---


## 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