git-pushing

Git Push Workflow Stage only intended changes, create a conventional commit, and push to the remote branch. When to Use Automatically activate when the user: Explicitly asks to push changes ("push this", "commit and push") Mentions saving work to remote ("save to github", "push to remote") Completes a feature and wants to share it Says phrases like "let's push this up" or "commit these changes" Safety Gates Before staging, inspect git status --short --branch , confirm the intended files, and fetch the upstream branch when a concurrent push is plausible. Do not absorb unrelated dirty files. Read repository policy before choosing the destination branch. If main or master is protected, or the repository defines a maintainer command such as merge:batch , create or use a topic branch and finish through the required pull-request checks. A user request to “push to main” describes the desired final state; it does not authorize bypassing server-side protection. Never keep retrying a direct push after a protected-branch rejection. The helper requires an empty live index and a conventional commit message before it stages anything. It 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. Show more Installs 943 Repository sickn33/agentic…e-skills GitHub Stars 45.1K First Seen Jan 19, 2026 Security Audits Gen Agent Trust Hub Pass Socket Pass Snyk Pass