GitLab Reviewer

Reviews GitLab merge requests thoroughly by analyzing diffs, researching alternatives, and suggesting improvements.

Workflow

Step 1: Determine Project & MRs

Project path: - If the user mentions a project, use it. - Otherwise, check if the current workspace is a Git repository. If it is, derive the GitLab project path from git remote -v (e.g., owner/repo-name). Use this as the default project. - If the workspace is not a Git repository, ask the user which GitLab project to review.

MR selection:

User specifies MRs — use those IIDs directly.
User describes a topic — use gitlab_search (scope: merge_requests) to find matching MRs.
General review sweep — list open MRs with gitlab_list_merge_requests(state="opened"). Present the list to the user and confirm which to review. Default: review all open MRs.

Step 2: Gather MR Details

For each MR: 1. Call gitlab_get_merge_request to get MR details, activity, and discussion. 2. Read the MR description, title, and discussion comments. 3. Read the surrounding code context for changed files using gitlab_get_file_contents.

Step 3: Launch Parallel Review Subagents

For each MR, spawn a read-only subagent. Launch all subagents in the same turn for parallel execution.

Subagent prompt format:

Review this GitLab merge request thoroughly.

MR Details:
- Project: {project_path}
- MR IID: {mr_iid}
- Title: {title}
- Description: {description}

Changes (diff):
{diff_content}

Surrounding code context for changed files:
{file_contexts}

Perform the following review:

1. CORRECTNESS: Identify bugs, logic errors, race conditions, edge cases, and
   missing error handling.

2. SECURITY: Check for injection vulnerabilities, credential exposure, insecure
   defaults, missing input validation, and authentication/authorization issues.

3. PERFORMANCE: Identify N+1 queries, missing indexes, unnecessary allocations,
   blocking calls, memory leaks, and scalability concerns.

4. CODE QUALITY: Check for consistency with project conventions, naming,
   readability, duplication, and test coverage.

5. ONLINE RESEARCH:
   - Use Context7 to fetch current best practices and documentation for the
     relevant frameworks and libraries. If Context7 is unavailable or returns
     no results, fall back to web search for the same documentation.
   - Search the web for alternative solutions, recent articles, and
     established patterns for the problems this MR addresses.
   - Search GitHub for how other projects solve the same problem.
   - Check if there are industry-standard libraries or patterns that could
     replace or improve the implementation.

6. ARCHITECTURE: Assess whether the design fits the overall architecture,
   identify coupling issues, missing abstractions, and long-term
   maintainability concerns.

7. IMPROVEMENTS: Suggest concrete improvements beyond what the MR addresses,
   including refactoring opportunities, missing features, and potential
   future-proofing.

Return a structured review report:
- Summary (1-2 sentences)
- Issues Found (categorized by severity: Critical, Major, Minor, Nit)
- Online Research Findings (with references)
- Best Practices Applicable to This Change
- Suggested Improvements
- Overall Verdict (Approve / Request Changes / Needs Discussion)
- Sources (list every URL, documentation page, GitHub issue, or paper you referenced — include direct links)

IMPORTANT: The report will be posted as a comment on the GitLab merge request. Always include a "Sources" section at the end with every link you used during research. Do not omit sources.

Step 4: Collect and Present Results

As subagents complete, collect their review reports. Present a summary:

## Code Review Summary

| MR | Title | Verdict | Issues |
|----|-------|---------|--------|
| #42 | Fix login | Request Changes | 2 Critical, 1 Major |
| #38 | Add caching | Approve | 0 issues |

Detailed reviews below.

Then show each review report in full.

Step 5: Post Comments (Optional)

If the user approves, post the review as an MR comment using gitlab_add_merge_request_note: - project_path: the project path - mr_iid: the MR number - body: the review report (already in markdown format)

Step 6: Show Next Steps

**Next steps:** If changes were requested, use the `gitlab-solver` skill to
implement the fixes. If the MR is approved, it's ready to merge.

Important

Always research alternatives — don't just review the code as-is.
Online research is mandatory — every subagent must use Context7 (with web search fallback) and web search to ground recommendations in current best practices.
Reference specific lines or functions when pointing out issues.
Be constructive — explain why something is an issue and how to fix it.
If the MR follows good practices, say so explicitly.
Keep subagents read-only — only the main agent posts comments.

When NOT to Use

When the user just wants to quickly glance at a diff without a full review.
When the user explicitly says "just merge it" or "skip review".
When there are no open MRs to review.

gitlab-reviewer