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:

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:

By module/feature: Files that belong to the same feature or module go together
By type of change: Schema changes, service changes, UI changes, config changes, etc.
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:

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:

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

If the branch has no upstream:

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

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
No AI attribution: Never add Co-Authored-By, Generated by, or any similar metadata
No destructive operations: Never use git reset --hard, git checkout ., git clean -f, or git push --force
Specific file staging: Always git add specific files, never git add -A or git add .
Respect hooks: Never use --no-verify
Don't touch others' work: If files from other people's work are in the working tree, leave them alone
Skip sensitive files: Never commit .env, credentials, secrets, or API keys
Empty state: If there are no changes to commit, inform the user and stop
Single-concern commits: Each commit should address one logical concern
Verify success: After each commit, verify it succeeded before proceeding to the next

auto-commit