diff --git a/.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md b/.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
index eb36a774..66b208fc 100644
--- a/.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
+++ b/.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
@@ -87,8 +87,8 @@ Before calling `push_to_pull_request_branch`, call `ready_to_push_to_pr` and app
 - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
 2. Edit the files directly to incorporate the changes from the base branch
 3. Commit the changes as regular (single-parent) commits
-4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
diff --git a/.github/workflows/gh-aw-mention-in-pr-by-id.lock.yml b/.github/workflows/gh-aw-mention-in-pr-by-id.lock.yml
index f4fa5236..28d597d3 100644
--- a/.github/workflows/gh-aw-mention-in-pr-by-id.lock.yml
+++ b/.github/workflows/gh-aw-mention-in-pr-by-id.lock.yml
@@ -436,11 +436,11 @@ jobs:
           - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+          Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+          1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
           2. Edit the files directly to incorporate the changes from the base branch
           3. Commit the changes as regular (single-parent) commits
-          4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+          4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
           GH_AW_PROMPT_EOF
           cat << 'GH_AW_PROMPT_EOF'
           ## resolve-pull-request-review-thread Limitations
diff --git a/.github/workflows/gh-aw-mention-in-pr-no-sandbox.lock.yml b/.github/workflows/gh-aw-mention-in-pr-no-sandbox.lock.yml
index 0e971bf5..fdf177ee 100644
--- a/.github/workflows/gh-aw-mention-in-pr-no-sandbox.lock.yml
+++ b/.github/workflows/gh-aw-mention-in-pr-no-sandbox.lock.yml
@@ -44,7 +44,7 @@
 #
 # inlined-imports: true
 #
-# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"37eed9452f2bf3443bda29742805f3e384dcd059772d5238c9aa7c0737a31c4a"}
+# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"6982acd5f0acad3aff5893a6795ea36a25ff3c68fd584b2e152ec7182388db35"}
 
 name: "Mention in PR (no sandbox)"
 "on":
@@ -452,11 +452,11 @@ jobs:
           - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+          Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+          1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
           2. Edit the files directly to incorporate the changes from the base branch
           3. Commit the changes as regular (single-parent) commits
-          4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+          4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
           GH_AW_PROMPT_EOF
           cat << 'GH_AW_PROMPT_EOF'
           ## resolve-pull-request-review-thread Limitations
@@ -493,8 +493,6 @@ jobs:
           - **CAN**: Read files, search code, modify files locally, run tests and commands, leave inline review comments, submit reviews, reply to review threads, resolve review threads, push to the PR branch (same-repo only)
           - **CANNOT**: Push to fork PR branches, merge PRs, delete branches
           
-          When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-          
           ## Instructions
           
           Understand the request, investigate the code, and respond appropriately.
@@ -532,7 +530,7 @@ jobs:
              - If the fix isn't obvious from the code change alone, call `reply_to_pull_request_review_comment` with the comment's numeric ID to briefly explain what you changed.
              - If you disagree with feedback or it's unclear, call `reply_to_pull_request_review_comment` to explain your reasoning instead of making changes. Do NOT resolve the thread — let the reviewer decide.
           - Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the change and include results. If required commands cannot be run, explain why and do not push changes.
-          - Commit your changes locally, then use `push_to_pull_request_branch` to push them.
+          - Use `push_to_pull_request_branch` to push your changes.
           - 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.
           
diff --git a/.github/workflows/gh-aw-mention-in-pr-no-sandbox.md b/.github/workflows/gh-aw-mention-in-pr-no-sandbox.md
index 554fce99..4cf8c7c7 100644
--- a/.github/workflows/gh-aw-mention-in-pr-no-sandbox.md
+++ b/.github/workflows/gh-aw-mention-in-pr-no-sandbox.md
@@ -125,8 +125,6 @@ Assist with pull requests on ${{ github.repository }} — review code, fix issue
 - **CAN**: Read files, search code, modify files locally, run tests and commands, leave inline review comments, submit reviews, reply to review threads, resolve review threads, push to the PR branch (same-repo only)
 - **CANNOT**: Push to fork PR branches, merge PRs, delete branches
 
-When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-
 ## Instructions
 
 Understand the request, investigate the code, and respond appropriately.
