Weekday Slack nudges for stale Bitbucket pull requests

Every weekday at 9am, help me nudge reviewers about stale Bitbucket pull requests by posting one grouped message to our engineering Slack channel. The point is to keep review latency low without pinging people individually all day. Bitbucket has no native "remind reviewer" feature, so this workflow fills that gap.

Start by listing open pull requests across the Bitbucket repositories we track using the List Pull Requests operation. It defaults to OPEN, and pagelen caps at 50, so page through when a repo has more than that. Narrow the query with the BBQL q parameter filtering on updated_on so we only look at PRs that have been idle for more than two business days, for example q=updated_on<"2026-07-10T00:00:00Z". Bitbucket pull request states are always uppercase (OPEN, MERGED, DECLINED, SUPERSEDED).

For each candidate, skip pull requests authored by a bot account, and skip pull requests where a reviewer already has a changes-requested state on their review, because those are correctly stalled on the author and not on the reviewers. For everything that survives, call the List Pull Request Activity operation on the pull request to walk the log of approvals, updates, and comments so you can identify which listed reviewers still owe a review (they have not approved yet, and they have not just been handed a new revision to react to).

Once you have a per-reviewer picture, assemble one grouped Slack message and post it to the engineering channel using the Slack Bot Send a Message operation. Open the message with a bulleted line per pending reviewer using their Slack handle where you can resolve it ("@alice - 3 PRs waiting on you", "@bob - 1 PR waiting on you"), then list each stale pull request as a short human-readable line with title, author, how long it has been waiting, and a link to the PR. Slack messages use mrkdwn (*bold*, _italic_, <url|text> for links), not standard Markdown, so format links accordingly. When you know a reviewer's Slack user ID, use the <@USERID> mention syntax so the message actually pings them; fall back to a plain @handle display when you do not.

Post exactly one grouped message per run. If nothing qualifies on a given morning, skip the post rather than sending an empty ping. Only run on weekdays - the cron schedule should already enforce that.