Batch PR comment review decisions

.changeset/bright-comments-review.md

@@ -0,0 +1,5 @@
+---
+'@kin0992/skills': patch
+---
+
+Improve review-pr-comments triage by batching decisions and requiring consent before implementing accepted code changes.

.github/plugin/marketplace.json

@@ -17,7 +17,7 @@
     {
       "name": "engineering-skills",
       "description": "Skills for engineering workflows: triage unresolved pull-request review comments and draft approval-gated replies.",
-      "version": "0.1.0",
+      "version": "0.1.1",
       "source": "./plugins/engineering-skills"
     },
     {

evals/review-pr-comments/trigger_tests.yaml

@@ -13,6 +13,14 @@ should_trigger_prompts:
     reason: 'Requests unresolved thread evaluation and reply drafting'
     confidence: high
 
+  - prompt: 'There are lots of unresolved comments on this PR. Triage each one with me, then publish the approved reactions and replies together.'
+    reason: 'Requests grouped decision collection before GitHub mutations'
+    confidence: high
+
+  - prompt: 'After we decide which review comments to accept, ask me before making any requested code changes.'
+    reason: 'Requests explicit implementation consent after comment decisions'
+    confidence: high
+
 should_not_trigger_prompts:
   - prompt: 'Reply to this general PR conversation comment.'
     reason: 'General PR comments have no unresolved review-thread state'

package.json

@@ -30,13 +30,13 @@
     "@kin0992/oxc-config": "workspace:*",
     "oxfmt": "catalog:core",
     "oxlint": "catalog:core",
-    "turbo": "^2.10.8",
+    "turbo": "^2.10.9",
     "typescript": "catalog:core",
     "vitest": "^4.1.10"
   },
   "engines": {
     "node": ">=24.0.0",
     "pnpm": ">=11.0.0"
   },
-  "packageManager": "pnpm@11.20.0+sha512.9a6f330a95b66446ea088faf1521405a8a01f07fde7124cc9958dfed52d4bb436737e65b08f85f37b46fcba375092558ac51262b816844b22f63406ed166bfee"
+  "packageManager": "pnpm@11.21.0+sha512.521705bce689924eac72f5a3587122f362689ef6571e55ba80076fd637c11132ecffada26fad4ea79c485bfddbfd3d5a2a5b05805a77e893de71ec8a6cca3bb1"
 }

packages/skills/src/engineering/review-pr-comments/SKILL.md

@@ -19,11 +19,23 @@ license: MIT
 2. Process one PR and all actionable comments in its unresolved review threads;
    include bots, but exclude general PR conversation comments.
 3. Evaluate each comment against the diff and source context.
-4. Ask one question at a time. Record `Accept` with `+1`, `Defer` with `eyes`,
-   and `Ignore` with `-1`. Do not edit code merely because it was accepted.
-5. Suggest possible answers. Post a reply only after exact-text and target
-   approval; editing a draft is not approval.
-6. Never resolve threads or post general PR comments.
+4. If there is more than one actionable comment, enter batch triage before
+   making any GitHub mutation. Ask one question at a time, and for each comment
+   show its recommendation plus a concise suggested reply. Record `Accept` with
+   `+1`, `Defer` with `eyes`, and `Reject` with `-1`; do not edit code merely
+   because a comment was accepted.
+5. After all decisions are collected, identify accepted comments that require
+   code changes and ask explicitly whether to implement them. An `Accept`
+   decision never authorizes code edits. If approved, implement and validate
+   the requested changes before finalizing reply drafts; if declined, leave
+   code unchanged and continue with the decisions.
+6. Keep every decision and reply draft grouped locally until triage and any
+   authorized implementation are complete. Then show the complete grouped plan
+   and ask for one confirmation to publish it. Do not publish a partial batch.
+7. Publish each selected reaction and only the exact reply text approved for
+   that target. If a draft is edited, ask for approval of the new exact text
+   before publishing it.
+8. Never resolve threads or post general PR comments.
 
 Requires an authenticated `gh` CLI. Use `gh api graphql --paginate` to collect
 threads and comments, and `gh api` REST calls for reactions and approved replies.

packages/skills/src/engineering/review-pr-comments/references/gh-commands.md

