Webdevcody Go Mailing List Commit And Push

User-question protocol: Whenever this skill needs the user to pick between options, confirm an action, or answer a multiple-choice prompt, you MUST call the AskUserQuestion tool to render a proper interactive picker. Do NOT print numbered options as plain text and wait for the user to type a number — that produces a degraded UX. Free-form questions (open-ended typing) may be asked in prose, but any time you would write "1) … 2) … 3) …", use AskUserQuestion instead.

commit-and-push

Two steps, in order: (1) delegate commit work to the commit skill, (2) push the current branch.

Step 1 — Commit

Invoke the commit skill. Do NOT re-implement its grouping logic here — it owns commit composition, ordering, and message style.

Exit conditions from Step 1:

• Commits were created → proceed to Step 2.
• Working tree was already clean (nothing to commit) → no-op the whole skill. Do not push. Tell the user "nothing to commit; not pushing" and stop.
• commit skill aborted or errored → stop. Do not push a partial state.

Step 2 — Push

Before pushing, confirm: the branch you're about to push is the one the user expects. HEAD may have moved during Step 1 if the commit skill checked out anything; always re-derive the branch from git rev-parse --abbrev-ref HEAD rather than caching it from before Step 1.

Run exactly:

git rev-parse --abbrev-ref HEAD                    # capture <branch>
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null

• If the second command succeeds → upstream exists → git push.
• If it fails (no upstream) → git push -u origin <branch>.

If origin does not exist (push errors with "'origin' does not appear to be a git repository"), run git remote -v, show the user the available remotes, and stop. Do not guess a remote name.

Report the pushed branch and remote in one line when done.

NEVER

• NEVER pass --force, --force-with-lease, +<refspec>, or any force variant Instead: If the push is rejected as non-fast-forward, stop, surface the rejection verbatim, and suggest the user run git pull --rebase then re-invoke this skill. Do not auto-pull, do not auto-rebase, do not force. Why: Force-push silently rewrites remote history; on shared branches it destroys other people's commits. Auto-pull/rebase hides the conflict from the user and can merge unrelated upstream work into commits they just made. The user explicitly forbade force for this skill.

• NEVER push without first attempting Step 1 Instead: Always run the commit skill first, even if you suspect the tree is clean. Let commit decide. Why: The whole point of this skill is "commit + push as one action." Skipping Step 1 turns it into git push and bypasses the grouping discipline.

• NEVER push when Step 1 produced zero commits Instead: No-op and tell the user. If they wanted to push pre-existing local commits, they'll re-run with plain git push. Why: The user specified no-op semantics when there's nothing to commit. A push in that case would publish unrelated stale local work the user didn't ask about.

• NEVER skip the upstream check and assume git push will work Instead: Run the @{u} rev-parse first; branch on its exit code. Why: A first-push on a new branch fails without -u origin <branch>. Checking up front avoids a cryptic error and a second round-trip.

• NEVER push to a branch other than the current HEAD Instead: Always derive the branch from git rev-parse --abbrev-ref HEAD. Never hardcode main or pass an explicit refspec. Why: Hardcoded targets push the wrong branch when the user has checked out a feature branch.

Source: webdevcody/go-mailing-list — distributed by TomeVault.