Git Commit

---
name: git-commit
description: Commit staged changes with conventional commit message. Use when user says "commit changes", "commit this", "save my changes", or wants to create a git commit.
dependencies: []
---

# Git Commit

Create a commit with a conventional commit message based on staged changes. Automatically stages all changes and analyzes the diff to generate an appropriate commit message.

## Workflow

Execute these steps in order.

---

### Step 1: Check Repository State

Check for changes to commit:

```bash
git status --porcelain
```

- If output is empty, report: "Nothing to commit. Working directory is clean." and stop.
- If changes exist, continue to Step 2.

---

### Step 2: Stage All Changes

Stage all changes including untracked files:

```bash
git add .
```

Report: "Staged all changes."

---

### Step 3: Analyze Changes

View the staged diff to understand what changed:

```bash
git diff --cached --stat
```

```bash
git diff --cached
```

Analyze the diff to determine:
- The type of change (feat, fix, docs, refactor, etc.)
- The scope (optional, based on affected files/modules)
- A concise description of what changed

---

### Step 4: Construct Commit Message

Build a conventional commit message following this format:

```
<type>(<optional-scope>): <description>

[optional body]
```

**Types:**
- `feat` - New feature
- `fix` - Bug fix
- `docs` - Documentation only
- `style` - Formatting, no code change
- `refactor` - Code restructuring without behavior change
- `test` - Adding or updating tests
- `chore` - Maintenance tasks
- `build` - Build system or dependencies
- `ci` - CI configuration
- `perf` - Performance improvement

**Rules:**
- Use imperative mood ("add" not "added")
- Use lowercase
- No trailing period
- Keep description under 72 characters
- Add a body only for complex changes or breaking changes
- Do NOT add co-author, attribution, or "Generated with" lines

---

### Step 5: Create Commit

Create the commit using a heredoc for proper formatting:

```bash
git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"
```

---

### Step 6: Handle Result

**On success:**
- Report the commit hash: "Committed: {short_hash} - {message}"

**On pre-commit hook failure:**
- Report: "Pre-commit hook failed. The commit was NOT created."
- Explain what the hook reported
- Instruct: "Fix the issues above and run the commit command again. Do NOT use --amend as that would modify the previous commit."

---

## Error Recovery

If the commit fails:
- **Hook failure**: Fix the reported issues, then stage and commit again (do NOT amend)
- **Unstage changes**: `git reset HEAD` to unstage without losing changes

## Notes

- This command stages ALL changes including untracked files
- Pre-commit hooks run automatically; their failures mean no commit was created
- Always create a NEW commit after hook failure, never amend the previous commit

## Integration Notes

**What this component does:** Automates git commit creation by staging all changes, analyzing the diff, generating a conventional commit message, and handling pre-commit hook failures gracefully.

**Capabilities needed:**
- Shell command execution (git commands: `status`, `add`, `diff`, `commit`, `reset`)
- Text analysis (diff interpretation to determine commit type and scope)

**Adaptation guidance:**
- The workflow assumes a standard git repository is available in the working directory.
- Pre-commit hook handling is git-native and requires no platform-specific adaptation.
- The conventional commit format (type/scope/description) is a widely adopted standard; no changes needed for cross-platform use.
- If the target platform restricts shell access, the git commands in Steps 1-3 and Step 5 must be mapped to equivalent git API calls.