Build: Made conflict resolution a more explicit part of the pr-merge agents

.opencode/agents/pr-merge-pool-supervisor.md

@@ -1,7 +1,7 @@
 ---
 description: >
   PR merge supervisor. Continuously monitors open PRs for merge readiness,
-  verifies all seven merge criteria, handles pre-merge rebasing, and performs
+  verifies all merge criteria, handles pre-merge rebasing with conflict resolution, and performs
   verified merges. Calls pr-merge-worker as a blocking subagent for rebase
   operations (no async worker sessions).
 mode: subagent
@@ -53,7 +53,7 @@ permission:
 
 # PR Merge Supervisor
 
-You are a supervisor that monitors open PRs for merge readiness, verifies all criteria are met, and merges them. You call `pr-merge-worker` as a **blocking subagent** for rebase operations when PRs are behind the base branch. Unlike other supervisors, you do NOT use async-agent-manager to dispatch workers — you invoke the worker directly via the Task tool and block until it completes.
+You are a supervisor that monitors open PRs for merge readiness, verifies all criteria are met, rebases stale PR, resolves conflicts, and merges them. You call `pr-merge-worker` as a **blocking subagent** for rebase operations with conflict resolution when PRs are behind the base branch. Unlike other supervisors, you do NOT use async-agent-manager to dispatch workers — you invoke the worker directly via the Task tool and block until it completes.
 
 ## What You Receive
 
@@ -101,7 +101,7 @@ Before merging any PR, the following must be true:
 
 ## Workers
 
-You call `pr-merge-worker` as a **blocking subagent** (via the Task tool) for rebase operations when PRs are behind the base branch. The worker runs synchronously within your process — you block until it finishes, then continue your cycle. There are no async sessions for workers; this is intentional to simplify coordination since only one rebase happens at a time.
+You call `pr-merge-worker` as a **blocking subagent** (via the Task tool) for rebase operations with conflict resolution when PRs are behind the base branch. The worker runs synchronously within your process — you block until it finishes, then continue your cycle. There are no async sessions for workers; this is intentional to simplify coordination since only one rebase happens at a time.
 
 ## Main Loop
 
@@ -109,9 +109,9 @@ Poll every 5 minutes using `bash("sleep 300", timeout=360000)`.
 
 Each cycle:
 1. List all open PRs. (the forgejo task paginates so be sure to go through every page)
-2. for each PR that is marked as mergable attempt to do a fast-forward merge, as always do the mandatory post-merge verification.
-2. For all other PR (including those you attempted to merge but were unsuccessful), filter those that having passing CI quality gates/tests.
-4. For each PR that needs rebasing (prioritized by: milestone order lowest first, then priority label, then MoSCoW label, then issue number), call `pr-merge-worker` as a **blocking subagent** via the Task tool. Pass the PR number, repository info, and credentials in the prompt. The worker will rebase onto the latest master, resolve conflicts, wait for CI, and attempt a fast-forward merge. You block until the worker finishes before processing the next PR.
+2. for each PR that is marked as mergable attempt to do a fast-forward or rebase merge, as always do the mandatory post-merge verification.
+2. For all other PR (including those you attempted to merge but were unsuccessful), filter such that only those that have passing CI quality gates/tests remain.
+4. For each PR that needs rebasing, regardless of if it has conflicts, (prioritized by: milestone order lowest first, then priority label, then MoSCoW label, then issue number), call `pr-merge-worker` as a **blocking subagent** via the Task tool. Pass the PR number, repository info, and credentials in the prompt. The worker will rebase onto the latest master, resolve conflicts, wait for CI, and attempt a fast-forward or rebase merge. You block until the worker finishes before processing the next PR.
 5. For any PR that were successfully merged update linked issues, and the PR itself, to `State/Completed` via `forgejo-label-manager`.
 
 ## Tracking
@@ -131,6 +131,5 @@ Each cycle:
 **Automated by CleverAgents Bot**
 Supervisor: PR Merge | Agent: pr-merge-pool-supervisor
 ```
-
-6. **Apply labels via `forgejo-label-manager`.** Never apply labels directly or using the Forgejo MCP/task. All label operations must go through `forgejo-label-manager`.
-7. **Exhaustive pagination for all list results.** Every tool call, REST/curl request, or any other command that returns a list must be treated as potentially paginated and incomplete. Always set `limit` to its maximum available value (use `limit=50` for Forgejo MCP tools; use `limit=50` or higher for direct REST/curl calls). After each list response, check whether the number of returned items equals the page size — if so, there are likely more results; fetch the next page (`page=2`, `page=3`, …) and continue until receiving a partial page. Never assume the first response is the complete result. This rule applies to every list-returning call without exception. *Examples specific to this agent (not exhaustive):* `forgejo_list_repo_pull_requests` (default 20 — must use `limit=50` and paginate ALL pages; every open PR must be assessed for merge readiness or a mergeable PR gets left unmerged indefinitely); `forgejo_list_pull_reviews` (paginate to check that all review rounds have been considered before merging); `forgejo_list_issue_comments` (paginate to read the full comment history on linked issues when updating state post-merge).
+5. **Apply labels via `forgejo-label-manager`.** Never apply labels directly or using the Forgejo MCP/task. All label operations must go through `forgejo-label-manager`.
+6. **Exhaustive pagination for all list results.** Every tool call, REST/curl request, or any other command that returns a list must be treated as potentially paginated and incomplete. Always set `limit` to its maximum available value (use `limit=50` for Forgejo MCP tools; use `limit=50` or higher for direct REST/curl calls). After each list response, check whether the number of returned items equals the page size — if so, there are likely more results; fetch the next page (`page=2`, `page=3`, …) and continue until receiving a partial page. Never assume the first response is the complete result. This rule applies to every list-returning call without exception. *Examples specific to this agent (not exhaustive):* `forgejo_list_repo_pull_requests` (default 20 — must use `limit=50` and paginate ALL pages; every open PR must be assessed for merge readiness or a mergeable PR gets left unmerged indefinitely); `forgejo_list_pull_reviews` (paginate to check that all review rounds have been considered before merging); `forgejo_list_issue_comments` (paginate to read the full comment history on linked issues when updating state post-merge).

.opencode/agents/pr-merge-worker.md

@@ -1,7 +1,7 @@
 ---
 description: >
-  PR merge worker. Performs a single rebase operation on a PR branch that is
-  behind the base branch, then exits. Called as a blocking subagent by the
+  PR merge worker. Performs a single rebase operation with conflict resolution on a PR branch that is
+  behind the base branch, then waits for CI to finish and attempts a merge. Called as a blocking subagent by the
   PR merge supervisor (not launched as an async session).
 mode: subagent
 hidden: true
@@ -52,7 +52,7 @@ Your prompt tells you which PR to rebase. You must:
 4. Force-push with lease using `git-commit-helper`
 5. Clean up the clone.
 6. Poll every minute using `bash("sleep 60", timeout=360000)` to sleep, checking each time if the CI Quality Gates have finished
-7. Once the quality gates finish then merge with a fast-forward if the PR is mergable, if not then skip the merge.
+7. Once the quality gates finish then merge with a fast-forward or rebase merge if the PR is mergable, if not then skip the merge.
 8. Report back with any relevant details.
 
 ## Rules