Review PR Threads

2. Handle each thread

For each unresolved thread:

1. Assess the comment(s) and decide whether a code change is warranted, in scope, and clearly correct.

2. Needs a fix → edit the code, then verify with the delegated skills — /lint, /build, /test (and /integration-test if it could affect live-API behaviour); those run in Haiku subagents so logs stay out of context. Commit with a gitmoji message and record the commit SHA. Batch the sweep's pushes: commit per fix, but git push once after all threads are handled (§3), so one review/CI cycle is triggered per sweep, not one per thread.

3. No fix warranted (disagree / out of scope / a question / already done) → make no code change; you'll say why in the reply. When the reason is out of scope and the reviewer's point is sound, file it per .github/ISSUE_FILING.md and reply with the issue number. "Out of scope" with nothing behind it is how a valid review comment gets closed forever; a link is what makes it a deferral rather than a dismissal.

4. Reply on the thread — what you assessed and whether you fixed it (include the commit SHA when you did). Use mcp__github__add_reply_to_pull_request_comment (owner/repo from origin, pullNumber: <n>, body, and commentId — the number from the thread's first comment's html_url anchor, …#discussion_r<ID>; the number only, never the PRRT_… node id). On a 401/403, or if no comment in the thread carries the anchor, fall back to the GraphQL reply with the thread node id we already have from §1:

   gh api graphql -f query='mutation($id:ID!,$body:String!){
     addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:$id,body:$body}){ comment{ id } }
   }' -f id=<THREAD_ID> -f body='<your feedback>'

5. Resolve the thread with mcp__github__pull_request_review_write method resolve_thread (threadId: <PRRT_… node id>; owner/repo/pullNumber are ignored for this method). Resolving an already-resolved thread is a no-op.

6. Record the thread ID and topic signature in the ledger.

Reply and resolve after the single push (§3) for threads you fixed, so the SHA you cite is on the remote. Reply/resolve reply-only threads immediately.

3. Push once, then finish

After every thread is handled, if you committed any fixes, git push once (it re-triggers CI and the claude-review bot — expected). Then post the deferred replies + resolves for the fixed threads.

There is no pre-commit hook (.git/hooks/ holds only *.sample), so nothing lints on your behalf — run /lint before committing.

Guardrails

• Never edit .github/workflows/* or other CI/config to silence a reviewer, and never force-push, without surfacing to the user first.
• If a requested change is ambiguous or risky, reply with your assessment and leave it for the user (note it in the summary) rather than guessing.
• Stay in scope: address the thread, don't opportunistically refactor around it.

Return: sweep summary

Report, concisely:

• Fixed — thread topic → commit SHA, per fixed thread.
• Replied-only — thread topic → one-line reason (disagreed / out of scope / already done / question answered).
• Left for the user — ambiguous/risky threads you replied on but did not act on, and why.
• Counts — threads handled this sweep, and any that remain unresolved (e.g. a thread you intentionally left open for a human decision).

Whether anything was pushed (and the resulting CI/review re-trigger) so the caller can decide whether to sweep again.

Arguments: $ARGUMENTS