From 0b1ee39a0afdd4dd8d73cb2fb5e51e07351a74da Mon Sep 17 00:00:00 2001 From: openhands Date: Wed, 27 May 2026 15:35:39 +0000 Subject: [PATCH] fix(github-pr-review): add explicit guidance on when to use APPROVE event The skill's example JSON template uses "event": "COMMENT" and the summary says "post a short approval message" without specifying the event type. Agents follow the template literally and default to COMMENT even when the review is fully positive with no issues. Changes: - Add "Choosing the event Value" section with a table mapping APPROVE/COMMENT/REQUEST_CHANGES to review outcomes - State "Default to APPROVE" when code is merge-ready - Update summary item 8 to explicitly mention "event": "APPROVE" - Reorder event values to list APPROVE first in the parameters table Co-authored-by: openhands --- skills/github-pr-review/SKILL.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/skills/github-pr-review/SKILL.md b/skills/github-pr-review/SKILL.md index 7ba363cb..f44eb3e4 100644 --- a/skills/github-pr-review/SKILL.md +++ b/skills/github-pr-review/SKILL.md @@ -56,12 +56,22 @@ gh api -X POST repos/{owner}/{repo}/pulls/{pr_number}/reviews --input /tmp/revie | Parameter | Description | |-----------|-------------| | `commit_id` | Commit SHA to comment on (use `git rev-parse HEAD`) | -| `event` | `COMMENT`, `APPROVE`, or `REQUEST_CHANGES` | +| `event` | `APPROVE`, `COMMENT`, or `REQUEST_CHANGES` (see below) | | `path` | File path as shown in the diff | | `line` | Line number in the NEW version (right side of diff) | | `side` | `RIGHT` for new/added lines, `LEFT` for deleted lines | | `body` | Comment text with priority label | +### Choosing the `event` Value + +| Event | When to use | +|-------|-------------| +| `APPROVE` | No issues found, or only 🟡 suggestions that are non-blocking | +| `COMMENT` | You have 🟠 Important feedback but it's not a hard blocker | +| `REQUEST_CHANGES` | There are 🔴 Critical issues that **must** be fixed before merge | + +**Default to `APPROVE`** when the code is correct and merge-ready. Use `COMMENT` or `REQUEST_CHANGES` only when there are actionable issues that warrant it. + ### Multi-Line Comments For comments spanning multiple lines, add `start_line` to specify the range: @@ -145,4 +155,4 @@ curl -X POST \ 5. Do NOT post comments for code that is acceptable — only comment when action is needed 6. Use suggestion syntax for concrete code changes 7. Keep the review body brief (details go in inline comments) -8. If no issues: post a short approval message with no inline comments +8. If no issues: use `"event": "APPROVE"` with a short approval message and no inline comments