Turn Local AI Agent Runs Into Pull Requests

An AI agent pull request workflow should not start when the pull request opens. It starts before Claude Code or Codex edits the first file.

That is the difference between an agent run that leaves behind a messy patch and an agent run that becomes a reviewable change. The agent can write code, run commands, and explain decisions, but the workflow still needs branch discipline, verification, diff review, and a clear handoff for reviewers.

GitHub's pull request documentation describes pull requests as a way to propose, review, and merge code changes. That review shape matters even more when the first implementation pass came from an AI coding agent. Reviewers need to know what changed, why it changed, how it was tested, and where the risky parts are.

Junction helps because the run stays local. The daemon runs on your machine, Claude Code or Codex works where your code already lives, and the browser or phone becomes the control surface for streaming output, approvals, stopping sessions, Git review, notifications, and pull-request handoff.

Before the Agent Starts

The easiest way to improve an agent-generated pull request is to make the work reviewable before the prompt.

Use a dedicated branch or worktree. Make sure the base branch is current. Decide whether the task is implementation, investigation, review, or cleanup. Then give the agent a prompt that contains scope, verification, and a stop condition.

For example:

Implement the empty-state copy change for the pricing page.
 
Scope:
- Edit the pricing page copy and the related site test only.
- Do not change plan limits, billing behavior, provider setup, or homepage copy.
 
Verification:
- Run the focused site test for pricing.
- If that passes, run the site typecheck.
 
Stop condition:
- If a product behavior change appears necessary, explain it before editing anything outside the pricing page.

This prompt does four useful things:

• It tells the agent what success means.
• It names the files and areas that should not change.
• It gives a verification command.
• It creates a moment where the agent should stop instead of improvising.

That is what makes the future pull request smaller.

During the Run

While the agent works, your job is not to stare at every token. Your job is to notice when the run changes shape.

In Junction, you can monitor the output stream from a browser or phone. That gives you enough context to answer practical questions:

• Is the agent still working on the stated task?
• Is it asking for an approval that matches the scope?
• Did it start editing unrelated files?
• Is it repeatedly running the same failing command?
• Does the final direction still match the branch name?

Approvals are especially important. A command can be technically valid and still be wrong for the PR. If the task was a focused copy change and the agent asks to rewrite a billing helper, the answer might be "stop and explain," not "approve."

This is where local-first control matters. You do not have to move the repository into a cloud sandbox to supervise the work away from your desk. The daemon stays on your machine and Junction gives you the control surface.

Before Opening the Pull Request

Do not open the pull request just because the agent says it is done.

Run a short pre-PR checklist:

Junction's Git and diff review surfaces help here because the transcript, approvals, and changed files are close together. You can see what the agent claimed, what it actually changed, and whether the verification output supports the result.

If the diff is larger than expected, do not rationalize it after the fact. Either split the change, send the agent back with narrower instructions, or abandon the run and start again from a clean branch.

Write the PR Like a Human Reviewer Will Read It

An agent-generated change still needs a human-quality PR description.

Use a compact template:

Summary:
- Updated pricing empty-state copy.
- Adjusted the matching site test.
 
Why:
- The previous copy did not explain the next action clearly.
 
Verification:
- pnpm --filter @junctionpanel/site run test -- pricing
- pnpm --filter @junctionpanel/site run typecheck
 
Review notes:
- No plan limits or billing behavior changed.
- The diff should be copy and test coverage only.

The goal is not to narrate every agent turn. The goal is to make review faster. A reviewer should be able to compare the stated scope with the diff and decide where to focus.

If the agent made decisions that are not obvious from the code, summarize them. If the agent hit a failed command and then fixed it, include the final successful command. If a test could not be run, say so plainly.

Example Workflow

Here is a realistic local agent run to PR flow:

1. Create a branch named fix/pricing-empty-state-copy.
2. Start Claude Code or Codex from the repo or worktree.
3. Give the agent a bounded prompt with scope, verification, and stop conditions.
4. Monitor the output in Junction while away from the desk.
5. Approve only commands that match the task.
6. Stop the run if it edits unrelated pricing logic.
7. Review the final diff in Junction.
8. Run the required verification locally if the agent did not run it.
9. Open a PR with summary, why, verification, and review notes.

That workflow is deliberately boring. Boring is good. It makes the PR review about the code, not about reconstructing what an agent did.

When Switchboard Is the Better Fit

Manual PR handoff is the right workflow when a developer still wants to decide when the agent starts, what branch it uses, and when the result becomes a pull request.

Switchboard is for a different shape: issue-to-pull-request automation. On the Switchboard plan, Junction can route Linear automation so a well-written issue can become an agent workflow. That is useful when the input quality is consistent and the review gate is clear.

The two workflows should not be blurred:

• Use a manual local run when the task needs judgment before the agent starts.
• Use Switchboard when the issue is structured enough to become repeatable automation.
• In both cases, review the resulting diff before merge.

If you are preparing issues for automation, read Write Linear Issues Ready for AI Agent Automation. If you are reviewing an agent diff from mobile, read How to Review AI Agent Diffs from Your Phone.

Tradeoffs and Failure Modes

Not every agent run deserves a pull request.

Do not open a PR when:

• The agent changed files outside the stated scope without a clear reason.
• Verification failed and the failure is not understood.
• The diff mixes unrelated changes.
• The description would require hand-waving.
• You have not reviewed the generated code.

There is also a timing tradeoff. Sometimes mobile review is enough to stop a bad run, approve a safe command, or confirm that a small diff is ready. For high-risk changes, you may still want a full desktop review before opening the PR. Junction gives you remote control and visibility; it does not remove the need for judgment.

The core rule is simple: agent output is not done until it is reviewable.

Build the Habit

The best AI agent pull request workflow is a repeatable habit:

• Start from a branch or worktree.
• Prompt with scope and verification.
• Monitor the run while it happens.
• Review the diff before opening the PR.
• Write the PR for the human reviewer, not for the agent transcript.

Start with the Junction setup guide to pair one local daemon. If you need unlimited daemons, more open chats, or Switchboard automation for Linear issue-to-PR workflows, compare the current plans on pricing.