@@ -164,7 +162,7 @@ Based on what's asked, do the appropriate thing:
    - If the fix isn't obvious from the code change alone, call `reply_to_pull_request_review_comment` with the comment's numeric ID to briefly explain what you changed.
    - If you disagree with feedback or it's unclear, call `reply_to_pull_request_review_comment` to explain your reasoning instead of making changes. Do NOT resolve the thread — let the reviewer decide.
 - Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the change and include results. If required commands cannot be run, explain why and do not push changes.
-- Commit your changes locally, then use `push_to_pull_request_branch` to push them.
+- Use `push_to_pull_request_branch` to push your changes.
 - 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.
 
diff --git a/.github/workflows/gh-aw-mention-in-pr.lock.yml b/.github/workflows/gh-aw-mention-in-pr.lock.yml
index cb3c7f5a..c43eba5a 100644
--- a/.github/workflows/gh-aw-mention-in-pr.lock.yml
+++ b/.github/workflows/gh-aw-mention-in-pr.lock.yml
@@ -44,7 +44,7 @@
 #
 # inlined-imports: true
 #
-# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"3e2208ff26fa33bb18399c3abb9067fe36fae6c3b0bd59650e6973ee1ba67b99"}
+# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"2972e3e4ad6daec077743c1fbbd759bd02ba13f71f7d4ffb4ac1c79e6ce5eb29"}
 
 name: "Mention in PR"
 "on":
@@ -464,11 +464,11 @@ jobs:
           - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+          Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+          1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
           2. Edit the files directly to incorporate the changes from the base branch
           3. Commit the changes as regular (single-parent) commits
-          4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+          4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
           GH_AW_PROMPT_EOF
           cat << 'GH_AW_PROMPT_EOF'
           ## resolve-pull-request-review-thread Limitations
@@ -506,8 +506,6 @@ jobs:
           - **CAN**: Read files, search code, modify files locally, run tests and commands, leave inline review comments, submit reviews, reply to review threads, resolve review threads, push to the PR branch (same-repo only)
           - **CANNOT**: Push to fork PR branches, merge PRs, delete branches
           
-          When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-          
           ## Instructions
           
           Understand the request, investigate the code, and respond appropriately.
@@ -545,21 +543,17 @@ jobs:
              - If the fix isn't obvious from the code change alone, call `reply_to_pull_request_review_comment` with the comment's numeric ID to briefly explain what you changed.
              - If you disagree with feedback or it's unclear, call `reply_to_pull_request_review_comment` to explain your reasoning instead of making changes. Do NOT resolve the thread — let the reviewer decide.
           - Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the change and include results. If required commands cannot be run, explain why and do not push changes.
-          - Commit your changes locally, then use `push_to_pull_request_branch` to push them.
+          - Use `push_to_pull_request_branch` to push your changes.
           - 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.
+          - Identify conflicting files by comparing with the base branch, then edit each file directly to produce the correct merged result. Commit the resolved changes as regular (single-parent) commits — do not use `git merge` or `git rebase` (the `ready_to_push_to_pr` check will catch merge commits before pushing).
+          - 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.
           - 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.
+          - Use `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.
diff --git a/.github/workflows/gh-aw-mention-in-pr.md b/.github/workflows/gh-aw-mention-in-pr.md
index 6197c442..ff840c15 100644
--- a/.github/workflows/gh-aw-mention-in-pr.md
+++ b/.github/workflows/gh-aw-mention-in-pr.md
@@ -133,8 +133,6 @@ Assist with pull requests on ${{ github.repository }} — review code, fix issue
 - **CAN**: Read files, search code, modify files locally, run tests and commands, leave inline review comments, submit reviews, reply to review threads, resolve review threads, push to the PR branch (same-repo only)
 - **CANNOT**: Push to fork PR branches, merge PRs, delete branches
 
-When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-
 ## Instructions
 
 Understand the request, investigate the code, and respond appropriately.
@@ -172,21 +170,17 @@ Based on what's asked, do the appropriate thing. **Requests can combine multiple
    - If the fix isn't obvious from the code change alone, call `reply_to_pull_request_review_comment` with the comment's numeric ID to briefly explain what you changed.
    - If you disagree with feedback or it's unclear, call `reply_to_pull_request_review_comment` to explain your reasoning instead of making changes. Do NOT resolve the thread — let the reviewer decide.
 - Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the change and include results. If required commands cannot be run, explain why and do not push changes.
-- Commit your changes locally, then use `push_to_pull_request_branch` to push them.
+- Use `push_to_pull_request_branch` to push your changes.
 - 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.
+- Identify conflicting files by comparing with the base branch, then edit each file directly to produce the correct merged result. Commit the resolved changes as regular (single-parent) commits — do not use `git merge` or `git rebase` (the `ready_to_push_to_pr` check will catch merge commits before pushing).
+- 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.
 - 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.
+- Use `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.
diff --git a/.github/workflows/gh-aw-pr-actions-fixer.lock.yml b/.github/workflows/gh-aw-pr-actions-fixer.lock.yml
index c38f4bab..e9511d38 100644
--- a/.github/workflows/gh-aw-pr-actions-fixer.lock.yml
+++ b/.github/workflows/gh-aw-pr-actions-fixer.lock.yml
@@ -37,7 +37,7 @@
 #
 # inlined-imports: true
 #
-# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"067ef5b1714251b55aa9fc1316a2fda34c0f3af4158afe58b21c4637ae7f99c0"}
+# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"d2c2b776d3dee5aa475d84d57680bab8f10089e1b661026e268673e5b6c052d0"}
 
 name: "PR Actions Fixer"
 "on":
@@ -297,11 +297,11 @@ jobs:
           - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+          Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+          1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
           2. Edit the files directly to incorporate the changes from the base branch
           3. Commit the changes as regular (single-parent) commits
-          4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+          4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
           GH_AW_PROMPT_EOF
           cat << 'GH_AW_PROMPT_EOF'
           
@@ -321,8 +321,6 @@ jobs:
           - **CAN**: Read files, search code, modify files locally, run tests and commands, comment on PRs, push changes to same-repo PR branches
           - **CANNOT**: Push to fork PR branches, merge PRs, or modify `.github/workflows/`
           
-          When pushing changes, the workspace already has the PR branch checked out. Make your changes, run tests, commit them locally, then use `push_to_pull_request_branch`.
-          
           ## Instructions
           
           ### Step 1: Gather Context
@@ -352,7 +350,7 @@ jobs:
           ### Step 2: Analyze and Fix
           
           - Identify the failing job/step and summarize the root cause.
-          - If the fix is straightforward and safe, implement it locally, run tests, commit, and push to the PR branch.
+          - If the fix is straightforward and safe, implement it locally, run tests, and push to the PR branch.
           - If the fix is risky or requires broader refactoring, propose a concrete remediation plan instead of pushing.
           - If the PR is from a fork, do not push; provide patch guidance in the comment.
           
