Read the pull request your Brief delivered, discuss it with your team, and approve or request changes without leaving Hamster.
Once Delivery opens a pull request, a Review tab appears on the Brief beside Plan. It shows the pull request the Brief produced — the description, the CI checks, the file diffs, and the conversation around them — so the code and the intent behind it sit on the same page.
This page describes Review on a GitHub pull request. It reads a GitLab merge request too, with the provider differences noted on that page. Before Delivery opens one, the tab is greyed out with the tooltip "No pull request yet", and there is no way into Review until then.
The header carries the pull request title, a state pill — Draft, Open, Merged, or Closed — the person who opened it, and a link to the same pull request on GitHub.
Review has three panes, selected from a row under the header.
Activity opens first. It leads with the pull request description, then the review history — Approved, Commented, Changes requested, Dismissed, or Pending — and every comment thread on the pull request. The composer at the foot is where you leave a general comment: "Leave a comment for the team…" A comment anchored to a file line links back to that line in the diff, and the thread on it takes a Reply — GitHub does not nest replies, so the reply lands on the thread instead of on an individual response inside it.
Checks lists the CI checks reported for the current commit, one row per check name, each with a Pending, Passing, or Failing pill and a link out to the run on GitHub. A failing check expands Failure details in place with the output GitHub returned, so you can read the failure without opening another tab. If nothing has reported yet, the pane says "No checks configured for this commit."
Changes holds the code, and its tab carries the pull request's +N −N line totals so you can size the change before you open it.
Check results and pull request comments update live, so the panes track the pull request as it moves, not only at the moment you opened Review.
Inside Changes there are two ways to read the same pull request.
Diff is the file-by-file view. A file tree sits on the left, the diffs on the right, and a toggle switches between unified view and split view. Hamster remembers which one you prefer for the next pull request you read.
Tour is a walkthrough Hamster writes for the pull request your Brief delivered. It starts with an Overview, follows with Review focuses — the things worth paying attention to — and then groups the changed files into named sections and subsections with their real diffs inline. A counter in the toolbar reads "N/M Files Viewed" and fills in as you scroll through. Hamster remembers which section and file you had open, so you can leave a long pull request and come back to the place you left it — the viewed count starts again from zero.
You can ask for parts of the Tour again without regenerating everything: Redo AI overview, Redo AI review focuses, and Regenerate section on any subsection. When the pull request has moved on since the Tour was written, a banner reads "This pull request changed since this Tour was generated." with a Regenerate Tour action.
Tour is generated once Hamster has located the pull request and its base and head commits.
Review writes to GitHub as you, not as Hamster's app — so a comment or a decision needs your own GitHub sign-in to reach GitHub.
A comment is saved in Hamster the moment you post it and then sent to GitHub, so nothing you type is lost if GitHub can't be reached. A decision goes to GitHub first and is recorded in Hamster once GitHub accepts it, so a rejected decision shows an error instead of looking saved. Signed out, the decision waits in Hamster until you sign in.
If you have not signed in, a line above the composer reads "Comments and approvals stay in Hamster until you sign in." with a Sign in with GitHub button. If a previous sign-in has lapsed, it reads "GitHub sign-in expired. Reconnect to post comments and approvals as yourself." with Reconnect GitHub.
Hamster tells you which of the two happened each time you comment: "Comment posted to GitHub" when it reached GitHub, "Comment saved in Hamster. GitHub did not receive it." when it did not. A comment that failed to post shows "Couldn't post to GitHub" with a Try again beside it.
Sign in later and Hamster back-fills. Comments that were only in Hamster are posted to GitHub, each thread ahead of the replies on it, and a pending decision is submitted with them.
Approve and Request changes sit in the Review header on the Brief.
Approve opens a dialog titled "Approve pull request", where a comment is optional. Afterwards the button reads Approved, and hovering it turns it into Unapprove.
Request changes opens a dialog titled "Request changes" and asks you to describe what should change — a comment is required here. Afterwards the button reads Changes requested, and hovering it turns it into Withdraw.
When someone else has already approved, Review shows it beside the buttons — "Approved by …", or "Also approved by …" once you have approved too.