Send Conflict-Fix Instructions Back to Agents

AI agent conflict resolution is not a separate magic trick. It is a follow-up coding task with a very specific goal: resolve the current pull request's conflicts, preserve the intended change, commit the resolution, and push to the same remote branch.

That is a better framing than "the agent made a mess." Merge conflicts happen whenever branches contain competing changes. GitHub's own merge-conflict docs explain that simple conflicts can sometimes be resolved in the web editor, while other conflicts must be resolved locally and pushed back to the branch. Agent-generated pull requests are still pull requests. They drift when the base branch moves, when another developer touches the same file, or when multiple agent runs target related code.

Junction gives you a cleaner loop for handling that drift. Because the daemon runs on your machine and agents execute in the local repo, Junction can send conflict-fix instructions back to the existing Claude Code or Codex chat tied to that workspace. You can keep the branch, context, output stream, Git diff, and pull request flow together instead of abandoning the run.

Why conflicts are different from ordinary code review

A normal review comment asks for a change to the implementation. A merge conflict asks the branch to reconcile two histories. GitHub's web conflict editor documentation is useful for simple cases, but agent-generated PRs often still benefit from local resolution because the daemon can run the repo's normal checks.

That distinction matters because the agent needs different context:

• The current branch name.
• The target branch name.
• The pull request state.
• The conflicted files.
• The original intent of the change.
• The command or workflow needed to verify the resolution.

If you simply say "fix the PR," the agent may focus on style, tests, or implementation details. A conflict-fix prompt should be more constrained.

In Junction, the PR action flow can send a purpose-built instruction back to the current workspace chat: the current PR has merge conflicts with its target branch, resolve the conflicts, commit the resolution, and push to the same remote PR. That wording is intentionally narrow. It tells the agent not to start a new implementation, not to create a separate branch, and not to lose the existing pull request.

A good conflict-fix prompt

When you need to write the prompt yourself, use this shape:

The current pull request has merge conflicts with its target branch.
 
Please resolve the conflicts locally, preserve the intended behavior from this branch,
commit the resolution, and push to the same remote PR.
 
Current branch: sb/platform-issue-123
Target branch: main
 
After resolving, run the focused tests for the touched area and report what changed.

That prompt has five important properties:

• It states the exact problem.
• It tells the agent to work in the current branch.
• It tells the agent to preserve the existing intent.
• It tells the agent to push to the same pull request.
• It defines verification.

The instruction should not ask the agent to re-implement the whole feature unless the branch is truly unrecoverable.

What Junction adds to the loop

Terminal-only conflict resolution works, but it is awkward when the run started from a mobile workflow or Switchboard automation. You may have to find the right worktree, inspect the PR, paste conflict details into the agent, watch the terminal, then manually confirm whether the branch was pushed.

Junction keeps those surfaces together:

• The daemon already knows the local workspace.
• The chat is tied to the current agent session.
• The right sidebar can expose Git, diff, file, and PR context.
• Conflict-fix instructions can be sent back to the current chat.
• Output streams live while the agent works.
• The diff can be reviewed before merge.
• Switchboard can keep route context attached to issue-to-PR automation.

This does not remove the need for human review. It removes the friction of reconstructing context after the PR falls out of a mergeable state.

When to let the agent resolve conflicts

Agent-assisted conflict resolution is useful when the conflict is mechanical or well bounded.

Good candidates:

• Two branches changed nearby copy or UI layout.
• The base branch moved imports, names, or helper functions.
• A generated file or snapshot needs a known regeneration command.
• A test file changed around the same assertions.
• The agent's branch is small and the original intent is clear.

Poor candidates:

• A migration conflict that changes production data semantics.
• Auth, billing, or permissions code with ambiguous behavior.
• Large architectural refactors on both sides of the conflict.
• Conflicts where neither side is obviously correct.
• Branches that no longer match the product requirement.

For poor candidates, use the agent to prepare a plan or explain the conflict first. Do not let it push a resolution without review.

Review the resolution like any other change

The conflict markers disappearing is not enough. The branch can compile and still choose the wrong behavior.

Review these points:

• Did the agent remove all conflict markers?
• Did it preserve the intended change from the PR?
• Did it include the necessary base-branch updates?
• Did it avoid unrelated refactors?
• Did it run the relevant tests?
• Did it commit only the conflict resolution and necessary follow-up edits?
• Did it push to the same remote branch?

Junction's diff review helps here because the control surface is not just a chat transcript. You can inspect the actual code changes, use file browser context, watch terminal output, and decide whether the PR is ready.

Conflict prevention starts earlier

The best conflict workflow is still prevention.

For AI coding agents, that means:

• Use isolated git worktrees for agent sessions.
• Keep one task per branch when possible.
• Keep prompts narrow.
• Avoid running multiple agents against the same files without coordination.
• Rebase or refresh long-running branches before review.
• Keep Switchboard route concurrency conservative for high-churn repos.
• Use branch prefixes so generated work is easy to identify.

Junction already supports workflows that help with this: worktree isolation, branch review, live output monitoring, and route-level concurrency for Switchboard. The post on git worktree isolation for AI coding agents goes deeper on keeping runs from stepping on each other before conflicts appear.

Manual runs versus Switchboard runs

For a manual Junction chat, a conflict usually appears while you are reviewing the branch or trying to create or update a pull request. The fix loop is direct: send the conflict instruction to the active chat, watch the agent resolve, review the diff, and continue.

For Switchboard, conflict handling is part of the issue-to-pull-request lifecycle. A route may create a branch and PR from a Linear issue, but the base branch can still move before merge. When that happens, the route context matters: which daemon owns the repo, which agent created the work, which branch policy was used, and whether the team expects the agent to resolve conflicts or pause for human review.

That is why route settings and review habits matter. Automation should be fast enough to remove busywork, but explicit enough that a conflict does not become invisible.

A practical phone workflow

You do not need to be at your desk to keep a conflicted PR moving.

1. Open Junction from your phone.
2. Open the workspace or Switchboard run tied to the PR.
3. Check the PR action state and the latest agent output.
4. Send conflict-fix instructions back to the current chat.
5. Watch for commands, edits, errors, and completion.
6. Review the updated diff.
7. Merge only after the checks and review state are acceptable.

Your code still stays on the machine running the daemon. The phone is the control surface for supervising the local resolution.

Tradeoffs and failure modes

The agent may choose the wrong side of a conflict if the product intent is ambiguous. Give it context before asking it to push.

The branch may be too stale. If the base branch changed substantially, a new implementation may be cleaner than a conflict resolution.

The agent may need credentials or tooling available only on the daemon machine. If Git authentication, package installs, or test dependencies are broken locally, fix that environment first.

The provider may hit rate limits during the follow-up. Junction can help you inspect and manage runs, but provider accounts still enforce their own usage limits.

Finally, do not skip review because an agent resolved the conflict. Treat the resolution as code written under pressure. It deserves a focused diff pass.

The clean recovery loop

A strong conflict workflow looks like this:

• Keep the original PR branch.
• Send a narrow conflict-fix instruction.
• Preserve the branch's intended behavior.
• Resolve locally on the daemon machine.
• Run focused verification.
• Commit and push to the same remote PR.
• Review the diff before merge.

That loop is exactly where Junction is useful: local execution, remote visibility, agent output streaming, Git review, and follow-up prompts from the same control surface. If you already use Junction for PR creation, connect this workflow with turning local agent runs into pull requests and reviewing agent diffs from your phone.