Stale PR Slack DM bot: nudge reviewers and authors daily

Q: How does the agent decide who to ping for each PR?

It calls List Pull Request Reviews for each candidate. If the latest review is a change request, the PR author gets pinged. If there are no reviews yet or reviews are stale, the requested reviewers get pinged.

Q: What counts as a stale pull request?

By default, any open PR whose updated_at is older than 3 days, found via GitHub's Search Issues and Pull Requests with the query is:pr is:open updated:<3-days-ago. You can change the window in the prompt.

Q: Will it spam the same person every day?

Each run is a fresh snapshot, so the same PRs may appear until they're updated or closed. You can ask the agent to skip PRs that were nudged in the last 24 hours, or to escalate after the third nudge.

Q: How does it map GitHub users to Slack users?

It tries to match by primary email first, then by display name. For reliability, you can hand the agent an explicit map of GitHub usernames to Slack user IDs.

Q: Can it post to a channel instead of DMs?

Yes. Tell the agent to post a single digest in #eng-prs instead of opening DMs. You can also do both: a channel summary plus targeted DMs for owners.

Build me an agent workflow that nudges people about stale pull requests every weekday at 10am.

Trigger: cron, every weekday (Mon-Fri) at 10:00am in my local timezone.

What the agent should do on each run:

1. Use GitHub Search Issues and Pull Requests with a query like is:pr is:open updated:<3-days-ago, scoped to my repos or org. Return up to ~50 candidate PRs sorted by oldest update first.

2. For each candidate PR, call GitHub List Pull Request Reviews to see who has reviewed it and what state their last review was in. Use that to decide who is on the hook:

- If the most recent review on the PR is a CHANGES_REQUESTED, the PR author is on the hook. Put it in the "author needs to respond" bucket.

- If there are no reviews yet, or the last review state is COMMENTED with no approval and no change request, the requested reviewers are on the hook. Put it in the "waiting on reviewer" bucket. If a PR has multiple requested reviewers, ping each of them.

- Skip draft PRs and PRs labeled wip or do-not-merge.

3. Group results by person (GitHub login). Each person should end up with a small list of PRs they're blocking, with a one-line note for each: title, repo, age ("updated 5 days ago"), and the PR URL.

4. Map each GitHub user to a Slack user. Try matching on primary email first, then display name. If you can't resolve someone, skip them and include them in a final summary so I know who fell through.

5. For every resolved person, draft a short, friendly Slack DM (not a corporate-sounding one) that:

- Opens with one sentence of context ("Quick PR nudge").

- Lists their PRs as bullets with the title, repo, age, and link.

- Tailors the verb to the bucket: reviewers get "could you take a look", authors get "this is waiting on changes from you".

- Stays under ~6 lines total.

6. Send each DM via Slack: call Open a Conversation with the target user's Slack ID to get a DM channel, then call Send a Message with the drafted text. Don't @-mention them inside the DM.

7. At the end, log a short run summary (how many PRs scanned, how many people pinged, anyone you couldn't resolve) so I can spot-check it.

Constraints: don't ping the same person more than once per run even if they own multiple PRs (consolidate into a single DM). Don't post in any public channels by default. If GitHub Search returns zero stale PRs, exit without sending anything.

Additional information

What does this prompt do?

Runs every weekday at 10am and pulls open pull requests that haven't been updated in 3+ days using GitHub's Search Issues and Pull Requests.
For each candidate PR, calls List Pull Request Reviews to figure out whether reviewers have actually engaged.
Sorts PRs into two buckets: waiting on a reviewer, and waiting on the author after a change request.
Drafts a short, friendly Slack DM per person listing only the PRs they own, then opens a conversation and sends the message.

What do I need to use this?

A connected GitHub account with read access to the repos you want monitored.
A connected Slack workspace where the agent can open DMs and send messages.
Optional: a list of repos or a GitHub org/team to scope the search to.
GitHub usernames mapped to Slack users (the agent will try to match by email or display name, but a manual map is more reliable).

How can I customize it?

Change the schedule (10am ET, twice a day, only Mon/Wed/Fri) or the staleness threshold (default updated:<3-days-ago).
Scope the GitHub search to specific orgs, repos, teams, or labels (for example, exclude draft PRs or PRs labeled wip).
Tweak the DM tone and format, or fall back to a single channel post for people who haven't installed Slack DMs from the bot.

Frequently asked questions

How does the agent decide who to ping for each PR?

It calls List Pull Request Reviews for each candidate. If the latest review is a change request, the PR author gets pinged. If there are no reviews yet or reviews are stale, the requested reviewers get pinged.

What counts as a stale pull request?

By default, any open PR whose updated_at is older than 3 days, found via GitHub's Search Issues and Pull Requests with the query is:pr is:open updated:<3-days-ago. You can change the window in the prompt.

Will it spam the same person every day?

Each run is a fresh snapshot, so the same PRs may appear until they're updated or closed. You can ask the agent to skip PRs that were nudged in the last 24 hours, or to escalate after the third nudge.

How does it map GitHub users to Slack users?

It tries to match by primary email first, then by display name. For reliability, you can hand the agent an explicit map of GitHub usernames to Slack user IDs.

Can it post to a channel instead of DMs?

Yes. Tell the agent to post a single digest in #eng-prs instead of opening DMs. You can also do both: a channel summary plus targeted DMs for owners.