Nobody gets an alert when a pull request has waited three days for a review. It just slides down the list as fresh ones pile on top. Eventually the author messages someone directly, or quietly moves on to other work. Spread that over a whole team and your review SLA turns into a nice idea that nobody checks. "Changes requested" stops being a step and becomes a place where PRs go to live.

So we gave the job to an agent on Machine. Once a day it reads every open pull request across our repos and sends a Slack nudge for each one that's stuck: overdue for review, gone quiet, or still waiting on requested changes. It only reads GitHub. A Slack nudge is the one thing it produces. Merging, closing and approving are never on the table.

The problem

Writing a review SLA down takes a minute. Sticking to it is another matter. No one watches the queue all day, so a PR opened first thing Monday that's still untouched by Wednesday afternoon looks just like one opened a moment ago, until somebody happens to scroll down far enough. Stale PRs are worse. A branch with a week of no commits, no comments and no reviews has usually been forgotten, and it decays out of sight until a merge conflict drags someone back to it. Then there's "requested changes", which is a label, not a warning. The reviewer asks for edits, the author reads them, the week gets busy, and the PR sits there looking open when really it's blocked.

The usual habits leave gaps. GitHub notifications are easy to mute, and they treat a PR from five minutes ago the same as one from five days ago. A weekly standup hears about the loud blockers and misses the quiet ones. Reading through the PR list by hand is careful the first week and forgotten by the next.

What we built

Each day, a cron on Machine starts an agent in a brand new session that can read GitHub through the gh CLI and do nothing else there. It gathers every open PR in our repos and checks it against three rules. Is it waiting on a review past the SLA? Has it seen no activity for N days? Does it have requested changes the author hasn't dealt with? When a PR breaks a rule, the agent sends a Slack nudge to whoever has to act next. That's the requested reviewer when a review is late, and the author when the PR is stale or has open feedback. Each nudge carries one line saying what's really in the way.

How it works

The pattern

Once a day a cron opens a new session that reads open PRs through the gh CLI using a scoped GH_TOKEN. A skill holds the rules for late reviews, stale PRs and changes not dealt with. The agent can see it all, and the only thing it writes is a Slack nudge.

Guardrails

The agent can see across every repo we point it at, so its reach is narrow and flows one way only:

• Kept apart. Each run gets its own sealed-off sandbox. The session can reach GitHub, read-only, and Slack, and it sends nothing anywhere else.
• Locked-down key. The GH_TOKEN is stored encrypted in the Secrets Manager, added to the sandbox at run time, and only handed to the agents you grant it to.
• Nudges and summaries, that's all. It won't merge, close or approve a PR, and it won't dismiss or resolve a review. It says what's stuck and leaves the call to a person.
• All of it lives in code. The SLA limits, the stale window and what the agent may do in GitHub are files in the repo. They're versioned, and you change them with a reviewed change request, not a setting on a dashboard.

The outcome

Our review queue used to depend on someone remembering to scroll it. Now it reports its own blockers each morning in Slack, to whoever needs to move next. The agent reads and nudges, nothing more. Every PR's fate is still the team's decision.