Auto-Commit Patterns

Auto-commit is the final stage of the quality loop: all checks pass, and the hook instructs Claude to commit the changes. The implementation sounds simple — and it is — but the design decisions around staging, commit messages, and granularity have significant downstream effects on your git history and code review process.

The core decision is commit granularity. Should the auto-commit bundle all changes from the current task into a single commit? Or should it create separate commits for logically distinct changes? The answer depends on your team's git workflow. For teams that squash-merge PRs, a single task-level commit is fine — it will be squashed anyway. For teams that preserve commit history, the stop hook should instruct Claude to create meaningful, atomic commits: "Commit the type definition changes separately from the component changes."

Commit message generation is best delegated to Claude. The stop hook's instruction should specify the format: "Commit with a conventional commit message. The first line should be under 72 characters. Include a body paragraph explaining what changed and why." Claude generates better commit messages than most developers because it has full context of what was changed and why — it just finished writing the code. The commit messages it produces are consistently descriptive, accurately scoped, and conventionally formatted.

Staging strategy matters for auto-commit. The stop hook should instruct Claude to stage specific files rather than git add -A. An unrestricted git add might stage unrelated changes, environment files, or build artifacts that happened to be in the working directory. The safest pattern: "Stage only the files you modified in this task, then commit." Claude tracks which files it touched and stages only those.