mr-review

name	mr-review
description	Quick local code review of a GitLab MR — checkout, analyze diff, and fix issues directly in the source code. No GitLab API or tokens needed.

Quick MR Code Review

Lightweight local review of a GitLab MR. Checks out the branch, analyzes the diff, fixes issues directly in source. Uses glab CLI only — no API tokens needed.

For comprehensive workflows (resolving reviewer comments, posting findings to GitLab, git commit/rebase help), use the gitlab-review-kiran agent instead.

Workflow

Step 0: Validate repo context (bail out if wrong repo)

This step is mandatory when a full GitLab URL is given. A bare MR ID (e.g. !42) skips this check.

Parse the project namespace from the URL argument:

Given https://gitlab.com/NAMESPACE/PROJECT/-/merge_requests/ID, extract NAMESPACE/PROJECT.

Get the current repo's remote origin and normalize it:

git remote get-url origin
# SSH:   [e-mail]:company/camera/camera-build.git  → company/camera/camera-build
# HTTPS: https://gitlab.com/company/camera/camera-build.git → company/camera/camera-build

Strip the .git suffix and the host prefix to get the bare NAMESPACE/PROJECT path.

Compare the two project paths:

• If they match → proceed to Step 1.
• If they do not match → STOP IMMEDIATELY and output:

❌ Repo mismatch detected.

  MR URL project : company/camera/camera-soc-yocto
  Current repo   : company/camera/camera-build

Please cd into the correct repository before running this command.
  cd /path/to/camera-soc-yocto

Do not continue past this point if there is a mismatch.

---

Step 1: Identify the MR

Parse the MR ID or URL from $ARGUMENTS. If not provided, detect the open MR for the current branch.

glab mr view <MR_ID>

Step 2: Checkout the MR branch

glab mr checkout <MR_ID>

Step 3: Analyze the diff

glab mr diff <MR_ID>

Read the full diff and surrounding source files for context — don't review the diff in isolation.

Step 4: Review for issues

Prioritize by impact:

Priority	Category	Examples
🔴 Critical	Security	Injection, exposed secrets, unsafe operations
🔴 Critical	Bugs	Logic errors, null handling, off-by-one, race conditions
🟠 High	Error handling	Missing checks, silent failures, unhandled edge cases
🟡 Medium	Performance	Inefficient loops, unnecessary allocations, blocking calls
🟡 Medium	Code quality	Duplication, excessive complexity, poor naming
🟢 Low	Style	Typos, formatting, minor readability improvements

Step 5: Fix issues in the source code

For each fix:

1. Read surrounding context and related call sites before editing
2. Make the minimal change that addresses the issue
3. Verify with diagnostics on changed files

Step 6: Report summary

## MR Review Summary

**MR**: !<MR_ID> — <title>
**Branch**: <source> → <target>

### Fixed (<count>)
- `<file>:<line>` — <what was fixed and why>

### Noted but not fixed (<count>)
- <description> — <reason skipped (subjective, out of scope, needs discussion)>

### Clean areas
- <areas reviewed that looked good>

Rules

• ASK to jpush changes or post comments to GitLab
• ASK to amend existing commits — fixes stay as unstaged changes for the user to review
• Fix bugs and clear issues; skip subjective style preferences
• When unsure if something is a bug, read the surrounding code and tests before deciding
• Group related fixes when they address the same concern

Permissions

Bash commands allowed except:

• git push (any form) - DENIED
• glab mr note/comment/approve/merge/close/reopen/update - DENIED