Skip to main content
Ask your assistant to review a change and it should tell you three things: what the change does at its current head, what still stands in the way of merging, and what it recommends. Give it this page along with Use ReasonOS with your AI assistant.

​
Start with a request like this

Review change request 42 in the payments project. Check it against its issue’s acceptance criteria and its current CI, list anything that blocks merging, and tell me whether it is ready. Leave your findings as comments; do not approve or merge it.

​
Tools

On the managed ReasonOS MCP:
  • get_change_request — the request with its files, discussion and line threads, reviewers and their verdicts, its place in a stack, and counts of unresolved threads and approvals; patch adds the patch text
  • get_diff — what the head changes relative to the base, measured from their merge base
  • check_merge — whether it merges cleanly, its base and head commits, and what branch protection still requires
  • ci_status, get_ci_run, get_ci_run_log — the checks at a commit
  • issue_evidence — the evidence linked to the request’s issue
  • comment_on_change_request, review_change_request — record findings
With local RBS MCP and the change checked out, rbs_affected and rbs_test check what the diff touches, as in Validate a change.

​
The workflow

  1. Pin the head. Read the request and note its head commit. A review is about that commit only. If the head moves while you work, start again from the new head.
  2. Read the intent. Find the linked issue and its acceptance criteria. A change that is correct but does something other than what was asked is a finding.
  3. Read the change. Use get_diff against the request’s base. Follow the affected code paths, permissions and failure handling, not only the lines that changed.
  4. Check the evidence at this head. For each required check, report whether it passed, failed, is still running, or has not run at this head. A check that has not run is not a pass, and a pass at an earlier commit does not count for this one. Use check_merge for what the branch rules still need.
  5. Write findings. Make each one specific: where, what goes wrong, and what would fix it. Leave them as comments or line comments.
  6. Recommend. Say ready, ready once the named items are done, or not ready, with the reasons, and name what a person still has to decide.

​
What counts toward merging

  • Approvals are tied to a commit. If the branch is pushed again, earlier approvals predate the current head. Whether they still count depends on the project’s branch rules: with dismiss stale approvals on, only approvals of the current change count. Say which approvals predate the head either way.
  • Approvals recorded as agent reviews do not count toward a required number of approvals; a person still has to approve. Whether a review is recorded as a person’s or an agent’s comes from the connection that submitted it, not from who wrote the words: a review an assistant writes through a person’s own connection is recorded as that person’s. Check the reviewer and agent recorded on the request rather than inferring either.
  • The author can only comment. A reviewer recorded as the change request’s author — the same person through the same agent identity, or none — cannot approve it. An assistant working through the author’s own connection is that author.
  • A request for changes blocks, whatever the number of approvals, and so can unresolved threads and other branch rules. The merge box lists everything still standing in the way.

​
Approval points

Reading, diffing and checking are reviews; they change nothing. Ask the person before you:
  • submit an approved or changes requested verdict, rather than comments;
  • resolve someone else’s review thread;
  • merge. A review the assistant wrote is a recommendation, not permission to merge. If the person does ask for a merge, pass check_merge’s base_sha and head_sha as expected_base_sha and expected_head_sha to merge_change_request, so a push to either branch since the check stops the merge instead of landing unseen.

​
When things go wrong

  • The head moves during the review. Earlier findings may no longer apply and earlier checks are for the old commit. Re-read the request and diff, and say what changed.
  • You cannot see something. If a tool refuses for lack of access, report what you could not check. Do not ask for broader access or treat the gap as a pass.
  • A merge answer is uncertain. Read the change request again before doing anything else; do not retry the merge blind. See Recover and resume.

​
Limits today

  • This page describes the current tools. A hosted deployment may run an earlier build: use the tools your connection actually offers.
  • The merge button works for repositories ReasonOS hosts; a project that mirrors an external remote is merged there and then marked as merged.