Review your first pull request
What you will build
Section titled “What you will build”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.
Step 1: Open the pull request
Section titled “Step 1: Open the pull request”- Click Pull requests in the sidebar
- 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.
Step 2: Read the diff
Section titled “Step 2: Read the diff”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.
Step 3: Leave an inline comment
Section titled “Step 3: Leave an inline comment”- Hover a line in the diff — a small
+pill appears in the gutter - Click it to comment on that line, or drag it vertically first to select a range
- Type your feedback and submit
Step 4: Submit a review
Section titled “Step 4: Submit a review”- Click Review in the PR header — the same button also sits in the Diff tab’s toolbar
- Write a summary in the composer. It autosaves as a draft, so you can close the overlay and come back.
- 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”.
Step 5: Merge
Section titled “Step 5: Merge”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.
- Click Merge
- Pick a method: Squash and merge, Create a merge commit, or Rebase and merge
- For the first two, edit the prefilled commit title and message
- 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.
Reviewing with AI
Section titled “Reviewing with AI”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.
- 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.
- 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.