---
name: review-merge-request
description: Use when reviewing, approving, rejecting, or summarizing Remix merge requests.
---

# Review Remix Merge Request

Use Remix merge request tools as the default review workflow.

Remix merge requests are app-lineage review flows, not git branch merges. In a bound repo, use Remix merge-request tools as the authoritative merge workflow rather than local `git merge`.

Recommended sequence:

1. Use the queue tool that matches the intent when the target MR is not already known:
   - `remix_collab_review_queue` for "what can I review?"
   - `remix_collab_my_merge_requests` for "what did I create?"
  - `remix_collab_list_app_merge_requests` for app-scoped requests, with required `queue`:
    - `app_reviewable` for incoming reviewable requests on this app
    - `app_outgoing` for requests opened from this app
    - `app_related_visible` for all open visible requests where this app is source or target
2. Use `remix_collab_view_merge_request` to inspect the request.
3. Request bounded diff output first. Only request a larger diff if needed to answer the review task accurately.
4. If approval is requested:
   - use `remix_collab_approve_remote` when local target repo sync is not needed
   - use `remix_collab_approve_and_sync_target` only when you are in the correct target repo context and the user wants local sync too
5. Use `remix_collab_reject` when the correct outcome is rejection.

Important rules:

- In a bound repo, use Remix review tools as the default path for MR handling.
- Choose an explicit queue instead of treating merge requests as one broad inbox.
- Do not treat raw `git merge` as the way Remix merge requests are approved or applied.
- If approval would mutate the local target repo, explain that before applying it.
- If the repo context is unclear, stay in remote-only review mode until the target repo is confirmed.
- Review-only turns with no repository diff should be captured by `remix_collab_record_turn`, not by `remix_collab_add`.
