--- name: azure-devops-prs-waiting-on-review description: "Each weekday morning: active Azure DevOps pull requests where you are a reviewer and have not voted yet, oldest first, with build and merge status. Use when the user asks for this, or when it runs on a schedule." --- # Azure DevOps pull requests waiting on your review Each weekday morning: active Azure DevOps pull requests where you are a reviewer and have not voted yet, oldest first, with build and merge status. In Azure Repos the "Assigned to me" tab shows every pull request you are on, including the ones you approved last week and the ones where a team you belong to was added as a whole. Finding the handful that actually wait on your vote takes clicking through each project. The agent asks the REST API for active pull requests in each project with you as a reviewer, keeps the ones where your vote is still 0, and adds whether the build policy passed and whether the branch merges cleanly. Oldest first, so the colleague who asked on Tuesday gets an answer before the one who asked an hour ago. ## 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 personal access token with Code (Read) and User Profile (Read) scopes (`vso.code`, `vso.profile`) in `AZURE_DEVOPS_PAT`, and the organization name. - Or the Azure DevOps MCP server (remote at `https://mcp.dev.azure.com/{organization}` with the `X-MCP-Readonly: true` header, for organizations backed by Microsoft Entra; otherwise the local server with a PAT). If something is missing, say what and stop; do not invent numbers. ### Steps 1. **Find your identity** (Azure DevOps): Call `GET https://app.vssps.visualstudio.com/_apis/profile/profiles/me?api-version=7.1` and keep its `id`. List the projects with `GET https://dev.azure.com/{organization}/_apis/projects?api-version=7.1`, or use the list in the prompt. 2. **List pull requests that name you** (Azure DevOps): Per project: `GET https://dev.azure.com/{organization}/{project}/_apis/git/pullrequests?searchCriteria.reviewerId={id}&searchCriteria.status=active&$top=100&api-version=7.1`. Skip `isDraft: true`. 3. **Keep the ones without your vote**: In each pull request's `reviewers`, find your entry and keep it when `vote` is 0. A vote of -5 (waiting for author) or -10 (rejected) comes back only after the author pushes new commits; 5 and 10 are approvals and drop out. 4. **Add build and merge status** (Azure DevOps): Read `mergeStatus` (`succeeded` or `conflicts`) from the pull request, and the build policy `status` (`approved`, `rejected`, `running`, `queued`) from `GET https://dev.azure.com/{organization}/{project}/_apis/policy/evaluations?artifactId=vstfs:///CodeReview/CodeReviewId/{projectId}/{pullRequestId}&api-version=7.1-preview.1`. 5. **Rank and ask**: Sort by `creationDate`, oldest first. Post the list and ask which pull request to summarize first; never vote or complete anything. ## Route B: the browser ### What you need - Signed in to Azure DevOps with your own account, Basic access or higher, with read access to the repositories in each project. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://dev.azure.com/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Open My pull requests for the organization**: The URL lists your organizations; open the one to check, then append `/_pulls` to its address (`https://dev.azure.com//_pulls`), which is the **My pull requests** page across every project. Select the **Assigned to me** tab. 2. **Keep the active ones without your vote**: The tab groups pull requests by project and shows only active ones. Skip rows labelled **Draft**. Open each remaining pull request and read your own entry in the **Reviewers** panel on the right: keep it when it says **No vote**; approved, approved with suggestions, waiting for author and rejected drop out. 3. **Read build and merge status**: On the same **Overview** page read the required policies block at the top: the build policy line says succeeded, failed or running, and a **Merge conflicts** entry appears when the branch does not merge cleanly. Note the author, the repository and the created date shown under the title. 4. **Spot the ones back to you**: A pull request where your entry says **Waiting for author** or **Rejected** but the **Updates** tab shows a push after your vote is back to you; list it separately as a re-review. 5. **Order and ask**: Sort by created date, oldest first, and ask which pull request to summarize before opening it. Never vote or complete anything. Note: The Assigned to me tab already hides completed and abandoned pull requests, so this route is quick for a single organization. Pull requests assigned to a team you belong to appear in the same tab and are included here, where the API route needs a second query for them. ## The report - **Waiting on your vote**: count, and the age of the oldest. - One row per pull request: ID, title, repository, author, days waiting, build policy, merge conflicts. - **Back to you**: pull requests you sent back that have new commits. - The ask: which pull request to summarize before you open it. ## 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": "azure-devops-prs-waiting-on-review/", "item_key": "azure-devops-prs-waiting-on-review", "project": "Acme", "source": "Azure DevOps pull requests waiting on your review skill", "kind": "action", "title": "4 pull requests waiting on your vote", "summary": "**4** active pull requests list you as a reviewer with no vote yet. **PR 1842** has waited **5 days**; its build passed.", "action": { "request": "Shall I summarize the changes in the oldest one so you can review it first?", "options": [ "Summarize PR 1842", "Summarize all 4", "Skip the ones with conflicts", "Not today" ] }, "widget": { "type": "Table", "props": { "columns": [ "Pull request", "Repository", "Waiting", "Build", "Merge" ], "align": [ "left", "left", "right", "left", "left" ], "rows": [ [ "1842 Add retry policy to the payment client", "acme-api", "5 days", "Passed", "Clean" ], [ "1857 Split the reports page into tabs", "acme-web", "3 days", "Failed", "Clean" ], [ "1861 Terraform: move logs to the new workspace", "acme-infra", "2 days", "Passed", "Conflicts" ], [ "1866 Upgrade to .NET 9", "acme-api", "1 day", "Running", "Clean" ] ] } } } 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 azure-devops-prs-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/azure-devops-prs-waiting-on-review#schedule Source: https://briefkin.dev/skills/azure-devops-prs-waiting-on-review