Git Commit

Batch changes into logical commits following best practices.

[GOAL]

Review git diff, batch changes into logical commits, and commit them safely one at a time.

[CONTEXT]

May be run alongside other agents changing code. Prioritizes data safety and atomic operations.

[PROCESS]

1. Review changes

•Run git status and git diff to understand all changes
•List all modified files before proceeding

2. Plan batches

•Each commit = small/medium feature, stage, or cluster of related changes
•Code and docs for same feature go together
•Codebase should be working after each commit
•Don't mix unrelated changes
•If in a conversation: Only commit changes relevant to this conversation
•Prefer older files first (less likely another agent is working on them)

3. Commit each batch atomically

•ALWAYS chain reset/add/commit to avoid interference:

bash

git reset HEAD unwanted-file && git add "wanted-file" && git commit -m "type: subject"

•ALWAYS quote paths (especially SvelteKit routes with brackets)

4. Format commit message

code

<type>: <subject> (50 chars max)

<body> (optional, wrap at 72 chars)
- Planning doc: yyMMddx_feature_name.md (if applicable)
- Bullet points for multiple changes

Types: feat, fix, docs, style, refactor, test, chore

[IMPORTANT]

•Never do anything destructive without explicit user instruction
•Quote file paths: git add "path/with/[brackets]/file.ts"
•Chain operations: reset && add && commit (atomic)
•Stop immediately on merge conflicts or unexpected issues
•Check .gitignore: If you notice uncommittable files (node_modules, secrets), ask user
•Parallel agents: Provide context to help write good commit messages

[FALLBACK]

If codebase is in partial/broken state, prioritize commits that leave it working.

When in doubt, ask user before proceeding.