Automate Git Commits and Pushes

Git Push Workflow stages only the intended changes, creates a conventional commit, and pushes to the remote branch through a smart_commit.sh helper. The helper enforces safety at every step: it requires an empty live index and a conventional commit message before staging anything, locks the live index, builds and validates the commit in an isolated temporary index, rejects -- without paths, and atomically updates the branch only if its parent is unchanged. It resolves the push destination via 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 detached HEAD or invalid remote configuration before staging. A representative invocation with a custom commit message:

bash "<skill-directory>/scripts/smart_commit.sh" "feat: add feature"

Use this skill when the 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 will not absorb unrelated dirty files. It reads repository policy before choosing a destination branch: if main or master is protected, or the repo defines a maintainer command like merge:batch, it uses a topic branch and goes through the required pull-request checks instead - a user asking to "push to main" describes the desired final state, not authorization to bypass server-side protection, and it never keeps retrying a direct push after a protected-branch rejection. It is explicitly not for a maintainer merge batch, canonical synchronization, versioned release, tag publication, or any repository with an explicit merge:batch, release:prepare, or release:publish workflow - those own their own pull-request evidence, protected-branch checks, generated files, tags, and publication verification, and should use their own maintainer or release flow instead. It also requires Git's files ref backend and rejects reftable repositories, since their refs can't use the filesystem lock protocol.

Input is the working directory's current changes and an optional commit message or file paths passed after -- to scope staging to named files; with no paths, the helper stages all current changes, so that form should only be used when every dirty file belongs to the requested commit. Output is a conventional commit created in an isolated temporary index and pushed to the resolved remote/branch, without replacing validation, release tooling, or a rebase that an advanced upstream branch might require.

Developers who want a safe, guarded git push - one that won't absorb unrelated changes, bypass branch protection, or push a malformed commit message - rather than running git add/commit/push by hand or trusting a maintainer-release flow to catch mistakes it isn't scoped to catch.