Harden reviewer eligibility for auto-assigned PR reviews

.github/workflows/assign-reviews.yml

@@ -121,16 +121,25 @@ jobs:
                 3. CI is passing and there are no merge conflicts
 
                 For each PR that truly has NO reviewers:
-                1) Read git blame for changed files to identify recent, active contributors.
-                2) From those candidates, ONLY consider maintainers — repository collaborators with write access or higher. Verify via the GitHub API before
-                requesting review:
-                   - Preferred: GET /repos/{owner}/{repo}/collaborators (no permission filter). Filter client-side using either:
-                     role_name in ["write", "maintain", "admin"] OR permissions.push || permissions.admin. Note: paginate if > 30 collaborators.
-                   - Alternative: GET /repos/{owner}/{repo}/collaborators/{username}/permission and accept if permission in {push, maintain, admin}.
-                3) If multiple maintainers qualify, avoid assigning too many reviews to any single one.
-                4) Request review from exactly one maintainer and add this message:
-
-                [Automatic Post]: I have assigned {reviewer} as a reviewer based on git blame information.
+                1) Build reviewer candidates ONLY from human users who appear in git blame for the changed files or changed hunks on the base branch.
+                   Never invent or guess a reviewer who does not appear in blame for at least one changed file.
+                2) Before requesting review, verify that each candidate meets ALL of these requirements:
+                   - Is a human user (not a bot or app) and is not the PR author.
+                   - Has repository write access or higher. Verify via the GitHub API before requesting review:
+                     * Preferred: GET /repos/{owner}/{repo}/collaborators (no permission filter). Filter client-side using either:
+                       role_name in ["write", "maintain", "admin"] OR permissions.push || permissions.admin. Note: paginate if > 30 collaborators.
+                     * Alternative: GET /repos/{owner}/{repo}/collaborators/{username}/permission and accept if permission in {push, maintain, admin}.
+                   - Has authored at least one commit in this repository in the last 12 months:
+                     GET /repos/{owner}/{repo}/commits?author={username}&per_page=1&since={iso_timestamp}
+                   - Has authored at least one commit touching at least one changed file in the last 12 months:
+                     GET /repos/{owner}/{repo}/commits?author={username}&path={file}&per_page=1&since={iso_timestamp}
+                3) NEVER assign someone solely because they are a maintainer or collaborator. If they have write access but zero qualifying commits, they are NOT eligible.
+                4) For bot-authored PRs (for example dependabot[bot]), be stricter: only assign a reviewer if they have a qualifying recent commit touching a changed
+                   file. If no one qualifies, leave the PR unassigned and do NOT comment.
+                5) If multiple eligible reviewers qualify, avoid assigning too many reviews to any single one.
+                6) Request review from exactly one eligible reviewer and add this message:
+
+                [Automatic Post]: I have assigned {reviewer} as a reviewer based on git blame and recent commit history.
                 Thanks in advance for the help!
 
             LLM_MODEL: litellm_proxy/claude-sonnet-4-5-20250929

AGENTS.md

@@ -115,6 +115,8 @@ When reviewing code, provide constructive feedback:
 - Workspace-wide uv resolver guardrails belong in the repository root `[tool.uv]` table. When `exclude-newer` is configured there, `uv lock` persists it into the root `uv.lock` `[options]` section as both an absolute cutoff and `exclude-newer-span`, and `uv sync --frozen` continues to use that locked workspace state.
 - `pr-review-by-openhands` delegates to `OpenHands/extensions/plugins/pr-review@main`. Repo-specific reviewer instructions live in `.agents/skills/custom-codereview-guide.md`, and because task-trigger matching is substring-based, that `/codereview` skill is also auto-injected for the workflow's `/codereview-roasted` prompt.
 - Auto-title generation should not re-read `ConversationState.events` from a background task triggered by a freshly received `MessageEvent`; extract message text synchronously from the incoming event and then reuse shared title helpers (`extract_message_text`, `generate_title_from_message`) to avoid persistence-order races.
+- The `assign-reviews` workflow currently relies on prompt-driven reviewer assignment. Keep its reviewer eligibility constraints explicit and API-verifiable: reviewers must come from git blame for the changed files, have write access, and have recent commit history in both the repo and the touched files; for bot-authored PRs, prefer leaving the PR unassigned over guessing a maintainer.
+
 
 
 ## Package-specific guidance

examples/03_github_workflows/01_basic_action/assign-reviews.yml

@@ -99,12 +99,21 @@ jobs:
                 3. Were created more than 1 day ago.
                 4. CI is passing and there are no merge conflicts.
 
-                For each of these pull requests, read the git blame information for the files,
-                and find the most recent and active contributors to the file/location of the changes.
-                Assign one of these people as a reviewer, but try not to assign too many reviews to
-                any single person. Add this message:
-
-                [Automatic Post]: I have assigned {reviewer} as a reviewer based on git blame information.
+                For each of these pull requests:
+                1. Build reviewer candidates ONLY from human users who appear in git blame for the changed files or changed hunks on the base branch.
+                   Never invent or guess a reviewer who does not appear in blame for at least one changed file.
+                2. Before requesting review, verify that each candidate:
+                   - Is not a bot or app and is not the PR author.
+                   - Has write access or higher on the repository.
+                   - Has authored at least one commit in this repository in the last 12 months.
+                   - Has authored at least one commit touching at least one changed file in the last 12 months.
+                3. NEVER assign someone solely because they are a maintainer or collaborator. If they have write access but zero qualifying commits, they are NOT eligible.
+                4. For bot-authored PRs (for example dependabot[bot]), be stricter: only assign a reviewer if they have a qualifying recent commit touching a changed
+                   file. If no one qualifies, leave the PR unassigned and do NOT comment.
+                5. If multiple eligible reviewers qualify, avoid assigning too many reviews to any single person.
+                6. Add this message:
+
+                [Automatic Post]: I have assigned {reviewer} as a reviewer based on git blame and recent commit history.
                 Thanks in advance for the help!
 
             LLM_MODEL: <YOUR_LLM_MODEL>