Agentsystemlabs Core 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 (which runs its own pre-flight quality gate), (2) push the current branch.

Modes

Accepts mode=fast|balanced|production. Default — when no mode= is specified — is production. The default is strict on purpose: pushing publishes to others; once it's on the remote, it's out there.

The mode is forwarded to the commit skill, which runs its Step 0 pre-flight at the chosen depth (see commit/SKILL.md Modes table). On production, commit invokes the full check-pr-readiness gauntlet before composing commits — by the time Step 2 runs here, the diff is already verified.

For explicit mode=fast or mode=balanced, this skill runs a mandatory check-pr-readiness pass between Step 1 and Step 2, regardless. Pushing weak code to a shared remote is not a downgrade you can buy with a flag.

Override: explicit mode=… in the user's prompt always wins.

Step 1 — Commit

Invoke the commit skill, passing the active mode=. Do NOT re-implement its grouping logic here — it owns commit composition, ordering, message style, and the pre-flight quality gate.

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.

Pre-push quality gate (mandatory for mode=fast and mode=balanced):

If the active mode is fast or balanced, invoke agentsystem-core:check-pr-readiness against the branch vs. its base now. If any gate fails, stop the push. Ask via AskUserQuestion:

• Fix and retry → exit; user fixes and re-runs.
• Push anyway → require an explicit acknowledgement string; record the bypass in the push report.

Skip this step when mode is production — commit's Step 0 already ran the full gauntlet.

Pre-push risk briefing (all modes):

Invoke agentsystem-core:check-release-risk unless the branch has zero diff vs. base, or the diff is doc/comment-only. This is a content-risk briefing, not a blocking gate; surface its findings before running git push so the user can confirm.

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: AgentSystemLabs/core — distributed by TomeVault.