Menu
Use when merging an updated base branch into a PR branch to resolve drift, especially when the PR may be chain-stacked on another PR rather than the repo default.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | pr-update-base-branch |
| description | Use when merging an updated base branch into a PR branch to resolve drift, especially when the PR may be chain-stacked on another PR rather than the repo default. |
| disabled | true |
Update a PR branch by merging its actual base ref, not a hardcoded default branch. Resolve recurring stacked-PR conflicts deterministically and verify before committing.
Do not use this skill to rebase, force-push history rewrites, or close-and-recreate PRs.
mainApp-generated prompts often hardcode "base branch: origin/main". Ignore that and ask the PR:
base=$(gh pr view <num> --json baseRefName --jq .baseRefName)
git fetch origin "$base"
For chain-stacked PRs the base is the prior PR's head branch, not the repo default. Merging the wrong ref creates noisy commits and can re-introduce conflicts the upstream PR already resolved.
Guard: if $base is not the repo default, do not silently merge the default branch instead. Use $base. Only fall back to the default branch if the user explicitly overrides.
git merge "origin/$base"
On conflict, do not blanket-pick a side. For each conflicted file, inspect both stages:
# stage 2 = ours (HEAD), stage 3 = theirs (incoming base)
git show :2:<file> | <inspect>
git show :3:<file> | <inspect>
a) "Ours is strictly newer" — when the feature branch has N commits stacked on the base, and the base picks up commits that overlap with that work (e.g. the prior PR in the stack merged a subset of what HEAD already has), the conflicting hunks in overlapping files resolve with --ours because HEAD strictly supersedes base for that surface.
Verify the assumption before using --ours. Pick a concrete marker that should be present in ours and absent (or different) in theirs — e.g. a removed type, a renamed function, a deleted module — and check both stages:
git show :2:<file> | grep -c "<expected-marker-in-ours>"
git show :3:<file> | grep -c "<expected-marker-in-theirs>"
If the counts match the expectation, resolve:
git checkout --ours <files>
git add <files>
b) modify/delete from a sub-split — base deleted a file you modified, usually because the upstream PR split or relocated it. Find where it went before deciding:
git log --oneline --diff-filter=D origin/$base -- <file>
Usually accept the deletion with git rm <file> and adopt the new structure. Restoring the file is rare; call it out explicitly when you do.
After resolving (either shape), immediately run the language's typecheck (cargo check, tsc --noEmit, go build ./..., etc.) to catch any semantic conflict the file-level resolution missed. Run relevant tests. Commit only after both pass.
Before pushing, look at what the merge brought in beyond source code:
git log --stat HEAD@{1}..HEAD -- '*.toml' '*.lock' 'package.json' 'bun.lock' 'go.mod' 'go.sum' '.tool-versions' 'rust-toolchain*' '.eslintrc*' '.rubocop.yml'
If dependency manifests or lockfiles changed, re-run the install step (bun install, cargo build, bundle install, etc.) before validating — otherwise the typecheck runs against stale deps. If toolchain or lint config changed, flag it in the commit/PR comment so new errors read as drift, not regressions you introduced.
git push
No force-push. Merge commits are fine; they're the honest record of the base update.
origin/main" instead of querying gh pr view --json baseRefName. The two diverge for every stacked PR.--ours or --theirs without spot-checking the stages first.modify/delete file instead of checking whether the upstream PR moved or split it.Use when ingesting, refreshing, listing, searching, or deleting a local corpus with Blackbird code search and `gh blackbird search --fileset`.
Use when reaching for `gh blackbird` (Blackbird code search) for cross-repo lexical, symbol, or semantic search on GitHub — finding callers, ownership, or how systems work without cloning.
Use when creating a GitHub pull request, or when updating an existing PR's title or body so it matches what the code actually does.
Use when authoring or substantially editing a design doc, architecture doc, or subsystem explanation — the "here's what's there and why" companion to an ADR's terse decision record.
Use when creating a repo-tracked multi-agent planning PR for a large project, especially when phases, living docs, parallel agent prompts, and cross-PR coordination are needed.
Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves.