YourAI.tools
Roo Code logo

Skill

push

push local commits to remote repositories

Published by Roo Code Updated Jul 16
Covers GitHub Git

Description

Push local commits or existing unpushed commits to the remote without opening pull requests. Stage and commit any uncommitted changes first, keep existing unpushed history when present, and report the follow-up pull request command.

SKILL.md

You are executing a command to push work to remote branches without creating a pull request. Stage and commit any unstaged changes first when needed, keep existing unpushed commits when present, then push the result.

<shared_core_loading> If the implement-changes skill is not currently loaded into your context, load that skill before deeper execution.When loading implement-changes from this child skill, inherit only the core-contract section and the matching parent child-path contract for this workflow.Do not execute implement-changes's default workflow from this child skill unless the caller explicitly instructed the parent default path to run first.This child skill remains the canonical owner of its delivery mechanics even when the parent skill is loaded for shared context. </shared_core_loading>

Push the current changes or existing unpushed commits to remote branches without opening pull requests, handling both single-repository and multi-repository workspaces. The current directory contains a `.git` directory. The current directory contains child repositories rather than being the active repository itself. No repository has uncommitted changes or unpushed commits after detection. Find every repository that requires a pushed branch and determine the names and commit metadata that should be used.
Detect the workspace layout and changed repositories Establish whether the workflow should operate on one repository or many, then collect all repositories that need a branch push. Run `echo "=== Workspace Detection ===" && pwd && echo "" && if [ -d ".git" ]; then echo "WORKSPACE_TYPE: SINGLE_REPO"; echo "REPO_DIR: $(pwd)"; echo "REPO_NAME: $(git remote get-url origin 2>/dev/null | sed -E 's|.*[:/]([^/]+/[^/]+)$|\1|' | sed 's/\.git$//' || basename $(pwd))"; else echo "WORKSPACE_TYPE: MULTI_REPO"; echo "=== Repos with Changes ==="; workspace_root=$(pwd); shopt -s nullglob; for repo_dir in */; do if [ -d "$workspace_root/${repo_dir}.git" ]; then cd "$workspace_root/$repo_dir"; has_changes=false; if [ -n "$(git status --porcelain 2>/dev/null)" ]; then has_changes=true; fi; if git rev-parse --abbrev-ref --symbolic-full-name @{u} >/dev/null 2>&1; then if [ -n "$(git log @{u}..HEAD --oneline 2>/dev/null)" ]; then has_changes=true; fi; elif [ -n "$(git log HEAD --not --remotes=origin --oneline 2>/dev/null)" ]; then has_changes=true; fi; if [ "$has_changes" = "true" ]; then repo_name=$(git remote get-url origin 2>/dev/null | sed -E 's|.*[:/]([^/]+/[^/]+)$|\1|' | sed 's/\.git$//' || basename $(pwd)); echo "CHANGED_REPO: ${repo_dir%/} -> $repo_name"; fi; fi; done; cd "$workspace_root"; for owner_dir in */; do if [ ! -d "$workspace_root/${owner_dir}.git" ]; then cd "$workspace_root"; for repo_dir in "$owner_dir"*/; do if [ -d "$workspace_root/${repo_dir}.git" ]; then cd "$workspace_root/$repo_dir"; has_changes=false; if [ -n "$(git status --porcelain 2>/dev/null)" ]; then has_changes=true; fi; if git rev-parse --abbrev-ref --symbolic-full-name @{u} >/dev/null 2>&1; then if [ -n "$(git log @{u}..HEAD --oneline 2>/dev/null)" ]; then has_changes=true; fi; elif [ -n "$(git log HEAD --not --remotes=origin --oneline 2>/dev/null)" ]; then has_changes=true; fi; if [ "$has_changes" = "true" ]; then repo_name=$(git remote get-url origin 2>/dev/null | sed -E 's|.*[:/]([^/]+/[^/]+)$|\1|' | sed 's/\.git$//' || basename $(pwd)); echo "CHANGED_REPO: ${repo_dir%/} -> $repo_name"; fi; fi; done; cd "$workspace_root"; fi; done; shopt -u nullglob; cd "$workspace_root"; fi`. Stop and report that there is nothing to push if the detection phase finds no changed repositories. The target repository list is explicit and complete before any commits or pushes occur. Determine the branch name and commit message for each repository Inspect the outstanding work so the pushed branch and any required commit reflect the actual intent of the change. For each repository, run `cd && echo "=== Analyzing $(basename $(pwd)) ===" && git remote get-url origin && git status && (git diff --stat HEAD 2>/dev/null || git diff --stat) && (if git rev-parse --abbrev-ref --symbolic-full-name @{u} >/dev/null 2>&1; then git log @{u}..HEAD --oneline; else git log HEAD --not --remotes=origin --oneline; fi || echo "No commits yet")`. Choose a branch name using `feature/-` or `fix/-`. Choose a conventional commit message for repositories that still need a local commit. Each repository has a branch name, repository identifier, and commit message when a commit is required.
Create or reuse the delivery head branch, commit pending work when necessary, and push the resulting branch to the remote.
Create the branch and commit pending work Ensure the repository is on a delivery branch created from the provided base/default branch and convert working tree changes into a commit when needed. For each repository, determine the current branch and the provided base/default branch for this run. If no branch is provided for the run, use the repository default branch. Fetch the provided base branch with `cd && git fetch origin `. If a new delivery branch is needed, run `cd && git checkout -b origin/` before staging or committing pending work. If already on an explicit existing delivery branch for this task, keep it. For each repository with working tree changes, run `cd && git add -A && git diff --cached --name-status`. After `git add -A`, explicitly compare `git diff --cached --name-status` against the intended deliverables for this task. If any staged path is unexpected, unstage it with `git restore --staged ` before committing. Treat generated or untracked files as excluded by default unless they are clearly part of the requested delivery. After the staged-path review is complete, for each repository with working tree changes run `cd && git commit -m ''`. If the repository already has unpushed commits and no working tree changes, skip only the commit while still ensuring the branch is correct. If hooks fail, fix the validation issue rather than bypassing `--no-verify` unless no safer option remains. Each repository is on a delivery branch created from the provided base/default branch, or is explicitly identified as already on an existing delivery branch for this task. Push the branch for each repository Publish the resulting branch to the remote so the work is available for later pull request creation. For each repository, run `cd && if git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null; then git push; else git push -u origin HEAD; fi`. Record the pushed repository and branch for final reporting. Every targeted repository has a confirmed pushed branch or a clearly reported blocker.
Summarize the pushed branches clearly so the user can move directly into pull request creation if desired.
Report the pushed branches and next step Provide the repository, branch, and follow-up pull-request path for each pushed target. Report each repository and pushed branch in a concise structured summary. Offer pull request creation as the follow-up step for each pushed branch: a `create-pr` run delivers it through the provider-neutral `mcp__roomote__manage_source_control` tool, so do not suggest provider-specific CLI commands such as `gh pr create`. Mention the org-configured conflict resolver label supplied in the task context so a follow-up pull request run can apply it. The final report includes every pushed branch and gives the user an immediate next step for opening a pull request.

