Commit 37

---
name: commit
description: Analyze unstaged and staged changes, suggest atomic commit groups with conventional commit messages. NEVER pushes to remote.
license: MIT
compatibility:
  - vcs:git
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash(git:status)
  - Bash(git:diff)
  - Bash(git:log)
  - Bash(git:add)
  - Bash(git:commit)
metadata:
  author: thoreinstein
  version: 1.0.0
---

# Commit

Analyze unstaged changes and organize them into atomic, well-documented commits.

## When to Use This Skill

- After completing work that spans multiple logical changes
- When working tree has mixed changes (features, fixes, refactors)
- To ensure clean, reviewable git history
- Before creating a pull request

## Workflow

1. **Analyze current state:**
   - Check `git status` to see all staged and unstaged changes
   - Review `git diff` to understand what changed

2. **Group changes into atomic units:**
   - Each group should represent one logical change (feature, fix, refactor, docs, etc.)
   - Group related files and hunks together
   - Keep changes that depend on each other in the same commit or note the dependency

3. **For each group, provide:**
   - List of files/hunks to stage
   - Commit message following project conventions
   - Brief rationale for the grouping

4. **Note dependencies:**
   - If commits must be applied in a specific order, document this
   - Identify any commits that could be applied independently

5. **Execute commits:**
   - Stage and commit each group in the appropriate order
   - Proceed unless there are questions or ambiguities

## Optional Focus

You can provide a focus to filter which changes to consider:

- `"frontend only"` - only consider frontend-related changes
- `"exclude tests"` - skip test file changes
- `"api changes"` - focus on API-related files
- Any other relevant filter for the codebase

## Constraints

- **NEVER push to remote** - this skill only creates local commits
- **Atomic commits** - each commit should be a single logical unit that could be reverted independently
- **Respect project conventions** - match existing commit message style in the repository
- **Ask before proceeding** - if grouping is ambiguous, ask for clarification rather than guessing

## Examples

### Example: Mixed Working Tree

**Situation:** Working tree has changes to API handler, its tests, a bug fix in an unrelated util, and a README update.

**git status output:**
```
modified:   internal/api/users.go
modified:   internal/api/users_test.go
modified:   internal/util/strings.go
modified:   README.md
```

**Proposed commit groups:**

**Group 1: Bug fix (independent)**
```
Files: internal/util/strings.go
Message: fix: handle empty string edge case in TrimSafe

Rationale: Standalone fix, no dependencies on other changes
```

**Group 2: Feature (with tests)**
```
Files: internal/api/users.go, internal/api/users_test.go
Message: feat: add email validation to user creation endpoint

Rationale: Handler and its tests belong together as one logical unit
```

**Group 3: Documentation (independent)**
```
Files: README.md
Message: docs: add API usage examples

Rationale: Documentation update, independent of code changes
```

**Suggested order:** Group 1 → Group 2 → Group 3 (no strict dependencies)

---

Begin by running git status and git diff to analyze the current working tree state.