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:

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:

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:

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