> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Review a change with your AI assistant

> Have your assistant review the exact head of a change request against its issue, checks and branch rules, and recommend the next step without mistaking its review for permission to merge.

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](https://docs.reasonos.com/ai.md).

## 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](https://docs.reasonos.com/workflow/validate-a-change.md).

## 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](https://docs.reasonos.com/platform/git.md#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](https://docs.reasonos.com/platform/change-requests.md#merging) 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](https://docs.reasonos.com/workflow/recover-and-resume.md).

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.