codingthefuturewithai/teamcraft-glgd:mr-review

Goal

A reviewer conducts a complete merge request review — reading the diff, understanding the implementation in context, engaging with existing discussion threads, leaving review comments, and deciding to approve or request changes — entirely within Claude Code, without opening the GitLab UI.

Hard Constraints

• The MR IID comes from $ARGUMENTS. If not provided, ask.
• Never auto-approve or auto-merge. Every consequential action — approving, merging, requesting changes — requires explicit instruction from the reviewer.
• Fetch current labels before any label update. Always merge into the existing label set — never replace.
• Use git (Bash) to understand codebase context beyond what the MR diff alone shows. The diff tells what changed; the codebase tells why it matters.
• Human is the authority on what merges. Surface findings and engage with the reviewer. Do not decide.

Identify the Project

Read .teamcraft/project.md if it exists — it contains the GitLab project ID. If not, check git remote context (git remote -v) to identify the project from the URL. If neither resolves it, use mcp__gitlab__list_projects to see what is visible, surface the results, and ask the reviewer to confirm which project. Never assume.

Load the MR

Fetch the MR from GitLab. Read it completely: title, description, source branch, target branch, pipeline status, linked issue reference, and any acceptance criteria the description contains. If the MR description references a GitLab issue, fetch that issue too — the acceptance criteria and original requirements belong in the reviewer's picture.

Fetch the diff and existing discussion threads. Read both in full before presenting anything to the reviewer.

Orient the Reviewer Locally

Check the current local branch. If the reviewer is not already on the MR's source branch, offer to check it out:

"You're currently on [branch]. Want me to check out [source-branch] so you can view the code locally in your editor?"

Wait for their answer. Check it out if they say yes. A reviewer seeing the code in their editor alongside the diff has a better picture than the diff alone.

Understand the Implementation in Context

Read the changed files in the local codebase alongside the diff. The diff shows what changed; the surrounding code shows what it changed relative to. Use git log on the source branch to understand the commit sequence and how the implementation evolved.

Look for what the automated analysis (code health and security review, if it ran) already flagged. CLAUDE.md and .claude/rules/ contain team conventions — read them to understand what this codebase expects and whether the implementation follows it.

Present the MR to the Reviewer

Synthesize the MR for the reviewer — not a raw diff dump. Cover:

What this MR delivers — a clear statement of what was built, referencing the linked issue and acceptance criteria.

What changed — the meaningful changes, grouped by area or concern. Not a line-by-line recitation. The reviewer can drill into specifics; start with the picture.

Existing discussion — any open threads or comments already in the MR that the reviewer should be aware of.

Your initial read — areas that warrant closer attention: logic that looks unusual, missing edge case handling, anything that doesn't align with team conventions, test coverage gaps, or any concerns the diff alone raises.

Then stop and let the reviewer drive.

Engage the Review

The reviewer leads from here. Support whatever they need:

• Drill into specific files, functions, or lines on request
• Respond to or resolve existing discussion threads
• Leave review comments on specific lines or the MR generally — present the comment for confirmation before posting
• Answer questions about what the code does or why it was written a particular way (inferred from the implementation and commit history)

Actions Available

When the reviewer is ready to act, offer the options that apply:

Approve — if the reviewer confirms they are approving, use mcp__gitlab__approve_merge_request. Confirm once before acting.

Request changes — leave a summary comment on the MR with the reviewer's concerns. Present the draft comment for review before posting.

Merge — if the reviewer instructs a merge, confirm pipeline status first. Present the current state and get explicit confirmation before merging.

Close without merging — if the reviewer decides the MR should not proceed, update the MR accordingly with a closing note. Confirm before acting.

No action happens without explicit reviewer instruction. No action happens without confirmation of what will be done before it is done.