Review & manage PRs

Birch tracks your pull requests across GitHub, GitLab, and Azure DevOps — on the repository page, the workspace PR card, and the Inbox — and can check any PR out into a fresh worktree to test it locally. Birch also syncs the full PR conversation, but the window that shows it currently has no entry point in the shipped build; the live paths for working a PR today are the birch pr CLI and AI code review. The window itself — a comment feed with AI fix suggestions, a CI checks panel, a batch review composer, and the complete lifecycle (merge with your chosen strategy, flip draft state, close, reopen) — is documented below because a new entry point is planned.

Where PRs surface

• Repository page — the right rail lists OPEN PULL REQUESTS for the repository: number, title, branch flow, a CI-checks chip, and a state badge. See Repository page.
• Workspace properties — the PULL REQUEST card shows the PR matched to the workspace’s branch, with its state, checks chip, and an open-in-browser button. It stays fresh on workspace entry and after pushes — see Create a pull request.
• Inbox — the PR tab collects review requests and activity on your own PRs (approvals, change requests, comments), synced in the background. See Inbox.

The PR window

Warning

There is currently no way to reach this feature in the shipped build — the menu that hosted it is hidden. It is documented here because the feature exists in the app and a new entry point is planned. The lifecycle and checkout actions below are available today via the birch pr CLI.

The PR window (“Comments: PR #N — title”) is a non-modal window you can keep open beside your work. It has the comment feed on the left and a side panel with three cards: Checks, Pull request (lifecycle), and Review.

The comment feed

Each comment card shows the author, a relative timestamp, a kind badge (issue comment, review comment, review summary), a resolved badge where the provider reports thread resolution, a monospace file:line anchor for inline comments, and the comment body rendered as markdown. A Sync button at the top pulls the latest comments from the provider on demand; the background comment sync also runs about every 10 minutes.

Fix: an AI fix suggestion per comment

Every actionable comment carries a Fix button. It sends the comment plus the surrounding code context to the AI and produces a markdown fix suggestion, opened in its own window and stored under the app’s artifacts folder. While a fix is generating, the button becomes Cancel.

This is an Anthropic API feature — it requires the ANTHROPIC_API_KEY environment variable and consumes API tokens.

The checks panel

The Checks card lists the PR’s CI checks: a state badge, the check’s name, and an ↗ button that opens the check’s details page in your browser. It loads when the window opens and reloads after every lifecycle action; “No checks reported.” means exactly that.

Lifecycle actions

Action	Behavior
Merge	Pick a strategy — Merge, Squash, or Rebase — then confirm. The confirmation names the strategy and warns “This cannot be undone.”
Delete source branch on merge	Checkbox, on by default; included in the merge confirmation.
Convert to draft / Mark ready for review	One button that flips with the PR’s state. Applies immediately.
Close	Confirmed — “Close pull request #N without merging? You can reopen it later.”
Reopen	Shown only for closed PRs. Merged PRs can never be reopened.

A merged PR shows “This PR is merged and can no longer be modified.” and hides every action.

The batch review composer

The Review card lets you build one review locally and submit it in a single shot:

1. Add draft inline comments — a file path, a line number (≥ 1), and a body. Drafts accumulate in a list; remove any with ✕. Nothing reaches the provider yet.
2. Pick a verdict: Comment, Approve, or Request changes.
3. Optionally write a review summary.
4. Submit review sends the verdict, summary, and all draft comments as one review. The local drafts clear on success.

Check a PR out into a worktree

To test a PR locally, Birch checks it out into a fresh worktree — your own checkout stays untouched (see the worktree-first model):

terminal

birch pr checkout <url-or-id>

<url-or-id> is a PR number, id, or its full URL. Birch fetches the PR head straight from the provider (GitHub refs/pull/N/head, GitLab refs/merge-requests/N/head, Azure DevOps the source branch), creates a local branch named pr/<number>, and places the worktree in a <repo>-pr-<number> folder next to the repository. Running the same command again reuses the existing checkout.

The worktree’s base branch is set to the PR’s target branch, so opening the workspace’s Review tab shows exactly the PR’s own diff. Git-ignored local files (.env and friends) are carried into the new worktree per your .worktreeinclude rules.

The command works whether or not the app is running — with Birch open it relays through the app, so the new worktree appears in the sidebar immediately.

Managing PRs from the CLI

The whole lifecycle is scriptable — see the CLI reference for details:

terminal

birch pr list --repo <name> --all        # include merged/closed
birch pr merge <url-or-id> --strategy squash --delete-source

--strategy accepts merge (default), squash, or rebase.

For AI review of a PR — automatic on new PRs, or on demand — see AI code review.