quick-push

name

quick-push

description

Fast-path push — stage everything in the working tree, create ONE auto-generated commit (bypassing the multi-commit grouping of the `commit` skill), then push the current branch's commits to remote `main` after explicit user confirmation. Trigger phrases — "/quick-push", "quick push", "push it now", "yolo", "/yolo", "yolo to main", "yolo commit", "speed commit", "one big commit and push to main", "just push it to main". Skip for — workflows that need grouped commits (use `commit` or `commit-and-push`), pushes to a branch other than `main`, force-push requests, amend/fixup, or when the user wants to review the diff before committing. For end-to-end engineering pipelines (plan → implement → test → review), use the orchestrator `/ship` instead.

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.

quick-push

One commit. Push to origin main. Confirm before the push.

This skill deliberately bypasses the commit skill's grouping logic — the user asked for the speed path, not the clean-history path.

---

Step 1 — Stage and commit everything

git status --short
git diff --stat HEAD

If the working tree is clean AND there are no untracked files → check if local has unpushed commits ahead of origin/main. If yes, skip to Step 2. If no, no-op: tell the user "nothing to ship" and stop.

Otherwise, generate a one-line commit message from the diff. Before writing it, ask: what is the dominant change a future bisecter would search for? That phrase belongs in the message. Imperative mood, ≤72 chars, name the dominant change — not "various updates". Then:

git add -A
git commit -m "<message>"

Use the project's standard Co-Authored-By trailer if other commits in git log have one; otherwise no trailer.

---

Step 2 — Confirm, then push to main

Probe the remote first:

git remote get-url origin

If this fails, run git remote -v, show the user the available remotes, and stop — do not guess a remote name.

Then probe whether origin/main already exists:

git fetch origin main
git rev-parse --verify origin/main

• If rev-parse succeeds → compute ahead-count with git rev-list --count origin/main..HEAD.
• If rev-parse fails (remote main doesn't exist yet — first push to a new repo) → skip the ahead-count and tell the user the push will create origin/main.
• If git fetch fails (offline, auth) → stop and surface the error; do NOT proceed with a stale count.

Show the user:

• Branch name (git rev-parse --abbrev-ref HEAD)
• The commit just made (git log -1 --oneline)
• Either the ahead-count or "this push will create origin/main"
• The exact command about to run

Ask: "Push these N commit(s) to origin/main? (y/n)" Wait for the user. Anything other than an affirmative reply → stop.

On approval, push the current branch's commits to remote main:

git push origin HEAD:main

This pushes whatever is at HEAD to the remote main ref regardless of the local branch name (per user spec: option c). Report the result in one line.

If the push is rejected as non-fast-forward → stop, surface the rejection verbatim, suggest git fetch origin main && git rebase origin/main. Do not auto-rebase, do not force.

---

NEVER

• NEVER pass --force, --force-with-lease, or +<refspec> Instead: On non-fast-forward rejection, stop and surface the error. Let the user choose how to reconcile. Why: This skill targets main directly — a force-push here rewrites the trunk for everyone.

• NEVER push without the explicit y/n confirmation in Step 2 Instead: Always show the branch, commit, and command, then wait for an affirmative reply. Why: The user specified confirmation before pushing. Pushing to main without it publishes unreviewed work to the trunk.

• NEVER delegate to the commit skill Instead: Stage with git add -A and create one commit inline. Why: The whole point of this skill is to bypass commit's grouping. Delegating defeats the purpose.

• NEVER use a placeholder commit message like "wip", "update", or "changes" Instead: Read git diff --stat and git diff (sampled) and write an imperative one-liner naming the dominant change. Why: This commit lands on main permanently. A useless message poisons the log and git blame.

• NEVER stage files matching .env*, *.pem, *credentials*, *.key, or anything in .gitignore that slipped through Instead: Run git status --short first; if any suspicious paths appear, stop and ask the user before git add -A. Why: git add -A is indiscriminate — secrets shipped to main are effectively public the moment they're pushed.

• NEVER push to a remote other than origin or a branch other than main under this skill Instead: If the user wants a different target, redirect them to commit-and-push (current branch → its upstream). Why: This skill's contract is origin main. Silently retargeting violates user expectation.