用途：当用户希望完整解决活动 PR 上的合并冲突（而非只查看）时使用本技能。流程为：识别 PR 基础分支、本地将基础分支合并进当前分支、在不丢弃分支原有工作的前提下解决冲突文件、验证合并结果、提交合并、推送分支。
前置条件：当前分支应已是待更新的 PR 分支；若需检查 PR 元数据，gh 需已对该仓库完成认证；不要假设本地已存在冲突，应先检查。
工作流：先用 git status --short --branch、git diff --name-only --diff-filter=U、gh pr view --json number,title,baseRefName,headRefName,url 检查分支与 PR 上下文。若冲突列表为空，说明工作区可能尚无进行中的冲突合并。然后 git fetch origin，再执行 git merge --no-edit origin/<base-branch>（如 origin/main、origin/develop）。出现冲突后用 git diff --name-only --diff-filter=U 列出冲突文件，编辑前先阅读，用 rg -n "^(<<<<<<<|=======|>>>>>>>)" <file> 定位冲突标记。解决时保留当前分支的功能意图，吸收基础分支的兼容改动，完全移除冲突标记，大文件不要盲目取一侧。编辑后用 rg -n "^(<<<<<<<|=======|>>>>>>>)" src 确认无残留标记。
验证：建议基线为 pnpm typecheck，再针对涉及文件运行聚焦测试（如 pnpm exec vitest run src/main/issue-resolution.test.ts）；若冲突影响可见 UI，再用 Playwright 做真实浏览器检查。随后 git add <resolved-files>、git status、git commit --no-edit 完成合并提交，最后 git push origin <current-branch> 推送。
决策标准：不要在不理解任一侧行为的情况下丢弃它；当 PR 目的即架构方向时优先功能分支方向；基础分支的新共享 API、测试与接线若能干净整合则优先采用。
常见陷阱：假设本地已有冲突；只修编译错误而忽略测试预期漂移；编辑了文件却未暂存导致仍标记 UU；忘记合并提交尚未完成；验证前就推送。
限制：仅依据公开资料整理，未提供具体支持平台、收费或价格信息。