--- name: github-prs-waiting-on-review description: "Twice a day: every open PR where your review is requested, the longest wait first, with size and CI state, and a nudge once one has waited over a day. Use when the user asks for this, or when it runs on a schedule." --- # GitHub PRs waiting on your review Twice a day: every open PR where your review is requested, the longest wait first, with size and CI state, and a nudge once one has waited over a day. Review requests arrive from four repos and a team alias, and GitHub's notifications mix them with every comment on every issue you ever touched. The request that waits longest is usually a small one from a teammate who is now stuck. The agent searches every repo you can see for open PRs that ask for your review, works out how long each request has waited (not how old the PR is), adds size and check status, and asks which one you will take next. Drafts stay out, and requests sent to a team you belong to are marked apart from the ones addressed to you. ## 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 - Read access to the repos; for private ones a classic token with the `repo` scope, or a fine-grained token that can read pull requests and commit statuses. - The `gh` CLI signed in (`gh auth status` shows it), or a GitHub MCP server or connector. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **Search for review requests** (GitHub): `gh search prs "draft:false" --review-requested=@me --state=open --sort=created --order=asc --json number,title,repository,author,createdAt,url --limit 50`. 2. **Find when you were asked** (GitHub): For each PR, read `timelineItems(itemTypes: [REVIEW_REQUESTED_EVENT], last: 10)` through the GraphQL API and take the latest request naming you or one of your teams. That timestamp, not the PR's age, is how long it has waited on you. 3. **Add size and checks** (GitHub): `gh pr view --repo --json additions,deletions,changedFiles,statusCheckRollup,reviewDecision`. Mark checks as failing, pending or passing, and size as S (under 100 lines changed), M (under 500) or L. 4. **Ask what to take**: Sort by wait time and flag anything waiting more than one working day. Ask which PR to review first, suggesting the small, green one that has waited longest. ## Route B: the browser ### What you need - Signed in to GitHub with an account that can read the repositories; for an organization with SAML single sign-on, authorize the session for that org first. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://github.com/pulls/review-requested. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Open the review queue**: This is the **Review requests** tab of your pull requests page. Replace the query in the search box with `is:open is:pr draft:false review-requested:@me sort:created-asc` so drafts drop out and the oldest sits first. `user-review-requested:@me` instead shows only requests that name you, which is how to tell team requests apart. 2. **Find when you were asked**: Open each PR. In the **Conversation** timeline, find the latest line "requested a review from you" (or from one of your teams) and hover its relative time for the exact timestamp. That moment, not the PR's opening date, is how long it has waited on you. 3. **Add size and checks**: The header of the **Files changed** tab shows files changed, additions and deletions: S under 100 lines changed, M under 500, L above. The merge box at the bottom of Conversation reads "All checks have passed", "Some checks were not successful" or "Some checks haven't completed yet". 4. **Ask what to take**: Sort by wait time, flag anything waiting more than one working day, and ask which PR to review first, suggesting the small, green one that has waited longest. Note: The list shows 25 pull requests per page. Repositories in a SAML-protected organization are missing from the list, without a warning, until the browser session is authorized for that organization. ## The report - **Waiting on you**: the count, and how many have waited more than a day. - **The queue**, longest wait first: repo, PR number and title, author, wait time, size and checks. - **Team requests**, marked apart from the ones addressed to you by name. - The ask: which PR to review 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": "github-prs-waiting-on-review/", "item_key": "github-prs-waiting-on-review", "project": "Acme", "source": "GitHub PRs waiting on your review skill", "kind": "action", "title": "4 pull requests waiting on your review", "summary": "The longest wait, **acme-web #1284**, is 2 days old: 38 lines with passing checks.", "action": { "request": "Which one do you want to review first?", "options": [ "#1284 Fix timezone in invoices", "#612 Rate limit headers", "Show me all four", "Not today" ] }, "widget": [ { "type": "Table", "props": { "columns": [ "PR", "Author", "Waiting", "Size", "Checks" ], "align": [ "left", "left", "right", "right", "left" ], "rows": [ [ "acme-web #1284 Fix timezone in invoice dates", "dana", "2d 3h", "S +31 -7", "passing" ], [ "acme-api #612 Add rate limit headers", "jlee", "1d 5h", "M +240 -18", "passing" ], [ "acme-web #1297 Move settings to the app router", "mo", "6h", "L +1,204 -880", "failing" ], [ "acme-infra #88 Bump the Terraform AWS provider", "renovate", "2h", "S +4 -4", "pending" ] ] } }, { "type": "Text", "props": { "text": "#88 was requested from @acme/platform, not from you by name.", "variant": "muted" } } ] } 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:30 and 13:30 (`30 9,13 * * 1-5`). From cron, with the agent signed in on that machine: ```bash 30 9,13 * * 1-5 claude -p "Run the github-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/github-prs-waiting-on-review#schedule Source: https://briefkin.dev/skills/github-prs-waiting-on-review