Automate Git Commits and Pushes

This skill stages only the intended changes, creates a conventional commit, and pushes to the remote branch through a helper script (smart_commit.sh). It activates when a user explicitly asks to push changes, mentions saving work to remote, completes a feature and wants to share it, or says something like "let's push this up." Before staging, it inspects git status --short --branch, confirms the intended files, and fetches the upstream branch when a concurrent push is plausible - it does not absorb unrelated dirty files. The helper requires an empty live index and a conventional commit message before staging anything: it locks the live index, builds and validates the commit in an isolated temporary index, rejects a bare -- with no paths, and atomically updates the branch only if its parent is unchanged. It resolves the push destination by honoring branch.<name>.pushRemote, remote.pushDefault, and the branch's configured upstream, in that order; for a new branch without those settings it requires origin and establishes origin/<branch>, and it rejects a detached HEAD or invalid remote configuration before staging.

bash "<skill-directory>/scripts/smart_commit.sh"

Use it for ordinary, non-release pushes: staging and pushing a completed change to a topic or feature branch. It reads repository policy before choosing a destination branch - if main/master is protected, or the repo defines a maintainer command such as merge:batch, it creates or uses a topic branch and finishes through the required pull-request checks instead. A user request to "push to main" describes the desired final state, not authorization to bypass protection, and the skill never retries a direct push after a protected-branch rejection. It explicitly does not apply to a maintainer merge batch, canonical synchronization, a versioned repository release, tag publication, or any repository with an explicit merge:batch, release:prepare, or release:publish workflow - those go through that repository's maintainer/release flow instead, which owns pull-request evidence, protected-branch checks, generated files, tags, and publication verification.

Input is an optional conventional commit message and an optional list of specific paths to stage. With no arguments, the helper stages all current changes, so that form is only appropriate when every dirty file belongs to the requested commit:

bash "<skill-directory>/scripts/smart_commit.sh" "feat: add feature"
bash "<skill-directory>/scripts/smart_commit.sh" "fix: scope change" -- path/to/file

Output is a pushed commit on the resolved remote/branch, or a rejection with a specific reason (protected branch, detached HEAD, invalid remote, non-empty live index, or a reftable repository, which the helper currently rejects before committing because reftable refs cannot use the filesystem lock protocol). The helper does not replace validation, release tooling, or a rebase required by an advanced upstream branch.

Developers who want a safe, scoped git push for a completed change - one that won't absorb unrelated dirty files, silently bypass branch protection, or interfere with a repository's separate maintainer/release process.