docs(skill): 让 resolve-pr 定位 PR 分支并处理冲突

.agents/skills/resolve-pr/SKILL.md

@@ -8,9 +8,26 @@ description: Address actionable feedback on an existing pull request, including
 ## Workflow
 
 1. Identify the PR from the supplied URL or number, otherwise from the current
-   branch. Verify the repository and that this checkout matches the PR head
-   before editing. If the target is ambiguous, stop before editing. Preserve
-   unrelated local changes; do not rebase or reset without a request.
+   branch. Read its head repository, branch, and SHA; check the current branch,
+   worktree status, and other worktrees before editing. If already on the PR
+   head branch in the right repository, stay in this worktree; if that branch
+   is checked out in another worktree, use that worktree. Otherwise follow
+   `git-worktree` safety checks, validate the branch name and target path, and
+   create `.worktrees/<head-branch>` without disturbing the current worktree:
+   - For an existing local PR branch, use `git worktree add <path> <branch>`;
+     do not pass `-b` or create a second branch.
+   - For a missing local branch, fetch the PR head from its repository, verify
+     the fetched SHA, then use `git worktree add --track -b <branch> <path>
+     <remote>/<branch>`. Do not branch from the PR base.
+   Verify the selected branch's upstream points to a writable remote for the
+   PR head. If an existing branch has no upstream, first verify the remote ref
+   matches the PR head, then run `git branch --set-upstream-to=<remote>/<branch>
+   <branch>`; stop if its upstream points elsewhere. Fast-forward a
+   clean branch that is behind the PR head only when safe. Inspect local commits
+   or dirty changes and continue only when they belong to this PR. Stop before
+   editing if the branch diverged, the path is occupied, fork access is
+   unavailable, or the target is ambiguous. Do not rebase or reset without a
+   request.
 2. Read repository guidance, worktree status, the current diff, unresolved
    review threads (including replies), non-empty review bodies, and top-level
    PR comments. Paginate each surface and deduplicate repeated feedback. Ignore
@@ -20,6 +37,11 @@ description: Address actionable feedback on an existing pull request, including
    it is already addressed, or explain factually why it is incorrect or out of
    scope. Group related fixes by root cause.
 4. For code changes, make the smallest coherent fix and run relevant validation.
+   If Git reports unmerged paths during the requested PR work, verify they
+   belong to this PR, then use `resolve-merge-conflicts` to inspect and resolve
+   them. Complete the interrupted Git operation, rerun affected validation,
+   and only then continue with the PR fix. This does not authorize starting a
+   rebase or reset merely to sync the branch.
    Use `git-commit` and `git-push` to commit and publish fixes. Do not commit
    when feedback only needs an answer or verification.
 5. Resolve a review thread only after its requested outcome is complete and
@@ -39,7 +61,8 @@ are needed.
 
 ## Report
 
-Report fixes, answers, already-addressed or declined items, reviewer follow-up,
-resolved threads, commits pushed, validation, and CI state. Do not call review
+Report the PR branch/worktree used, fixes, answers, already-addressed or
+declined items, reviewer follow-up, resolved threads, commits pushed,
+validation, and CI state. Do not call review
 bodies or top-level comments resolved, or imply a commit or push when none was
 needed.