# Nudge stalled Azure DevOps pull requests every weekday

> Every weekday morning we check your open pull requests, work out who is actually blocking each one, and send that person a direct message in Slack.

- Workflow type: agent
- Services: Azure DevOps, Slack Bot
- Categories: Engineering
- Published: 2026-08-14

## What it does

- Sweeps every open pull request across your repositories each weekday morning and works out how long each one has been sitting idle.
- Reads the review comments and approval status to decide whether the author needs to make changes or a reviewer needs to take a look.
- Sends the one person who owes the next step a direct Slack message naming the pull request, how long it has stalled, and exactly what to do.
- Posts a single ranked summary to your engineering channel, most blocking and longest waiting first, ready for standup.

## What you'll need

- An Azure DevOps account with access to the repositories you want covered
- A Slack workspace where the assistant can send direct messages and post to your engineering channel
- Team members whose Slack account uses the same email address as their Azure DevOps profile, since that is how people are matched
- The name of the Slack channel your team uses for standup

## Prompt

Every weekday at 9:30am, sweep all open pull requests across my Azure DevOps repositories and nudge the one person who owns the next action on each stalled pull request. Use a cron trigger so this works without depending on service hook configuration.

Start with List Repositories to enumerate the Git repositories in my project, then use List Pull Requests on each repository filtered to active pull requests. For every pull request that survives the filters below, call Get Pull Request for the full detail, including reviewer vote state and timestamps, and List PR Threads to read the comment threads.

Skip draft pull requests, anything opened in the last 24 hours, and any pull request where every assigned reviewer has already voted approved. Treat a pull request as stalled when there has been no new commit, comment, or reviewer vote for at least 2 days. Make that idle threshold a value I can easily change, and measure idle time from the most recent activity of any kind rather than from the creation date.

For each stalled pull request, work out who actually owns the next action. Read the reviewer votes (approved, approved with suggestions, waiting for the author, rejected, or no vote at all) together with the unresolved comment threads. If unresolved threads contain reviewer questions or change requests the author has not answered or addressed, the ball is with the author. If the author has replied to every open thread or pushed new commits since the last review, or if no reviewer has voted at all, the ball is with the reviewer who is silent or who last requested changes. Choose exactly one responsible person per pull request, and note the specific reason so the message can be concrete.

Resolve that person from their Azure DevOps identity to their Slack account with Look Up User by Email, using the email address on their Azure DevOps profile, then use Send a Message to send them a direct message. Each message should name the pull request with its title and link, say how many days it has been idle, and state the single specific next action they owe, for example that three reviewer comments about error handling are still unresolved on their pull request, or that they were added as a reviewer six days ago and have not voted yet. Keep it to a couple of sentences, stay friendly rather than accusatory, and send at most one direct message per person per pull request per run. If no Slack account matches that email address, skip the direct message and still include the pull request in the team summary.

Finish by using Send a Message to post one ranked summary to my engineering channel, ordered with the most blocking and longest idle pull requests first. For each entry show the repository, the pull request title and link, how many days it has been idle, who is blocking it, and the next action they owe. Add a one line total of how many pull requests are stalled so the team sees the whole review queue in one place at standup. If nothing is stalled, post a short all clear instead of staying silent.

## How to customize

- Change how many days a pull request can sit untouched before it counts as stalled, which starts at two days
- Move the run time, or have it run only on certain days of the week
- Limit the sweep to specific repositories, or only to pull requests aimed at your main release branch

## FAQ

### Will people get pinged about brand new pull requests?

No. Anything opened in the last 24 hours is skipped, along with drafts and any pull request that every reviewer has already approved. People only hear about work that is genuinely stuck.

### Does everyone involved in the review get a message?

No, and that is the point. Each stalled pull request produces exactly one direct message to the single person who owes the next step, so nobody learns to tune out a group blast.

### What if someone's Slack email does not match their Azure DevOps email?

People are matched by email address. If no Slack account matches, the direct message is skipped but that pull request still appears in the team summary, so nothing quietly falls off the list.

### Does this change anything in our pull requests?

No. It only reads your pull requests and their comments. Nothing is commented, approved, merged, or edited in Azure DevOps. The only thing it sends is Slack messages.

### Can it cover more than one repository?

Yes. It looks across the repositories in your project by default, and you can narrow it to a specific list if only some teams want the nudges.

Use this prompt in General Input: https://www.generalinput.com/prompts/nudge-stalled-azure-devops-pull-requests-every-weekday