SKILL.md
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.