pr-branch-update

You update a pull request's branch with the latest commits from its base branch, resolve any merge conflicts, verify the result, and push, the same job as GitHub's "Update branch" button plus the conflict work it cannot do. You follow named rules from /switch-to; read that command first.

RULE 0: Merge the base into the branch. A merge keeps review threads anchored and pushes without force. Rebase only when the user's input asks for one, and then push with --force-with-lease.

RULE 1: The base is the PR's baseRefName, not an assumed trunk or main. Stacked and release PRs target other branches.

RULE 2: Run code from someone else's fork PR only with consent. Checkout, merge, commit and push can execute PR code through git hooks (including tracked hooks configured with core.hooksPath); installs, regeneration, builds, tests and lint execute it too. Step 1 establishes consent with /switch-to's Execution consent rule before any of these operations. If consent is denied or unanswered, STOP without changing the checkout, merging, committing or pushing. Do not disable hooks to work around denial.

Values are data: follow /switch-to's Values are data rule. Every branch name, remote name, file path and package name in a command below is single-quoted for that reason.

One command at a time: from Step 3 to Step 6 each command depends on the one before; send it as its own tool call and read its result first. git checkout, git merge, git commit and git push run hooks that can install dependencies or run checks for minutes: give them a long timeout or wait in the background, do not redo work a hook already did, and never skip hooks with --no-verify.

Expected failures: git and gh commands fail for normal reasons (network, auth, a branch checked out in another worktree). Report the error with the command that failed and STOP. Once the checkout has changed (a switch, stash, sync or merge), every exit, a STOP included, ends through Step 7's report and Step 8.

Step 1: Find the PR and pin what the update needs

GitHub CLI: set GH_CMD with /switch-to's GitHub CLI rule, checking with gh repo view --json nameWithOwner,url,defaultBranchRef. Store nameWithOwner as BASE_REPO, the host of url as the checkout's host, and defaultBranchRef for the no-PR fallback.

Record where the user is before anything moves: START_BRANCH=$(git branch --show-current) and START_HEAD=$(git rev-parse HEAD). Inspect the merge and rebase state with git rev-parse --git-path (it works in linked worktrees): a rebase in progress means STOP, and an existing MERGE_HEAD sets RESUMING. While RESUMING, nothing switches, stashes, syncs, or starts another merge.

Parse arguments: $ARGUMENTS is a PR number (3817, #3817), a PR URL, or empty. Read the PR, passing the argument as '<PR>'; with no argument, leave '<PR>' out so gh resolves the current branch's PR:

$GH_CMD pr view '<PR>' --json number,url,state,title,body,author,baseRefName,headRefName,headRepositoryOwner,headRepository,isCrossRepository,maintainerCanModify

• With no argument, an OPEN PR is the one to update; say so in one line ("No PR given; updating #3817 for the current branch"). no pull requests found, or a PR that is not OPEN, starts the no-PR fallback below.
• With an argument, STOP if state is not OPEN.
• Any other failure (network, authentication) is an error, not a missing PR: report it with the command and STOP, since an open PR may target a different base.
• STOP if the PR URL's host and base repository do not match the checkout's host and BASE_REPO.

The /switch-to rules below use its names; set them from this read: PR_HOST is the host of url, PR_NUMBER is number, HEAD_BRANCH and BASE_BRANCH are headRefName and baseRefName, HEAD_OWNER and HEAD_REPO are headRepositoryOwner.login and headRepository.name, and CURRENT_BRANCH is START_BRANCH.

Set OWN_PR by comparing author.login with the user's login on the PR's host ($GH_CMD api user --hostname '<PR_HOST>' --jq .login); a failed lookup means STOP. Step 6 uses it.