Suggest Bitbucket PR reviewers from recent commit history

When a new pull request is opened in Bitbucket (the pullrequest:created webhook event), suggest two or three teammates who would be good reviewers based on who has been editing the changed files most in the last few months. Post the suggestions as a single comment on the pull request.

Skip the whole workflow if the pull request is a draft. Also skip if a suggestion comment has already been posted on this PR by this workflow, so a repeat webhook fire is a no-op.

Step 1. Use Bitbucket's Get Pull Request operation to load the full PR: title, author, current reviewers, source and destination branches, draft flag, and state. If the draft flag is true, stop.

Step 2. Use Get Pull Request Diffstat to enumerate the files the PR changes. Keep the file paths (including old_path for renames). If there are a lot of files, focus on the top 15 or so by lines changed so the commit-history lookups stay reasonable.

Step 3. For each changed path, use List Commits filtered by that path on the destination branch to fetch its recent commit history. Look at roughly the last 90 days, or the most recent 30 commits on that path, whichever is smaller. Skip merge commits.

Step 4. Aggregate the authors across all those commits. For each author, track how many commits they made, which files or directories they touched most, and how recent their last commit was. Prefer the Bitbucket account_id or uuid over display name so you match the same person consistently.

Step 5. Filter out the PR author, everyone already listed on the pull request's reviewers array, and obvious bot or service accounts (display names or usernames containing tokens like bot, ci, renovate, dependabot, github-actions).

Step 6. Rank the remaining candidates by commit count first, then by recency of their most recent commit. Take the top three. Cap the list at three names no matter what.

Step 7. Write a one-line reason for each selected person, grounded in the actual numbers you counted. Good examples: 'Sam is the author of 6 of the last 10 commits on src/billing/', or 'Priya touched 4 of the 7 files in this PR within the last month'. Do not invent numbers; if you cannot back a claim with the counts, drop it and pick a simpler phrasing.

Step 8. If fewer than two candidates make the bar, do NOT pad the list. Say so honestly, for example: 'Only one strong candidate stood out based on recent history — worth a manual look for a second reviewer.' or 'No clear historical owners on these paths — recommend picking reviewers manually this time.'

Step 9. Use Create Pull Request Comment to post a single general comment on the PR. Keep it short: one intro line ('Suggested reviewers based on recent commit history:'), then one bullet per person with the reason. Do not @-mention people (that would trigger notifications for everyone every PR); use their display name in plain text. Never post more than one comment per PR.