--- name: gitlab-merge-requests-waiting-on-review description: "Each weekday morning: open GitLab merge requests where you are a reviewer and have not reviewed yet, oldest first, with pipeline status and conflicts. Use when the user asks for this, or when it runs on a schedule." --- # GitLab merge requests waiting on your review Each weekday morning: open GitLab merge requests where you are a reviewer and have not reviewed yet, oldest first, with pipeline status and conflicts. GitLab's To-Do list mixes review requests with mentions and assignments, and the merge request list filtered by reviewer still shows the ones you already approved. The author who asked three days ago has no way to tell whether you saw it. This skill keeps only the merge requests where your review is still pending, puts the oldest on top and shows whether the pipeline is green, so you know which ones are worth opening now. It can summarize the diff of the one you pick before you start. ## Two ways to get the data Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used. ## Route A: API or MCP server ### What you need - A GitLab personal access token with `read_api` in `GITLAB_TOKEN`, and `GITLAB_URL` for self-managed instances. - Or the GitLab MCP server at `https:///api/v4/mcp`, connected with your account. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **List merge requests that name you as reviewer** (GitLab): Call `GET /api/v4/merge_requests?scope=all&state=opened&reviewer_username=&draft=false&order_by=created_at&sort=asc&per_page=100` (on GitLab before 19.0 use `wip=no` instead of `draft`). Your username comes from `GET /api/v4/user`. 2. **Drop the ones you already reviewed** (GitLab): For each one, `GET /api/v4/projects/:id/merge_requests/:merge_request_iid/reviewers` and keep it when your entry has `state` `unreviewed`. Keep `requested_changes` too when the author pushed after your review, and mark it as a re-review. 3. **Add pipeline and merge status** (GitLab): `GET /api/v4/projects/:id/merge_requests/:merge_request_iid` returns `head_pipeline.status`, `detailed_merge_status` and `has_conflicts`. Note the size from `changes_count` and how many days it has waited since `created_at` or since you were added. 4. **Rank and ask**: Oldest first, with green pipelines ahead of red ones of the same age, since a failing pipeline usually means the author is still working. Post the list and ask which merge request to summarize first. ## Route B: the browser ### What you need - Signed in to GitLab.com or your self-managed instance with your own account; the homepage only lists merge requests you can see. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://gitlab.com/dashboard/merge_requests. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Open the merge request homepage**: On GitLab.com the URL above is the merge request homepage (GitLab 17.9 or later; on self-managed, replace the host). Stay on the **Active** tab. Open **Display preferences** in the upper right and sort by **Role**, which puts the merge requests where you are a reviewer in one list. 2. **Read the Reviewer (Active) list**: Everything under **Reviewer (Active)** is waiting on you: review requested and not yet given. Merge requests you already approved sit under **Reviewer (Inactive)** and stay out. Skip rows marked **Draft**. Each row shows the project, the author, how long ago it was created and the pipeline icon. 3. **Check pipeline and conflicts**: Hover the pipeline icon or open each merge request and read the status under the title: pipeline passed, failed or running, and the "Merge blocked: merge conflicts must be resolved" notice when there are conflicts. Note the number of changed files from the **Changes** tab count. 4. **Spot re-reviews**: A merge request where you requested changes and the author pushed again shows up under **Reviewer (Active)** once more, with your earlier review in its activity. Mark those as re-reviews rather than new requests. 5. **Order and ask**: Oldest first, with passing pipelines ahead of failing ones of the same age. List them and ask which one to open and summarize first; do not approve, comment or merge. Note: The homepage is the quicker route for a handful of merge requests, since GitLab already filters out the ones you approved. It needs GitLab 17.9 or later; on older self-managed instances, use the **Merge requests** list with the **Reviewer** filter set to you and **Approved-By** set to None, which comes close. The homepage list is paginated; with more than 20 pending reviews, scroll until it ends. ## The report - **Waiting on you**: count, and how long the oldest has waited. - One row per merge request: reference, title, project, author, days waiting, pipeline status, conflicts. - **Re-reviews**: merge requests where you asked for changes and the author has pushed since. - The question: which one to summarize first. ## Post it to Briefkin When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on. ```bash [ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \ -H "authorization: Bearer $BRIEFKIN_TOKEN" \ -H "content-type: application/json" \ -d @- <<'JSON' { "v": 1, "event_id": "gitlab-merge-requests-waiting-on-review/", "item_key": "gitlab-merge-requests-waiting-on-review", "project": "acme", "source": "GitLab merge requests waiting on your review skill", "kind": "action", "title": "5 merge requests waiting on your review", "summary": "**5** merge requests are waiting on you. The oldest, **!412** in acme/api, has waited **4 days** and its pipeline passed.", "action": { "request": "Want a summary of the diff before you open one?", "options": [ "Summarize !412", "Summarize all 5", "Only green pipelines", "Not today" ] }, "widget": { "type": "Table", "props": { "columns": [ "Merge request", "Author", "Waiting", "Pipeline" ], "align": [ "left", "left", "right", "left" ], "rows": [ [ "!412 Retry webhook deliveries with backoff (acme/api)", "Priya", "4 days", "passed" ], [ "!398 Move billing settings to a tab (acme/web)", "Tom", "3 days", "failed" ], [ "!421 Add index on events.created_at (acme/api)", "Lena", "2 days", "passed" ], [ "!117 Bump the Node image to 22 (acme/infra)", "Sam", "1 day", "running" ], [ "!403 Re-review: CSV export streaming (acme/api)", "Priya", "pushed today", "passed" ] ] } } } JSON ``` Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report. ## Run it on a schedule Suggested: Weekdays at 9:00 (`0 9 * * 1-5`). From cron, with the agent signed in on that machine: ```bash 0 9 * * 1-5 claude -p "Run the gitlab-merge-requests-waiting-on-review skill" # Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run ``` Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/gitlab-merge-requests-waiting-on-review#schedule Source: https://briefkin.dev/skills/gitlab-merge-requests-waiting-on-review