Skip to content

Review your first pull request

By the end of this tutorial, you will have:

  • Opened a pull request in Control Center’s PR workbench
  • Read its diff and left an inline comment
  • Submitted a review verdict
  • Merged the PR

Prerequisites: Dispatch your first agent completed and one open pull request on a repo registered in this workspace. Any open PR works — one you pushed from an agent’s branch, or one that was already there.

  1. Click Pull requests in the sidebar
  2. Find your PR and click it

Checkpoint. The PR opens as a tabbed workbench — Overview, Diff, Source control, Chat, Actions, Review — focused on Overview: the title and actions, the description and activity timeline and a sidebar with status, reviewers, assignees, checks and changed files. Clicking a file there jumps to it in the Diff tab.

Open the Diff tab. A collapsible file tree sits on the left and the strip above the diff carries a commit-range selector — narrow the diff to one commit or a span of them — plus the file count and the running additions and deletions.

The settings button in the diff toolbar controls how it renders:

  • Split or unified view
  • Wrap or scroll long lines
  • Code-font ligatures

Mark a file as viewed to track your progress through a large diff. Keyboard navigation is in Keyboard shortcuts.

  1. Hover a line in the diff — a small + pill appears in the gutter
  2. Click it to comment on that line, or drag it vertically first to select a range
  3. Type your feedback and submit
  1. Click Review in the PR header — the same button also sits in the Diff tab’s toolbar
  2. Write a summary in the composer. It autosaves as a draft, so you can close the overlay and come back.
  3. Choose a verdict:
    • Approve (⌘↵)
    • Request changes (⌘⇧↵)

There is no “Comment” verdict in the overlay: those two are the only submissions it makes.

Checkpoint. The header button changes to read “Approved” or “Requested changes”.

The Merge button is present whenever GitHub reports the PR mergeable — it is not gated on your own approval. Its colour reports readiness rather than permission: primary when required approvals and checks are green, secondary while a check is still running, destructive when a requested reviewer has not approved or a check is failing.

  1. Click Merge
  2. Pick a method: Squash and merge, Create a merge commit, or Rebase and merge
  3. For the first two, edit the prefilled commit title and message
  4. Confirm

Any outstanding problems — “Checks failing”, “Some reviews are pending” — are listed in the flyout before you confirm.

After merging, a PrMerged domain event fires; analytics and notifications consume it. See Domain events for what else listens.

Control Center can put a reviewer pipeline on an open PR, but only when you ask: the pr_review template has a manual trigger and nothing else.

  1. Open the overflow menu in the PR header and choose Ask AI. Control Center starts the run and navigates to the pipeline run page, so you can watch the specialists work.
  2. Reviewer agents record their findings as review nodes in the PR’s space; a final step consolidates them into one report.

The pipeline deliberately does not post to GitHub — it ends after consolidating. Publishing is a separate step you take yourself, with the Publish to GitHub button on the PR’s Review tab. See Use AI-powered review.

You opened a PR in the workbench, read the diff with syntax highlighting, left an inline comment that went straight to GitHub, submitted a verdict and merged — without leaving the app.

Next: Build your first pipeline to automate multi-step workflows.