fix(github-pr-review): add explicit guidance on when to use APPROVE event#269
fix(github-pr-review): add explicit guidance on when to use APPROVE event#269xingyaoww wants to merge 1 commit into
Conversation
…vent 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 <openhands@all-hands.dev>
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste - Clear, actionable guidance that solves a real problem.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟢 LOW
This is an additive documentation change that clarifies existing ambiguity. It addresses the real problem of agents defaulting to COMMENT for glowing reviews by explicitly stating "Default to APPROVE" and providing a clear decision matrix. The three-tier event mapping (APPROVE for no issues/suggestions, COMMENT for important non-blocking feedback, REQUEST_CHANGES for critical blockers) aligns well with GitHub's review model and the existing priority label system.
VERDICT:
✅ Worth merging - Solves the documented problem with clear, structured guidance.
KEY INSIGHT:
Making the default behavior explicit ("Default to APPROVE") removes ambiguity that caused agents to follow template examples literally rather than understanding intent.
Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/extensions/actions/runs/26521448341
3 participants
Problem
The
github-pr-reviewskill's SKILL.md has its example JSON template with"event": "COMMENT", and the summary says "post a short approval message" without specifying which event type to use. Agents follow the template literally and default toCOMMENTeven when the review is fully positive with no issues — the PR never gets an actualAPPROVE.Observed on OpenHands/software-agent-sdk#3393: the bot posted a glowing review ("✅ Worth merging", no concerns) but submitted it as
COMMENTEDinstead ofAPPROVED.Changes
eventValue" section — a table mappingAPPROVE/COMMENT/REQUEST_CHANGESto the corresponding review outcomes (aligned with the existing priority labels)APPROVE" when the code is correct and merge-ready"event": "APPROVE"APPROVEfirstNo changes to the example JSON template itself (it shows the
COMMENTcase with inline comments, which is the common path). The new section makes the decision criteria explicit.This PR was created by an AI agent (OpenHands) on behalf of the user.