diff --git a/.github/workflows/gh-aw-pr-actions-fixer.md b/.github/workflows/gh-aw-pr-actions-fixer.md
index 241674f8..570e49b7 100644
--- a/.github/workflows/gh-aw-pr-actions-fixer.md
+++ b/.github/workflows/gh-aw-pr-actions-fixer.md
@@ -94,8 +94,6 @@ Assist with failed GitHub Actions checks for pull requests in ${{ github.reposit
 - **CAN**: Read files, search code, modify files locally, run tests and commands, comment on PRs, push changes to same-repo PR branches
 - **CANNOT**: Push to fork PR branches, merge PRs, or modify `.github/workflows/`
 
-When pushing changes, the workspace already has the PR branch checked out. Make your changes, run tests, commit them locally, then use `push_to_pull_request_branch`.
-
 ## Instructions
 
 ### Step 1: Gather Context
@@ -125,7 +123,7 @@ When pushing changes, the workspace already has the PR branch checked out. Make
 ### Step 2: Analyze and Fix
 
 - Identify the failing job/step and summarize the root cause.
-- If the fix is straightforward and safe, implement it locally, run tests, commit, and push to the PR branch.
+- If the fix is straightforward and safe, implement it locally, run tests, and push to the PR branch.
 - If the fix is risky or requires broader refactoring, propose a concrete remediation plan instead of pushing.
 - If the PR is from a fork, do not push; provide patch guidance in the comment.
 
diff --git a/.github/workflows/gh-aw-pr-review-addresser.lock.yml b/.github/workflows/gh-aw-pr-review-addresser.lock.yml
index b7454986..eded7694 100644
--- a/.github/workflows/gh-aw-pr-review-addresser.lock.yml
+++ b/.github/workflows/gh-aw-pr-review-addresser.lock.yml
@@ -40,7 +40,7 @@
 #
 # inlined-imports: true
 #
-# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"a75125e9e8e3ea172d6e4e27fb0b9fd66bd2403dfcb81a93da21c00f7d9aeeae"}
+# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"88cc1828871afb2677899a47eb636bf7e099fc47f675a98974424195fb17a32c"}
 
 name: "PR Review Addresser"
 "on":
@@ -308,11 +308,11 @@ jobs:
           - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+          Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+          1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
           2. Edit the files directly to incorporate the changes from the base branch
           3. Commit the changes as regular (single-parent) commits
-          4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+          4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push
           GH_AW_PROMPT_EOF
           cat << 'GH_AW_PROMPT_EOF'
           ## resolve-pull-request-review-thread Limitations
@@ -348,8 +348,6 @@ jobs:
           - **CAN**: Read files, search code, modify files locally, run tests and commands, reply to review comments, push to the PR branch (same-repo only), resolve review threads
           - **CANNOT**: Push to fork PR branches, merge PRs, delete branches, modify `.github/workflows/` files
           
-          When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-          
           ## Instructions
           
           Address the review feedback surgically — make only the minimum changes needed.
@@ -377,7 +375,7 @@ jobs:
           ### Step 3: Validate and Push
           
           1. Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the changes and include results. If required commands cannot be run, explain why and do not push changes.
-          2. Commit your changes locally with a descriptive message, then use `push_to_pull_request_branch` to push them.
+          2. Use `push_to_pull_request_branch` to push your changes.
           3. **Fork PRs**: If this is a fork PR, 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.
           
           ### Step 4: Resolve Addressed Threads
diff --git a/.github/workflows/gh-aw-pr-review-addresser.md b/.github/workflows/gh-aw-pr-review-addresser.md
index 8661ec35..e5fe15bb 100644
--- a/.github/workflows/gh-aw-pr-review-addresser.md
+++ b/.github/workflows/gh-aw-pr-review-addresser.md
@@ -111,8 +111,6 @@ Automatically address review feedback on pull requests in ${{ github.repository
 - **CAN**: Read files, search code, modify files locally, run tests and commands, reply to review comments, push to the PR branch (same-repo only), resolve review threads
 - **CANNOT**: Push to fork PR branches, merge PRs, delete branches, modify `.github/workflows/` files
 
-When pushing changes, the workspace already has the PR branch checked out. Make your changes, commit them locally, then use `push_to_pull_request_branch`.
-
 ## Instructions
 
 Address the review feedback surgically — make only the minimum changes needed.
@@ -140,7 +138,7 @@ For each unresolved review thread:
 ### Step 3: Validate and Push
 
 1. Run required repo commands (lint/build/test) from README, CONTRIBUTING, DEVELOPING, Makefile, or CI config relevant to the changes and include results. If required commands cannot be run, explain why and do not push changes.
-2. Commit your changes locally with a descriptive message, then use `push_to_pull_request_branch` to push them.
+2. Use `push_to_pull_request_branch` to push your changes.
 3. **Fork PRs**: If this is a fork PR, 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.
 
 ### Step 4: Resolve Addressed Threads
diff --git a/github/workflows/gh-aw-fragments/safe-output-push-to-pr.md b/github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
index b02286f7..6a773692 100644
--- a/github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
+++ b/github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
@@ -102,8 +102,8 @@ Before calling `push_to_pull_request_branch`, call `ready_to_push_to_pr` and app
 - **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 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 diff HEAD...origin/<base-branch>` (base branch from `/tmp/pr-context/pr.json` field `baseRefName`) to see what the base branch changed in the conflicting files
+Trying to resolve merge conflicts? Do not use `git merge` or `git rebase` — `push_to_pull_request_branch` uses `git format-patch` which requires single-parent commits. Instead:
+1. Compare with the base branch (from `/tmp/pr-context/pr.json` field `baseRefName`) to see what changed in the conflicting files
 2. Edit the files directly to incorporate the changes from the base branch
 3. Commit the changes as regular (single-parent) commits
-4. Once you are done with all of your changes on this branch, call `ready_to_push_to_pr` and then `push_to_pull_request_branch` to push
+4. Call `ready_to_push_to_pr` (which will catch any merge commits) and then `push_to_pull_request_branch` to push