You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update address-review command with triage system and thread resolution
Added MUST-FIX/DISCUSS/SKIPPED triage classification before creating todos, allowing users to focus on high-impact items. Also added GitHub GraphQL thread resolution to close feedback loops after addressing comments. Improved bot comment handling to deduplicate and filter by actionability rather than blanket-skipping. Added support for standalone review comment replies and better error handling.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Merge and de-duplicate results before creating todos.
73
-
74
54
**Filtering comments:**
75
55
76
56
- Skip comments where `in_reply_to_id` is set (these are replies, not top-level comments)
77
-
- Skip bot-generated comments (check if `user` ends with `[bot]`)
57
+
- Do not skip bot-generated comments by default. Many actionable review comments in this repository come from bots.
58
+
- Deduplicate repeated bot comments and skip bot status posts, summaries, and acknowledgments that do not require a code or documentation change
59
+
- Treat as actionable by default only: correctness bugs, regressions, missing tests, and clear inconsistencies with adjacent code
60
+
- Treat as non-actionable by default: style nits, speculative suggestions, changelog wording, duplicate bot comments, and "could consider" feedback unless the user explicitly asks for polish work
78
61
- Focus on actionable feedback, not acknowledgments or thank-you messages
79
62
80
63
**Error handling:**
@@ -83,45 +66,88 @@ Merge and de-duplicate results before creating todos.
83
66
- If the API returns 403, check authentication with `gh auth status`
84
67
- If the response is empty, inform the user no review comments were found
85
68
86
-
## Step 4: Create Todo List
69
+
## Step 4: Triage Comments
70
+
71
+
Before creating any todos, classify every review comment into one of three categories:
72
+
73
+
-`MUST-FIX`: correctness bugs, regressions, security issues, missing tests that could hide a real bug, and clear inconsistencies with adjacent code that would likely block merge
74
+
-`DISCUSS`: reasonable suggestions that expand scope, architectural opinions that are not clearly right or wrong, and comments where the reviewer claim may be correct but needs a user decision
- Deduplicate overlapping comments before classifying them. Keep one representative item for the underlying issue.
80
+
- Verify factual claims locally before classifying a comment as `MUST-FIX`.
81
+
- If a claim appears wrong, classify it as `SKIPPED` and note briefly why.
82
+
- Preserve the original review comment ID and thread ID when available so the command can reply to the correct place and resolve the correct thread later.
83
+
84
+
## Step 5: Create Todo List
87
85
88
-
Parse the response and create a todo list with TodoWrite containing:
86
+
Create a todo list with TodoWrite containing**only the `MUST-FIX` items**:
89
87
90
-
- One todo per actionable review comment/suggestion
88
+
- One todo per must-fix comment or deduplicated issue
91
89
- For file-specific comments: `"{file}:{line} - {comment_summary} (@{username})"` (content)
92
-
- For general comments: Parse the comment body and extract actionable items
90
+
- For general comments: Parse the comment body and extract the must-fix action
91
+
- Format activeForm: `"Addressing {brief description}"`
93
92
- All todos should start with status: `"pending"`
94
93
95
-
## Step 5: Present to User
94
+
## Step 6: Present Triage to User
96
95
97
-
Present the todos to the user - **DO NOT automatically start addressing them**:
96
+
Present the triage to the user - **DO NOT automatically start addressing items**:
98
97
99
-
- Show a summary of how many actionable items were found
100
-
- List the todos clearly
101
-
- Wait for the user to tell you which ones to address
98
+
- Number all items sequentially across categories so users can reference any item by number
99
+
-`MUST-FIX ({count})`: list the todos created
100
+
-`DISCUSS ({count})`: list items needing user choice, with a short reason
101
+
-`SKIPPED ({count})`: list skipped comments with a short reason, including duplicates and factually incorrect suggestions
102
+
- Wait for the user to tell you which items to address
103
+
- If useful, suggest replying with a brief rationale on declined items, but do not do so unless the user asks
102
104
103
-
## Step 6: Address Itemsand Reply
105
+
## Step 7: Address Items, Reply, and Resolve
104
106
105
-
When addressing items, after completing each todo item, reply to the original review comment explaining how it was addressed.
107
+
When addressing items, after completing each selected todo item, reply to the original review comment explaining how it was addressed.
106
108
107
-
**For general PR discussion comments (issue comments):**
109
+
**For issue comments (general PR comments):**
108
110
109
111
```bash
110
112
gh api repos/${REPO}/issues/{PR_NUMBER}/comments -X POST -f body="<response>"
111
113
```
112
114
113
-
**For inline review comments (replying to a thread):**
115
+
**For PR review comments (file-specific, replying to a thread):**
114
116
115
117
```bash
116
118
gh api repos/${REPO}/pulls/{PR_NUMBER}/comments/{COMMENT_ID}/replies -X POST -f body="<response>"
117
119
```
118
120
121
+
**For standalone review comments (not in a thread):**
122
+
123
+
```bash
124
+
gh api repos/${REPO}/pulls/{PR_NUMBER}/comments -X POST -f body="<response>" -f commit_id="<COMMIT_SHA>" -f path="<FILE_PATH>" -f line=<LINE_NUMBER> -f side="RIGHT"
125
+
```
126
+
127
+
Note: `side` is required when using `line`. Use `"RIGHT"` for the PR commit side (most common) or `"LEFT"` for the base commit side.
128
+
119
129
The response should briefly explain:
120
130
121
131
- What was changed
122
132
- Which commit(s) contain the fix
123
133
- Any relevant details or decisions made
124
134
135
+
After posting the reply, resolve the review thread when all of the following are true:
136
+
137
+
- The comment belongs to a review thread and you have the thread ID
138
+
- The concern was actually addressed in code, tests, or documentation, or it was explicitly declined with a clear explanation approved by the user
139
+
- The thread is not already resolved
140
+
141
+
Use GitHub GraphQL to resolve the thread:
142
+
143
+
```bash
144
+
gh api graphql -f query='mutation($threadId:ID!) { resolveReviewThread(input:{threadId:$threadId}) { thread { id isResolved } } }' -f threadId="<THREAD_ID>"
145
+
```
146
+
147
+
Do not resolve a thread if the fix is still pending, if you are unsure whether the reviewer concern is satisfied, or if the user asked to leave the thread open.
148
+
149
+
If the user explicitly asks to close out a `DISCUSS` or `SKIPPED` item, reply with the rationale and resolve the thread only when the conversation is actually complete.
150
+
125
151
# Example Usage
126
152
127
153
```text
@@ -133,16 +159,24 @@ The response should briefly explain:
133
159
134
160
# Example Output
135
161
136
-
After fetching comments, present them like this:
162
+
After fetching and triaging comments, present them like this:
137
163
138
164
```text
139
-
Found 3 actionable review comments:
165
+
Found 5 review comments. Triage:
166
+
167
+
MUST-FIX (1):
168
+
1. ⬜ src/helper.rb:45 - Missing nil guard causes a crash on empty input (@reviewer1)
169
+
170
+
DISCUSS (1):
171
+
2. src/config.rb:12 - Extract this to a shared config constant (@reviewer1)
172
+
Reason: reasonable suggestion, but it expands scope
140
173
141
-
1. ⬜ src/helper.rb:45 - Add error handling for nil case (@reviewer1)
142
-
2. ⬜ src/config.rb:12 - Consider using constant instead of magic number (@reviewer1)
143
-
3. ⬜ General comment - Update documentation to reflect API changes (@reviewer2)
0 commit comments