resolve-pr-conflicts

어떤 스킬인가요?

Resolve a PR's merge conflicts against its current base branch and verify the combined changes. Use independently or during PR babysitting and merging.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

# Resolving conflicts

**Textual conflicts.** Read each hunk and combine intent: prose takes the
richer superset, code keeps both sides' additions (two PRs that each add a
function at the same anchor: keep both). For a generated or lock file
(`Cargo.lock`, `package-lock.json`, `poetry.lock`), take the base version and
regenerate from the resolved manifest, then confirm consistency (`npm ci` fails
if a lockfile and manifest disagree).

**Semantic conflicts** (invisible to Git), caught when updating this PR onto a
base branch that already contains other changes:

- **Shared version or sequence constants.** Two PRs must not both claim the
  same bump. If a landed PR took `3 -> 4`, this PR's bump becomes `4 -> 5`.
  Regenerate whatever the change feeds and re-run the affected tests.
- **Migration or numbered-file collisions.** The same numeric prefix on
  different filenames is a clash Git cannot see. Renumber so the prefix does
  not collide with what already landed.
- **Combined-tree build or test breaks.** Two PRs that touch the same module
  in different files can still fail together. The update onto default is where
  you catch that.
- **Mutually dependent PRs.** Merge the library bump first, then the
  call-site, after updating the second onto default. If neither PR is
  mergeable on its own, stop and ask.

---
name: resolve-pr-conflicts
description: Resolve a PR's merge conflicts against its current base branch and verify the combined changes. Use independently or during PR babysitting and merging.
---

# Resolve PR conflicts

Update the PR's own branch against its current base. This skill does not
authorize merging the PR or retargeting it to another base.

## Inspect and update

```sh
gh pr view <n> -R <owner/repo> --json state,headRefName,headRefOid,baseRefName,mergeable,isCrossRepository,maintainerCanModify
```

1. Confirm the PR is open and record its head SHA and base branch.
2. Work in a temporary worktree, preserving existing local edits.
3. Fetch the PR head and base from their actual repositories; record the base tip.
4. Confirm fork permissions and the destination remote before updating the PR branch.
5. Merge or rebase onto the fetched base according to the repository's guidance.

Get explicit approval before rewriting a branch you do not own, unless already
authorized in the session. Disclose every rewrite. Use an explicit
`--force-with-lease=<branch>:<recorded-head-sha>` for an authorized rewrite.
If another contributor moved the PR head, stop and reconcile with its owner.
Never push to the base branch.

## Resolve and verify

Read [the conflict guidance](references/conflicts.md) before resolving hunks.
Preserve both changes' intent and check for semantic conflicts even when Git
merges cleanly. Ask when the resolution requires a product decision.

1. Resolve the conflicts and complete the merge or rebase.
2. Run the repository's relevant build, format, lint, and tests on the combined tree.
3. Recheck the remote head and base before pushing.
4. Update and re-verify if the base moved; preserve concurrent head changes.
5. Push the verified update to the PR branch within the user's authorized scope.
6. Re-read the PR head and mergeability after the push.
7. Remove the temporary worktree after preserving the completed work.

Report the resolved conflicts, any rewrite, checks run, and remaining blockers.
Return to the calling workflow for CI watching or an authorized merge.