commit

Prepare a git commit for the current task. User context: $ARGUMENTS

Default scope: this session only

Unless the user says otherwise, commit ONLY the changes made in the current session. Do not include pre-existing modifications, untracked files from earlier work, or edits the user made manually outside this session — even if they are staged or in the working tree.

Override signals (commit broader scope only when user explicitly says): "commit everything", "commit all", "include the other changes", "stage X too", or names specific files outside the session set.

Workflow

1. Inspect repository state.

• Run git status --short.
• Run git diff --name-only and git diff --cached --name-only.
• Cross-reference against this session's tool-call history (Edit/Write/MultiEdit targets) to identify which files this session actually touched.

2. Build a candidate set from this session's work only.

• Include only files and hunks this session created or edited.
• Exclude pre-existing, unrelated, or user-authored edits that were not part of this session — even if they appear in git status.
• If confidence is not high for any file or hunk (e.g. session edited part of a file, but other hunks predate session), mark it as uncertain.

3. Resolve uncertainty before staging.

• If any file or hunk is uncertain, stop and ask the user exactly what to include.
• Ask with explicit paths/hunks so the user can approve or exclude each uncertain change.
• Do not commit until all uncertain items are resolved.

4. Stage explicit paths/hunks only.

• Use git add <file1> <file2> ....
• Use git add -p <file> when only part of a file belongs in this commit.
• Do not use git add . or git add -A unless the user explicitly asks to commit everything.

5. Validate staged content.

• Run git diff --cached.
• Confirm staged hunks are only this session's edits and do not include accidental or unrelated changes.

6. Write a Conventional Commit message.

• Use one type: feat, fix, chore, refactor, docs, test.
• Optional scope format: type(scope): summary.
• Keep the subject concise and imperative.

7. Commit non-interactively.

• Run git commit -m "<message>".
• Do not use interactive commit flows.
• Do not amend existing commits unless the user explicitly asks.

8. Report completion.

• Provide commit hash, commit subject, and file list.
• Also report remaining modified or untracked files.

Safety rules

• Never revert user changes unless explicitly instructed.
• Never run destructive commands (git reset --hard, force checkout) unless explicitly instructed.
• Never include a change with unclear ownership; ask the user first.
• Prefer one focused commit per user request unless asked to split into multiple commits.