Raven
All docs

Working in a workspace

Pull requests

Opening a PR from a worktree workspace, what each state of the control means, watching checks, and merging without leaving Raven.

When a worktree workspace’s work is ready, the control in its header takes it the rest of the way: open a pull request from the workspace’s branch into your project’s home branch, watch checks, and merge.

This is a worktree-workspace feature; a local workspace doesn’t show the control. It’s working on a branch you already have checked out, so there’s nothing for Raven to open a PR from — ask the agent to open one instead.

Connecting GitHub

The control needs two things: a GitHub connection (Settings › Integrations) and a github.com origin remote on the project. Missing either, it says so plainly — a Connect GitHub button or Not on GitHub — rather than failing when you press it.

Opening a PR additionally needs the GitHub CLI (gh) installed and authenticated, for the reason in Opening a PR below.

What the control shows

It reflects real state from GitHub — checked whenever the branch moves until a PR exists, then polled every twelve seconds until it’s merged or closed:

Label Meaning
No commits yet The branch has nothing your home branch doesn’t. Nothing to open.
Open PR There’s work to open a pull request for.
Opening… The agent’s Open PR turn is running.
Checks running The PR is open and CI is still going — or GitHub hasn’t decided whether it can merge.
Checks failed A check is red.
Resolve conflicts The branch conflicts with the base and needs a merge or rebase.
Waiting on review Checks are fine, but a required review is missing.
Draft #N The PR is a draft. Mark it ready on GitHub.
Merge #N Checks pass and GitHub will take the merge.
Merging… The merge is in flight.
Merged #N / Closed The PR has landed, or been closed without landing.

Raven is deliberately conservative about Merge. A red check reads as failed even in cases where GitHub would still allow a merge, so the button is never offered on a PR you’d regret merging. Whenever a PR exists, a ↗ beside the label opens it on GitHub, and a failed action shows a ⚠ whose hover has the error. The control follows the branch the worktree has checked out: switch branches — from the terminal or the composer’s branch readout — and it shows that branch’s pull request instead. On a detached HEAD there’s no branch to open a PR from, and the control steps aside until you check one out.

The sidebar carries the same state as a small glyph on each workspace — ready, merging, conflicts, review, draft — so a set of open PRs is readable at a glance. When the header gets narrow, the control and the Run button shrink to glyphs.

Opening a PR

Pressing Open PR doesn’t call the GitHub API — it asks the workspace’s agent to do it, as a normal turn in the conversation. The agent pushes the branch, reads its own diff against the base, and opens the PR with gh pr create, writing the title and description from what actually changed. Raven pins the base to your home branch, so the PR can’t land against the wrong one.

That’s a deliberate choice: the agent has just done the work, so it’s the thing best placed to describe it. It also means the turn shows up in the transcript like any other, and you can follow up in the same breath — “add a testing section to that description”.

The instructions it gets are yours to edit, in Settings › General › Pull requests › Open PR prompt. It’s plain prose with no placeholders, so you can rewrite it to match your team’s PR conventions.

Merging

Merging is the other half, and this one Raven does itself through the GitHub API: from Merge, it squashes the branch and lands it on your home branch. If it fails, it fails loudly — Raven won’t report a merge it didn’t do.

Afterwards, the workspace is finished work. Its sidebar row gets a merged glyph — Changes landed on the home branch — safe to archive — which is read from git, so a PR merged outside Raven earns it too, and archiving it reclaims its checkout; the branch, the transcript, and the diff stats stay.

Fixing a red PR

Checks failing is the normal case, and the workspace is already the right place to fix it: the branch is checked out, the agent has the context, and the terminal is one keystroke away. Paste the failure in, let it fix, push, and the control picks up the new state on its own.