---
name: auto-commit
description: Analyze git status, batch commit changes by logical groups, and push to remote. No co-author or AI attribution info. Use when the user says "auto commit", "batch commit", "commit and push", or triggers /auto-commit.
---

# Auto Commit

Automatically analyze git working tree, group changes into logical batches, commit each batch with a concise message, and push to remote. No Co-Authored-By or any AI attribution is added.

## When to Use

- User says "auto commit", "batch commit", "commit and push", "提交代码", "自动提交"
- User triggers `/auto-commit`

## Workflow

### Step 1: Analyze Git Status

Run these commands in parallel to understand the current state:

```bash
git status --short
git diff --stat
git diff --cached --stat
git log --oneline -5
git branch --show-current
```

### Step 2: Identify Logical Groups

Analyze all changed files (staged + unstaged + untracked) and group them by logical concern. Common grouping strategies:

1. **By module/feature**: Files that belong to the same feature or module go together
2. **By type of change**: Schema changes, service changes, UI changes, config changes, etc.
3. **By dependency**: If file A depends on changes in file B, they should be in the same commit

Typical groups (adapt based on actual changes):
- `convex/schemas/` changes → schema/type commits
- `convex/repositories/` + `convex/services/` → backend logic commits
- `convex/*.ts` (functions layer) → API layer commits
- `src/components/` → UI component commits
- `src/routes/` → route/page commits
- Config files (`package.json`, `tsconfig.json`, `vite.config.ts`, etc.) → config commits
- Test files → test commits
- Migration files → migration commits

### Step 3: Exclude Other People's Changes

**CRITICAL**: Before committing, check `git status` carefully:
- Only commit files that are part of the current user's work
- If there are files that appear to be from other people's branches or unrelated work, **skip them**
- Do NOT `git restore` or `git checkout` other people's files — leave them as-is
- Do NOT use `git add -A` or `git add .` — always add specific files by name

### Step 4: Batch Commit

For each logical group, use `&&` to chain the `git add` and `git commit` commands in a single Bash call, ensuring they run sequentially and stop on failure:

```bash
git add <file1> <file2> ... && git commit -m "$(cat <<'EOF'
type(scope): short description
EOF
)"
```

Message format:

```
<type>(<scope>): <short description>
```

Where `type` is one of: `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `perf`, `style`, `build`, `ci`

**IMPORTANT**:
- **Always use `&&` to chain sequential commands** in one Bash call (e.g. `git add ... && git commit ...`). Do NOT make separate Bash calls for `git add` and `git commit` — they must be in the same call connected by `&&`
- Do NOT add `Co-Authored-By` or any AI attribution
- Do NOT add `--no-verify` or skip any hooks
- Commit message should be in English, concise (under 72 chars for subject line)
- Use HEREDOC format for commit messages to ensure proper formatting

### Step 5: Push and Summary

After all commits are made, push and then log in one chained command:

```bash
git push && git log --oneline -<N>
```

If the branch has no upstream:

```bash
git push -u origin <current-branch> && git log --oneline -<N>
```

(where N = number of commits just made)

Present a summary table:

| Commit | Files | Description |
|--------|-------|-------------|
| abc1234 | 3 | feat(auth): add login validation |
| def5678 | 2 | fix(ui): correct button alignment |

## Rules

1. **Chain commands with `&&`**: Always use `&&` to chain sequential git commands in a single Bash call (e.g. `git add file1 file2 && git commit -m "msg"`). Never split dependent commands into separate Bash calls
2. **No AI attribution**: Never add `Co-Authored-By`, `Generated by`, or any similar metadata
3. **No destructive operations**: Never use `git reset --hard`, `git checkout .`, `git clean -f`, or `git push --force`
4. **Specific file staging**: Always `git add` specific files, never `git add -A` or `git add .`
5. **Respect hooks**: Never use `--no-verify`
6. **Don't touch others' work**: If files from other people's work are in the working tree, leave them alone
7. **Skip sensitive files**: Never commit `.env`, credentials, secrets, or API keys
8. **Empty state**: If there are no changes to commit, inform the user and stop
9. **Single-concern commits**: Each commit should address one logical concern
10. **Verify success**: After each commit, verify it succeeded before proceeding to the next