Push

Planner Entry

Push the verified commit directly in the primary conversation. With --fixup, continue with /pr-fixup in that same conversation; do not delegate polling or delivery.

Available skills

• /commit — Creates the artifact after task-defined checks pass.
• /pr-fixup — Wait for CI checks and CodeRabbit, Greptile, Claude, OpenCode, and cubic review feedback, fix any failures or valid comments, and push again.

Options

• --fixup — after pushing, begin /pr-fixup in the same conversation.

Note: This skill normally uses git push. It uses gh pr view before a no-upstream fallback so a checked-out fork PR is not accidentally pushed to its base repository.

Your task

Push the already committed branch to its remote.

Steps

Create a todo/task for each step below and mark them as completed as you go.

1. Uncommitted changes: If there are dirty or staged changes, stop: a new commit and the affected task checks are required first.

2. Task-check evidence: Require the task-defined unit, integration, and E2E checks affected by this commit to pass. If the checkout or commit changed afterward, rerun only the affected task checks.

3. Safety check: Verify the current branch is NOT main or master. If it is, stop and ask the user — direct pushes to the default branch should go through a PR.

4. Push the current branch:

   git push
   

   If the branch has no upstream, first look up the current branch's PR. Treat an unavailable or ambiguous lookup as a stop condition; only a confirmed absence of a PR permits the ordinary origin fallback. For a confirmed PR, require its headRefName to match the checked-out local branch, then inspect its delivery target:

   gh pr view --json isCrossRepository,headRepositoryOwner,headRepository,headRefName,headRefOid,maintainerCanModify
   

   For a cross-repository PR, the PR head owner can push its own fork directly. When acting as a base-repository maintainer on somebody else's fork, maintainerCanModify must be true; do not treat that field as a universal fork-owner gate. Push the exact current commit to the reported head owner, repository, and ref. Before using the HTTPS URL, configure Git to use the authenticated gh credential helper:

   gh auth setup-git
   git push "https://github.com/<head-owner>/<head-repository>.git" "HEAD:refs/heads/<head-ref>"
   

   If that push fails with git repository does not match any credential lease scope, do not put a token in command arguments or logs. Retry after gh auth setup-git; if HTTPS still rejects the contributor-fork push, use the SSH fallback below or report the authentication/scope blocker. Never embed the token in a remote URL, command argument, log, or persisted credential. Re-fetch the PR and require its headRefOid to equal local HEAD afterward. If HTTPS still rejects a contributor-fork push and SSH authentication is available, verify the exact target with git ls-remote git@github.com:<head-owner>/<head-repository>.git, then retry the same exact ref over SSH (using the exact remote-OID lease if history was rewritten). Re-fetch and verify the PR head OID again. Do not substitute a local fork remote or an inferred repository. Do not use a conveniently named local fork/contributor remote: linked worktrees share remote configuration, so it can refer to another task. Re-fetch the PR and require headRefOid to equal local HEAD.

   Only for a non-PR or same-repository PR, use git push -u origin HEAD rather than transcribing the branch name. Then verify git rev-parse HEAD equals git rev-parse '@{upstream}', and report the branch from git branch --show-current. If the branch was rebased or history was rewritten, first confirm the current branch is not main or master, then use the exact remote-OID lease git push --force-with-lease=refs/heads/<branch>:<captured-remote-sha>. Use generic --force-with-lease only when no remote OID was captured; never use an unconditional force push. If the branch modifies .github/workflows/* and GitHub rejects the push with a message like refusing to allow an OAuth App to create or update workflow ... without workflow scope, treat it as push authentication/scope, not a code or branch-protection failure. Retry with an SSH remote when available, for example git push git@github.com:<owner>/<repo>.git <branch>, or tell the user the token needs workflow scope.

   If both HTTPS and SSH pushes time out and an authorized GitHub connector exposes Git database writes, preserve the tested tree by creating blobs for the exact file contents, a tree from the known parent tree, and a commit with the same parent and message, then fast-forward the existing branch ref. Fetch that ref, verify its content and commit, and reset the local worktree only to the fetched SHA. This can produce a different commit SHA, so all subsequent checks and final evidence must use the fetched head.

5. Report the pushed commit hash and branch.

6. If --fixup: Continue with /pr-fixup in this conversation.