@@ -75,6 +75,9 @@ query($threadId: ID!, $endCursor: String) {
 
 ## Replace a decision reaction
 
+Run these mutations only after the complete grouped plan is approved. Do not
+run them while collecting decisions or if the grouped plan is cancelled.
+
 Set `REACTION` to `+1`, `-1`, or `eyes`. Remove only decision reactions made by
 the authenticated user, then add the selected reaction:
 

packages/skills/src/engineering/review-pr-comments/references/workflow.md

@@ -13,45 +13,64 @@
    thread. Skip acknowledgements, status messages, duplicates, and replies with
    no request or technical claim; report the reason.
 
-## Decide and react
+## Decide and stage the batch
 
-For each actionable comment, show:
+For each actionable comment, show and retain:
 
 - author, file/line, and comment URL
 - requested change
 - whether it is correct, relevant, and still applicable
 - recommendation with brief evidence
-- concise possible replies when different decisions need different responses
+- one concise suggested reply, or an explicit reason no reply is needed
 
 Ask one question at a time:
 
 - `Accept (👍)` — valid and should be addressed
 - `Defer (👀)` — valid, but should be handled later
-- `Ignore (👎)` — invalid, irrelevant, duplicate, or already addressed
+- `Reject (👎)` — invalid, irrelevant, duplicate, or already addressed
 
-After the decision, use the reaction commands in
-[`gh-commands.md`](gh-commands.md). Replace only the authenticated user's
-previous `+1`, `-1`, or `eyes` decision reactions.
+Do not call any reaction or reply mutation while questions remain. Store the
+decision, target comment, and suggested reply for each item. For a single
+actionable comment, the same staging rules apply; skip the batch summary only
+when there is no second item to group.
 
-Do not react to non-actionable comments. A reaction does not mean code changed.
-If implementation is explicitly requested, treat it as separate work that may
-run asynchronously.
+After all decisions are collected, show a grouped summary containing every
+comment, selected reaction, and exact reply draft. Identify accepted comments
+that require code changes and ask explicitly:
+
+- `Implement the accepted changes`
+- `Leave code unchanged`
+
+An `Accept` decision does not authorize editing code. If implementation is
+approved, make and validate the changes before finalizing any affected reply
+drafts. If implementation is declined, leave the code unchanged and continue
+with the selected decisions. Do not react to non-actionable comments. A
+reaction does not mean code changed.
+
+After any authorized implementation is complete, show the refreshed grouped
+plan and ask for one confirmation to publish it. If the user declines, publish
+nothing. If implementation is explicitly requested but the user declines this
+consent step, treat it as declined rather than inferring approval.
 
 ## Draft and approve a reply
 
 Draft a concise reply consistent with the decision. Do not claim a change was
 implemented or verified unless that work completed.
 
-Show the exact text and target URL, then ask:
+During triage, show the exact draft and target URL alongside the decision
+question. The decision does not authorize changing the draft or targeting a
+different comment. Before the grouped publish confirmation, ask:
 
-- `Post exactly as shown`
-- `Edit before posting`
-- `Do not reply`
+- `Publish the grouped plan`
+- `Edit a draft`
+- `Cancel publication`
 
-Only the first choice authorizes posting that exact draft. If edited, show the
-new exact text and ask again. Reaction approval never authorizes a reply.
+If edited, show the new exact text and ask for approval of that draft before
+the grouped publish confirmation. Reaction approval never authorizes a reply
+unless the exact draft is included in the confirmed plan. A `Defer` or
+`Reject` decision may intentionally have no reply.
 
-After exact-text approval, use the review-comment reply command in
+After grouped approval, use the reaction and review-comment reply commands in
 [`gh-commands.md`](gh-commands.md).
 
 Never use a general PR comment endpoint and never resolve or unresolve threads.

plugins/engineering-skills/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "engineering-skills",
   "description": "AI Skills for engineering workflows: triage unresolved pull-request review comments and draft approval-gated replies.",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "author": {
     "name": "kin0992"
   },

plugins/engineering-skills/.github/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "engineering-skills",
   "description": "AI Skills for engineering workflows: triage unresolved pull-request review comments and draft approval-gated replies.",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "author": {
     "name": "kin0992"
   },