codex/skills/reply-to-pr-threads/SKILL.md
Draft, confirm, and post replies to GitHub PR review threads. Handles per-category reply formatting, re-fetches thread resolution state so auto-resolved threads are skipped, and posts via GraphQL. Use when the user asks to "reply to PR threads", "post PR thread replies", or "draft PR reply messages".
npx skillsauth add tobihagemann/turbo reply-to-pr-threadsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Draft replies for a processed review-thread list, confirm with the user, and post the surviving drafts.
Auto-detect owner, repo, and PR number from the current branch if not provided, then query the current resolution state:
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.
$github-voice SkillRun the $github-voice skill to load voice rules and the insider-vs-outsider detection.
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. 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.
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 request_user_input to ask whether to post. Offer:
For each approved draft, write the drafted reply to .turbo/pr/thread-<thread-id>.md with apply_patch, then post via the reply mutation:
gh api graphql -f query='
mutation($threadId: ID!, $body: String!) {
addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: $threadId, body: $body}) {
comment { id }
}
}' -f threadId='<thread-id>' -F [email protected]/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 call update_plan to mark this step completed and continue with the next step of the active workflow.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".