mr-review-request
Skill2 starsChanged 41 days agoMITView on GitHub
Request code review from developers on existing GitLab merge request. Run only when the user explicitly asks for it.
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 8 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 52
Resolve developers: Look up GitLab user IDs from shortcuts in .claude/gitlab-config.json
- Distinctive: line 53
Fetch MR: Verify MR exists and get current reviewers
- Very specific: line 133
Use /mr-review-request when you want code review
- Very specific: line 134
Use /mr-assign when you want someone to take ownership/merge
- Distinctive: line 227
Check spelling of shortcut
- Very specific: line 228
Verify developer exists in .claude/gitlab-config.json
- Distinctive: line 229
Use exact GitLab username if shortcut not defined
- Distinctive: line 232
Verify MR number is correct
- Distinctive: line 233
Check you have access to the project
- Very specific: line 234
Ensure MR is in <PROJECT_PATH> project
- Very specific: line 239
Check token in ~/.config/glab-cli/config.yml
- Distinctive: line 243
Ask project maintainer to add them
- Distinctive: line 244
Verify username is correct
- Distinctive: line 247
Check that user IDs are valid
- Very specific: line 248
Verify the -f "reviewer_ids=[<id>,…]" format (not -F, not reviewer_ids[])
- Very specific: line 271
Create MR with /mr-create
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/mr-review-request
Project resolution (project-agnostic)
This command works in any GitLab repo — nothing here is tied to a specific project. Resolve the target at runtime:
- Instance, project path, and IDs — auto-detected by
glabfrom the current repo's git remotes; never hardcode them.glabreadsorigin/upstreamdirectly. When a numeric id is needed:glab api projects/$(git remote get-url origin | sed -E 's#^[a-z]+://[^/]+/##; s#^.*@[^:]+:##; s#\.git$##' | sed 's#/#%2F#g') | jq -r '.id' - Fork vs single-repo — if both
originandupstreamremotes exist, treatoriginas your fork (push target) andupstreamas the MR/issue target; otherwise operate onorigin. - Optional extras — if
.claude/gitlab-config.jsonexists in the current repo, loaddevelopers(assignee/reviewer shortcuts) andlabels(auto-label rules) from it. If it is absent, those features degrade gracefully: ask the user for the assignee/reviewer/labels instead of resolving a shortcut.
All URLs, namespaces, and IDs in the examples below (
<GITLAB_URL>,<PROJECT_PATH>,projects/<FORK_ID>, etc.) are illustrative placeholders — resolve real values per the steps above.
Requests code review from one or more developers on an existing GitLab merge request.
⚠️ Permission Required: This command will ask for user confirmation before requesting reviews.
Usage
/mr-review-request <mr-number> <developer> [developer2] [developer3]...Arguments:
<mr-number>- MR number (e.g.,1598or!1598)<developer>- Developer shortcut or GitLab username (can specify multiple)
Developer Shortcuts: resolved from the optional .claude/gitlab-config.json → developers map in the current repo. If no config file exists, pass a real GitLab username directly. Resolve a username to an id with glab api "users?username=<name>" | jq '.[0].id'.
Examples:
/mr-review-request 1598 alice # Request review from alice
/mr-review-request !1598 bob # Request review from bob
/mr-review-request 1598 alice bob # Request review from both
/mr-review-request 1598 alice bob carol # Request from all threeWhat it does
- Resolves developer shortcuts to GitLab user IDs
- Fetches MR details to verify it exists
- Asks user for permission to request reviews
- Adds reviewers to MR via GitLab API
- Confirms review requests sent
Process
- Parse arguments: Extract MR number and developer shortcuts
- Resolve developers: Look up GitLab user IDs from shortcuts in
.claude/gitlab-config.json - Fetch MR: Verify MR exists and get current reviewers
- ⚠️ ASK USER PERMISSION: Display review request preview and await confirmation
- Add reviewers (if approved): PUT to
projects/:id/merge_requests/{iid}with the existing reviewer ids from step 3 plus the new ones — the PUT replaces the list, so sending only the new ids silently removes current reviewers - Confirm: Display updated reviewers list
Example Output
Example 1: Request single reviewer
🔍 Fetching MR !1598...
📋 MR #1598: feat(shipments): add pickup details to API responses
Status: Open
Author: dana.lee
Current reviewers: None
👤 Resolving developer shortcut: alice → alice (User ID: 7)
⚠️ Request review from alice on MR !1598? (yes/no)
> yes
✓ Requesting review...
✓ Review requested from alice
🔗 MR URL: <GITLAB_URL>/<PROJECT_PATH>/-/merge_requests/1598
👥 Reviewers: aliceExample 2: Request multiple reviewers
🔍 Fetching MR !1598...
📋 MR #1598: feat(shipments): add pickup details to API responses
Status: Open
Author: dana.lee
Current reviewers: alice
👥 Resolving developer shortcuts:
- alice → alice (User ID: 7) [already reviewing]
- bob → bob (User ID: 8)
- carol → carol (User ID: 9)
⚠️ Request review from bob, carol on MR !1598?
(alice is already a reviewer)
(yes/no)
> yes
✓ Requesting reviews...
✓ Reviews requested from: bob, carol
🔗 MR URL: <GITLAB_URL>/<PROJECT_PATH>/-/merge_requests/1598
👥 Reviewers: alice, bob, carolExample 3: User cancels
🔍 Fetching MR !1598...
📋 MR #1598: feat(shipments): add pickup details to API responses
👥 Resolving: alice, bob
⚠️ Request review from alice, bob on MR !1598? (yes/no)
> no
✗ Review request cancelledReviewer vs Assignee
Reviewer (this command):
- ✅ Should review and approve the code
- ✅ Gives feedback and suggestions
- ✅ Can be multiple people
- ✅ Not responsible for merging (author merges)
Assignee (/mr-assign):
- ✅ Responsible for taking action
- ✅ Usually person who will merge
- ✅ Or person who needs to fix issues
- ✅ Single person (or small team)
When to use:
- Use
/mr-review-requestwhen you want code review - Use
/mr-assignwhen you want someone to take ownership/merge
GitLab API
Endpoint: PUT /api/v4/projects/{id}/merge_requests/{iid}
Parameters:
{
"reviewer_ids": [7, 8, 9]
}Example API call:
# Get user IDs
glab api "users?username=alice" | jq -r '.[0].id' # Returns: 7
glab api "users?username=bob" | jq -r '.[0].id' # Returns: 8
# Request reviews (single reviewer)
glab api --method PUT projects/:id/merge_requests/1598 \
-f reviewer_ids=7
# Request reviews (multiple reviewers)
glab api --method PUT projects/:id/merge_requests/1598 \
-f "reviewer_ids=[7,8,9]"⚠️ Important:
- ✅ Use
-fflag (lowercase) for field data - ✅ Single reviewer:
reviewer_ids=7(no brackets) - ✅ Multiple reviewers:
reviewer_ids=[7,8,9](JSON array format) - ✅ Replaces existing reviewers (doesn't append) — always include the current ids
- ✅ Outside the repo you are in, prefix with
GITLAB_REPO=<namespace/repo>—:idotherwise resolves to the current directory's project - ❌ Don't use
-F(uppercase) - causes encoding issues - ❌ Don't use
reviewer_ids[]=7syntax - doesn't work with glab api - ❌ Don't use
reviewer_id(singular) - it won't work
Developer Management
Available Developers
Developers are defined in .claude/gitlab-config.json:
{
"developers": {
"alice": {
"username": "alice",
"gitlab_user_id": 7
},
"bob": {
"username": "bob",
"gitlab_user_id": 8
},
"carol": {
"username": "carol",
"gitlab_user_id": 9
}
}
}Finding GitLab User IDs
# Search for a user
glab api "users?search=name" | jq -r '.[] | {id, username, name}'
# Get specific user ID
glab api "users?username=alice" | jq -r '.[0].id'Permissions
Requires user permission because:
- Sends notifications to reviewers
- Changes MR state
- Affects team workflow
Why ask first:
- Requesting reviews requires approval
- Adding reviewers triggers notifications
Notifications
What happens when you request review:
- ✅ Reviewer receives email notification
- ✅ Reviewer sees MR in their "Review requests" list
- ✅ MR shows "Review requested" status
- ✅ Reviewer can approve, comment, or request changes
Troubleshooting
"Developer not found"
- Check spelling of shortcut
- Verify developer exists in
.claude/gitlab-config.json - Use exact GitLab username if shortcut not defined
"MR not found"
- Verify MR number is correct
- Check you have access to the project
- Ensure MR is in
<PROJECT_PATH>project
"Permission denied"
- Your GitLab token needs
apiscope - You must have Developer role or higher
- Check token in
~/.config/glab-cli/config.yml
"User does not have access to project"
- Reviewer must be a member of
<PROJECT_PATH>project - Ask project maintainer to add them
- Verify username is correct
"No reviewers added"
- Check that user IDs are valid
- Verify the
-f "reviewer_ids=[<id>,…]"format (not-F, notreviewer_ids[]) - Try using user ID directly instead of username
Related Commands
/mr-create --reviewer <dev>- Create MR with reviewer/mr-assign <mr> <dev>- Assign MR to developer
Best Practices
Request reviews from:
- ✅ Code owners for the affected files
- ✅ Team lead or senior developers
- ✅ Subject matter experts
- ✅ At least 2 people for important changes
Don't request reviews from:
- ❌ People unfamiliar with the code
- ❌ Too many people (max 2-3)
- ❌ The MR author (yourself)
Workflow:
- Push your changes
- Create MR with
/mr-create - Request reviews with
/mr-review-request 1598 alice bob - Address feedback
- Get approvals
- Merge
Created: 2025-12-27
Last updated: 2025-12-27
Config file: .claude/gitlab-config.json
Other versions1 project uses a version of this.
Word for word · 1
- AhmedMerza/claude-skills★ 2100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository53 other files it gives its agents.
- animateSkill
- api-docs-completeSkill
- best-optionSkill
- browseSkill
- changelog-generateSkill
- checkpointSkill
- claimSkill
- commitSkill
- courtSkill
- design-driftSkill
- designSkill
- expandSkill
- explainSkill
- fix-reviewSkill
- grill-meSkill
- handover-listSkill
- handover-resumeSkill
- handover-saveSkill
- i18n-syncSkill
- issueSkill
- leadSkill
- mr-approveSkill
- mr-assignSkill
- mr-createSkill
- mr-guideSkill
- mr-listSkill
- mr-mergeSkill
- mr-reviewSkill
- mr-statusSkill
- persona-walkthroughSkill
- ponytailSkill
- prove-the-testSkill
- qa-crawlSkill
- qa-sweepSkill
- reflectSkill
- reviewSkill
- root-causeSkill
- scoutSkill
- second-opinionSkill
- ship-checkSkill
- skill-auditSkill
- skill-compareSkill
- spinoffSkill
- story-siteSkill
- tool-compareSkill
- ui-auditSkill
- ui-polishSkill
- usage-weekSkill
- ux-auditSkill
- validate-planSkill
- video-teardownSkill
- wait-whatSkill
- where-were-weSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

