/gerrit-review

name: gerrit-review
description: Use when reviewing a Gerrit change — fetching change details, reading diffs, posting inline comments, and voting with labels. Triggers on "review this Gerrit change", "review change 12345", "look at this Gerrit CL", "code review on Gerrit".

Gerrit Code Review

Guide for reviewing changes on a Gerrit instance using the Gerrit MCP server tools.

Prerequisites

The Gerrit MCP server must be available (credentials configured via Integrations page). If `mcp__gerrit__*` tools are not listed, the user needs to connect their Gerrit instance first.

Workflow

1. Fetch the change

Use `mcp__gerrit__fetch_gerrit_change` with the change ID (numeric or change-Id).

Extract from the response:

• **Subject and commit message** — understand what the change does
• **Owner** — who authored it
• **Status** — NEW (open), MERGED, ABANDONED
• **Current patch set number** — the latest revision
• **Files changed** — list of modified files with insertions/deletions
• **Existing comments** — what reviewers have already said
• **Labels** — current votes (Code-Review, Verified, etc.)

2. Read the diffs

Use `mcp__gerrit__fetch_patchset_diff` to compare patch sets or view the current diff.

• To see the full change: compare patch set 1 vs current (or base vs current)
• To see what changed between review rounds: compare two specific patch sets
• Filter by file path if the change is large — focus on the most impactful files first

3. Analyze and form review feedback

Apply standard code review principles:

• Correctness — does the logic do what the commit message claims?
• Edge cases — missing null checks, boundary conditions, error handling
• Style — follows project conventions (check CLAUDE.md if available)
• Security — no credentials in code, proper input validation, no injection vectors
• Performance — unnecessary allocations, N+1 queries, missing caching

4. Post the review

Use `mcp__gerrit__submit_gerrit_review` to post feedback:

• **message**: A summary of your review findings (top-level comment)
• **labels**: Vote appropriately:
• `Code-Review +1` — looks good but someone else should also review
• `Code-Review +2` — approved, ready to submit (only if you have authority)
• `Code-Review -1` — needs changes before merging
• `Code-Review -2` — blocks submission (serious issues)
• `Verified +1` — tests pass, builds clean
• **comments**: Inline comments on specific files and lines

Gerrit conventions

• **Attention set**: After reviewing, the change owner gets added to the attention set automatically. Don't manually manage attention set unless needed.
• **Patchset iteration**: When the owner uploads a new patch set addressing your comments, re-review by comparing the previous and new patch sets (`fetch_patchset_diff`), not re-reading the entire change.
• **Resolved comments**: In Gerrit, comments can be marked as "resolved" or "unresolved". Focus on unresolved comments when re-reviewing.
• **Vote semantics**: Code-Review -2 is a hard block — use it only for architectural issues or security problems, not style nits.

Error handling

• If the change ID is not found, verify the instance name and change number
• If authentication fails, suggest the user reconnect via the Integrations page
• If the MCP server is not available, check that Gerrit credentials are configured