<completion_criteria> Every repository with changes or unpushed commits has been processed exactly once.Each targeted repository has a pushed branch or a clearly surfaced blocker.The final summary tells the user how to open a pull request for each pushed branch. </completion_criteria>

<best_practices> Push one branch per changed repository rather than mixing repository state in the final report.Repository-specific reporting makes later pull request creation predictable and auditable.None.Use conventional commit messages and branch names that encode the intent of the change.Pushed work should remain understandable when reviewed later outside the current task context.Use repository-specific conventions if they are stricter than the default pattern.Respect validation hooks and fix their failures instead of bypassing them casually.These flows are meant to keep repository state clean, not just to move bytes to a remote.Only bypass as a last resort after the root cause has been investigated and documented. </best_practices>

Detect whether work must happen in one repository or many before issuing git commands. Use for any branch-push workflow. Detect repositories, gather changed targets, and short-circuit if there is nothing to push. Push work remotely without immediately opening a pull request. Use when the user wants backup, collaboration, or later review rather than immediate PR creation. Choose branch and commit metadata, create or reuse the branch, push it, then report the follow-up PR command.

<decision_guidance> Prefer pushing work remotely over leaving it stranded in ephemeral local state.Do not create a pull request when the user explicitly asked only for a branch push.Stop and report blockers rather than pretending the branch was pushed when it was not.Use only non-interactive git commands, keep hook-based checks, and avoid destructive history rewriting unless the user explicitly asked for it.This workflow handles branch creation, optional commits, remote push, and push reporting.This workflow does not open pull requests automatically.When authentication, branch protection, or remote policy blocks the push, surface the blocker and stop. </decision_guidance>

The workspace contains two repositories with pending work that should be pushed remotely but not yet packaged into pull requests. Push these changes to branches but do not create PRs. Identify both repositories that have work to push. Run the workspace detection command and record the changed repositories. Both repositories are queued for branch creation and push. Create the branch and commit state for each repository. Choose branch names and conventional commit messages based on the repository-specific diffs. Each repository is on a reviewable branch with the local work committed when needed. Push both branches and report the follow-up pull request commands. Run `git push` or `git push -u origin HEAD` per repository and summarize the next command for each one. The user can immediately create pull requests later without losing the work. The work is safely pushed to remote branches and the user receives exact next-step commands. Pushing a branch is a valid endpoint even when pull request creation is intentionally deferred.

<error_handling> There is nothing to commit or push.The workspace is already clean and synchronized with the remote.The requested work was already pushed earlier.Stop and tell the user that no push action is needed.The branch cannot be pushed.Repository hooks fail.Remote permissions, branch protection, or authentication prevent the push.Fix the validation issue when possible; otherwise surface the exact blocker and stop rather than claiming the push succeeded. </error_handling>

AboutPrivacy PolicyTerms and Conditions

© 2026 YourAI.tools. Every skill from an identity-verified publisher.

Independent catalog. Not affiliated with, endorsed by, or sponsored by Anthropic or any listed publisher. All trademarks belong to their respective owners.