reply-to-pr-threads
# Reply to PR Threads This Claude Code skill drafts, confirms, and posts replies to GitHub pull request review threads. It re-fetches thread resolution state to skip auto-resolved threads, applies voice rules via the `/github-voice` skill, and formats replies by category (fix, skip, answer, clarify) before posting via GraphQL. Use it when asked to reply to PR threads, post PR thread replies, or draft PR reply messages for a pull request.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/reply-to-pr-threads && cp -r /tmp/reply-to-pr-threads/claude/skills/reply-to-pr-threads ~/.claude/skills/reply-to-pr-threadsSKILL.md
# Reply to PR Threads
Draft replies for a processed review-thread list, confirm with the user, and post the surviving drafts.
## Step 1: Run `/github-voice` Skill
Run the `/github-voice` skill to load voice rules and the insider-vs-outsider detection.
## Step 2: Re-fetch Thread State
Auto-detect owner, repo, and PR number from the current branch if not provided, then query the current resolution state:
```bash
gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $pr) {
reviewThreads(first: 100) {
nodes { id isResolved }
}
}
}
}' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
```
Drop threads whose `isResolved` is now true. Reviewers or bots such as CodeRabbit may resolve threads after the original fetch, and drafting replies for them is wasted work.
## Step 3: Draft Replies
Use the processed-thread list from conversation context. Each entry has: thread id, file path, line, category (`fix`, `skip`, `answer`, or `clarify`), and per-category payload.
Keep every reply to one or two sentences. No bullet-point reasoning. No bolded labels.
**fix**: payload is a commit SHA, optionally with a divergence note.
```
Fixed in <commit-sha>.
```
Only add a brief sentence after the SHA when the fix meaningfully diverges from what the reviewer suggested. Otherwise the SHA alone is enough.
**skip**: payload is the skip reasoning. State the reasoning directly. Do not apologize or hedge.
**answer**: payload is raw answer text from `/answer-reviewer-questions`. Tighten to one or two sentences and apply `/github-voice` rules (no em dashes, natural tone). Do not cite transcripts or mention Claude. The reply reads as the implementer's own explanation.
**clarify**: payload is a user-directed question. Draft it as directed.
## Step 4: Present Drafts and Confirm
Output all drafts as text, grouped by file:
```
### <file-path>
**Thread <id>** (<category>, line <line>)
Reviewer: <original comment, truncated if long>
Reply: <drafted reply>
```
Then use `AskUserQuestion` to ask whether to post. Offer:
- **Post** — post all drafts as shown
- **Cancel** — skip posting
## Step 5: Post Replies
For each approved draft, write the drafted reply to `.turbo/pr/thread-<thread-id>.md` with the Write tool, then post via the reply mutation:
```bash
gh api graphql -f query='
mutation($threadId: ID!, $body: String!) {
addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: $threadId, body: $body}) {
comment { id }
}
}' -f threadId='<thread-id>' -F body=@.turbo/pr/thread-<thread-id>.md
```
Substitute `<thread-id>` with the thread's id for each post. Report what was posted and what was skipped (due to auto-resolution between re-fetch and posting).
Then use the TaskList tool and proceed to any remaining task.
## Rules
- Never resolve or dismiss a review thread. Only reply. Let the reviewer resolve.
- If a post mutation fails because the thread is already resolved, log the skip and continue with the rest.For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\".
Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.
Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".
Shared commit message rules and technical constraints referenced by $stage-commit and $commit-staged. Not typically invoked directly.