iterate skill: add review thread reply and resolve guidance#206
Conversation
The iterate skill previously told the agent to fix code and push when addressing review feedback, but never mentioned replying to individual review threads or resolving them. This left threads dangling in the GitHub UI even after the code was fixed. Changes: - Updated the actionable/non-actionable comment workflows to include reply and resolve steps - Added a new 'Replying to and resolving review threads' subsection with concrete gh CLI commands (REST for reply, GraphQL for resolve) - Added a GraphQL query for discovering unresolved threads and their IDs - Added rules: reply to every thread, resolve addressed threads, verify zero unresolved threads before marking PR ready - Updated 'When done' section to require thread verification - Added 'Review threads resolved (count)' to final summary output 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.
Solid improvement addressing a real problem. The guidance for replying to and resolving review threads fills an important gap. One workflow ordering concern to address.
|
@OpenHands /iterate until reviewer bot approves. Also send the new PR to ReviewBot. Ask it to not comment anything about acceptable; we don't want these green comments because they are just noise. |
|
I'm on it! xingyaoww can track my progress at all-hands.dev |
Commit and push before replying to review threads, so the reply can reference the actual commit SHA (e.g. 'Fixed in abc1234'). Co-authored-by: openhands <openhands@all-hands.dev>
|
Addressed the workflow ordering feedback in c72919c. All review threads resolved. Ready for another review. Review instruction: Please do not post 🟢 Acceptable or 🟢 Nit comments — they are noise. Only comment on items that need action (🔴 Critical, 🟠 Important, 🟡 Suggestion). |
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
✅ Solid improvement that addresses a real usability gap. The guidance for replying to and resolving review threads fills an important operational gap in the iterate workflow.
All previous concerns (particularly the workflow ordering inconsistency) have been resolved. The technical commands are correct and the integration with the existing loop structure is clean.
[RISK ASSESSMENT]
🟢 LOW - Documentation-only change that improves agent behavior without breaking existing functionality. Commands are technically correct and workflow is pragmatic.
Summary of Work DoneRequest Checklist
Changes Made
ConcisenessThe changes are minimal and focused — a single 4-line swap in the SKILL.md file. No extraneous changes were made. Final State
|
3 participants
Summary
The
/iterateskill previously told the agent to fix code and push when addressing review feedback, but never mentioned replying to individual review threads or resolving them. This left threads dangling in the GitHub UI even after the underlying code was fixed.Changes
Updated review comment workflow (steps)
New subsection: "Replying to and resolving review threads"
ghCLI commands for replying (REST API with-Ffor numericin_reply_to)ghCLI command for resolving threads (GraphQLresolveReviewThreadmutation)Updated "When done" section
gh pr readyUpdated final summary output
Motivation
This was discovered during a real iteration on PR #205, where all review feedback was addressed in code but none of the 10 review threads were replied to or resolved. The reviewer experience was poor — they had to manually check each thread to see if it was addressed. The iterate skill should close the loop properly.
This PR was created by an AI assistant (OpenHands) on behalf of the user.