add merge conflict instructions

.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md

@@ -64,8 +64,8 @@ Before calling `push_to_pull_request_branch`, call `ready_to_make_pr` and apply
 - **Branch**: Pushes to the PR's head branch. The workspace must have the PR branch checked out.
 - You may not submit code that modifies files in `.github/workflows/`. Doing so will cause the submission to be rejected. If asked to modify workflow files, propose the change in a copy placed in a `github/` folder (without the leading period) and note in the PR that the file needs to be relocated by someone with workflow write access.
 
-Trying to resolve merge conflicts? Do NOT use `git merge` or `git rebase`. Instead:
-1. Compare the conflicting files between this PR branch and origin/main
-2. Edit the files directly to incorporate the changes from main
-3. Commit the changes as regular commits
+Trying to resolve merge conflicts? Do NOT create merge commits (commits with multiple parents) — `push_to_pull_request_branch` uses `git format-patch` which breaks on merge commits. This means: no `git merge`, no `git rebase`, no `git commit-tree` with multiple `-p` flags. Instead:
+1. Use `git merge-tree` or `git diff` to compare the conflicting files between this PR branch and the PR base branch (read from `/tmp/pr-context/pr.json`)
+2. Edit the files directly to incorporate the changes from the base branch
+3. Commit the changes as regular (single-parent) commits
 4. Use push_to_pull_request_branch to push

.github/workflows/gh-aw-mention-in-pr.md

@@ -150,7 +150,7 @@ PR context is pre-fetched to `/tmp/pr-context/`. Read `/tmp/pr-context/README.md
 
 ### Step 2: Handle the Request
 
-Based on what's asked, do the appropriate thing:
+Based on what's asked, do the appropriate thing. **Requests can combine multiple actions** (e.g., "fix merge conflicts and address the review feedback"). When they do, handle them in this order: merge conflicts first, then code changes/review feedback, then push once at the end. Do not push between steps — batch all changes into a single push.
 
 **If asked to review the PR:**
 - Read `/tmp/pr-context/review_comments.json` and `/tmp/pr-context/reviews.json` to check existing threads and prior reviews — do not duplicate feedback.
@@ -175,6 +175,18 @@ Based on what's asked, do the appropriate thing:
 - After pushing, resolve every review thread that your changes address by calling `resolve_pull_request_review_thread` with the thread's GraphQL node ID (the `id` field, e.g., `PRRT_kwDO...`). This includes threads left by other reviewers AND threads from your own prior reviews. Check `/tmp/pr-context/review_comments.json` for all unresolved threads (`isResolved: false`) — `isOutdated` threads have had the underlying code changed since the comment was made, so check whether your changes address them. Do NOT resolve threads you disagreed with, skipped, or only partially addressed — leave those open for the reviewer.
 - **Fork PRs**: Check via `pull_request_read` with method `get` whether the PR head repo differs from the base repo. If it's a fork, you cannot push — reply explaining that you do not have permission to push to fork branches and suggest that the PR author apply the changes themselves. This is a GitHub security limitation. You can still review code, make local changes, and provide suggestions.
 
+**If asked to fix merge conflicts:**
+- Check via `pull_request_read` (method `get`) whether this is a fork PR. If so, reply that you cannot push to fork branches and suggest the author resolve locally.
+- Read `/tmp/pr-context/pr.json` for the head and base branch names.
+- Do NOT create merge commits — `push_to_pull_request_branch` generates patches via `git format-patch`, which breaks on merge commits (commits with multiple parents). This means: no `git merge`, no `git rebase`, no `git commit-tree` with multiple `-p` flags. Instead, resolve conflicts manually:
+  1. Fetch the base branch: `git fetch origin "<base-branch>"`
+  2. Use `git merge-tree` or `git diff origin/"<base-branch>"` to identify conflicting files and understand both sides.
+  3. Edit each conflicting file directly to incorporate the changes from the base branch, producing the correct merged result.
+  4. Commit the resolved changes as a regular (single-parent) commit.
+- If conflicts are too complex to resolve confidently (large structural changes, binary files, ambiguous intent), reply explaining what you found and suggest the author resolve locally. Do NOT push a bad resolution or proceed with other requested work that depends on a clean merge.
+- If the request includes additional work (code fixes, review feedback), complete all of it before pushing — `push_to_pull_request_branch` can only be called once. Resolve merge conflicts first, then make other requested changes on top, then push everything together.
+- Push via `push_to_pull_request_branch` and reply summarizing what was resolved and how conflicts were handled.
+
 **If asked a question about the code:**
 - Find the relevant code and explain it.
 - Use `grep` and file reading to gather context.