Turn the requested work into coherent commits, accounting for everything in scope and verifying what Git actually recorded.
Establish the batch from current work
An unrestricted commit request covers all staged, unstaged, and non-ignored untracked changes in the selected repository and worktree, including other tasks. Do not ask again merely because a change came from another session. Honor explicit file, task, or staged-only restrictions. For message-only requests, leave Git unchanged; for stage-only requests, prepare and verify the index without committing.
On every invocation or resume, inspect the repository, branch, HEAD when present, status, staged and unstaged diffs, and untracked contents. Read enough surrounding code and history to understand each change; memory and old reports cannot replace current evidence. Follow repository instructions and exclusions. Never commit secrets; identify withheld paths and reasons without exposing sensitive values. Resolve factual uncertainties directly; ask only for a necessary unresolved choice.
Group changes by purpose and dependency. Keep the code, tests, configuration, and documentation needed for one change together; separate independent work. One coherent change needs only one commit. Account for every in-scope change, including deletions; do not split by file type or create a group that depends on a later commit.
Record and verify each group
Prepare exactly the group's content in the index. Inspect existing staging before altering it; preserve excluded content and staged selections. Select hunks when a file mixes groups or scopes, without pulling other hunks into the commit. Read the entire resulting staged diff, not merely the paths just added. Re-read and regroup affected work if content changes during the operation.
Run git diff --cached --check and required repository checks; allow hooks to run
without bypassing them. Associate check results with the content they actually
covered; a passing working-tree check may include changes absent from this group.
Commit verification does not replace implementation review.
Use repository message conventions; otherwise use English Conventional Commits with
a subject of at most 72 characters. Describe the actual change and its reason when
useful; do not invent validation or add Co-Authored-By or AI attribution. Use direct
Git commands to create the commit, with safely quoted literal messages or a message
file; avoid shell wrappers and command substitution.
Compare the created commit's diff and message with the intended group, then inspect the remaining index and working changes. Never discard or edit working content or rewrite existing commits to force success. After a failure, interruption, or hook edit, inspect HEAD, index, and working content before retrying. Preserve successful commits and resume from the actual remainder.
Finish the requested action
Reconcile the resulting commits and remaining changes with the intended batch. Report anything excluded or blocked and why; do not call partial work complete. If nothing needs recording, create no empty commit; still handle an authorized push.
Push only when requested, after completing the intended commit batch. Verify the
remote, destination branch, and outgoing history before a normal non-force push;
do not assume origin or an upstream. Resolve a material destination ambiguity,
and do not silently publish a partial batch or rewrite history after rejection.
Verify the remote received the intended commits; distinguish local commit success
from a failed or unverified push.
Return commit hashes and subjects, checks and material limits, and any leftovers with reasons. For message-only or stage-only work, return that result instead. State the verified local or pushed status and stop at the authorized action.