Discourage review agent from approving PRs#13512
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the expert review workflow prompts to prevent automated review agents from ever submitting an APPROVE review, ensuring the workflow doesn’t count toward PR approval requirements.
Changes:
- Restrict final review submissions to COMMENT or REQUEST_CHANGES (explicitly forbidding APPROVE) in the shared review workflow instructions.
- Update the
expert-revieweragent guidance so all-clear reviews result in COMMENT rather than APPROVE.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/shared/review-shared.md | Adjusts shared workflow instructions to forbid APPROVE and require COMMENT for clean reviews. |
| .github/agents/expert-reviewer.md | Updates the agent’s final verdict mapping to never emit APPROVE. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 2
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Expert Review — PR #13512: Prevent agent from using APPROVE verdict
| # | Dimension | Verdict |
|---|---|---|
| 1 | Backwards Compatibility | ✅ LGTM |
| 5 | Test Coverage | N/A (no code) |
| 12 | Code Simplification | ✅ LGTM |
| 13 | Concurrency | N/A |
| 18 | Correctness | ✅ LGTM |
- Backwards Compat — no behavioral change to builds
- Correctness — both instruction files updated consistently; no stale APPROVE-as-event references remain in
expert-reviewer.md - Completeness — all instruction-level references to APPROVE as a review verdict are updated
Summary
Clean, well-scoped change. Both files (expert-reviewer.md and review-shared.md) are updated consistently to replace APPROVE with COMMENT for clean reviews, and add an explicit "Never use APPROVE" directive. The rationale (AI agent reviews should not satisfy branch protection approval requirements) is sound.
One observation (NIT, no action required): The .agent.lock.yml files (review-on-open.agent.lock.yml and review.agent.lock.yml) still list "APPROVE" in the event enum schema for submit_pull_request_review. This is expected since those are auto-generated API schema definitions (what the tool can accept), not behavioral instructions. The instruction-level constraint is the correct layer for this policy. However, if the lock file schema supports restricting allowed values, removing APPROVE from the enum would provide defense-in-depth — worth considering as a follow-up.
No blocking or major issues found. LGTM.
Note
🔒 Integrity filter blocked 1 item
The following item were blocked because they don't meet the GitHub integrity level.
- #13512
pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
tools:
github:
min-integrity: approved # merged | approved | unapproved | noneGenerated by Expert Code Review (on open) for issue #13512 · ● 2.5M
|
@JanKrivanek please merge with squash next time |
Follow up of #13512 ### Context PR review agent is now prevented from approving PR reviews
Context
Thanks @JanProvaznik for pointing that the expert-reviewer could approve the PR.
Notes
To completely prevent the reviewing workflow from approving we'd need to remove the
submit-pull-request-reviewfromsafe-outputs:msbuild/.github/workflows/shared/review-shared.md
Line 24 in 9b5c9da
(untill github/gh-aw#25439 is fixed and deployed)
But even better - we should tune the repo ruleset for PR approvals to either accept it only from CODEOWNERS (though we'd nee to maintain that), or to exclude 'github-actions'