pr-threads-address
This Claude Code skill automates the process of addressing pull request review feedback by retrieving all unresolved review threads, analyzing each comment, implementing the requested code changes with tests, committing them with conventional commit messages, and then optionally replying to and resolving each thread. Use it when you have an open PR with multiple review comments and need to systematically work through all feedback before merging.
git clone --depth 1 https://github.com/posit-dev/skills /tmp/pr-threads-address && cp -r /tmp/pr-threads-address/github/pr-threads-address ~/.claude/skills/pr-threads-addressSKILL.md
## Prerequisites ### gh pr-review extension Before using this command, check if the gh pr-review extension is installed: ```bash gh extension list | grep -q pr-review || gh extension install agynio/gh-pr-review ``` ### Resolve PR context Every `gh pr-review` subcommand requires both `--pr <number>` and `--repo <owner/repo>` — do not omit either. Look the values up once at the start of the workflow and substitute the literal numbers and slugs into every later command. Get the PR number for the current branch: ```bash gh pr view --json number -q .number ``` Get the repository slug: ```bash gh repo view --json nameWithOwner -q .nameWithOwner ``` Then pass the resulting values directly — e.g. `--pr 42 --repo posit-dev/skills` — on every subsequent `gh pr-review` call in this workflow (review view, comments reply, threads resolve, etc.). ## Workflow 1. Fetch and display all unresolved PR review threads 2. Analyze each thread to understand the requested changes 3. For each thread: 1. Make the necessary code modifications 2. (When possible) Add unit tests to verify the change 3. Commit the changes with descriptive commit messages using conventional commit specification 4. Report back with a summary of addressed threads 5. Ask if the user wants to resolve the threads. If so, reply to each thread indicating what was done and then resolve the thread. ## CLI Reference ### View PR Reviews and Comments Display all reviews, inline comments, and replies for a pull request: ```bash gh pr-review review view --pr <number> --repo <owner/repo> ``` **Common filters:** - `--reviewer <login>` — Filter by specific reviewer - `--states <list>` — Comma-separated review states (APPROVED, CHANGES_REQUESTED, COMMENTED, DISMISSED) - `--unresolved` — Show only unresolved threads - `--tail <n>` — Show only the last n replies per thread - `--include-comment-node-id` — Include GraphQL node IDs for replies ### Reply to Review Threads ```bash gh pr-review comments reply --thread-id <PRRT_...> --body "<reply-text>" --repo <owner/repo> --pr <number> ``` For multi-line replies, pass `--body "$(cat <<'EOF' ... EOF\n)"` heredoc syntax. ### Resolve a Thread ```bash gh pr-review threads resolve --thread-id <PRRT_...> --pr <number> --repo <owner/repo> ``` Thread IDs (format `PRRT_...`) come from `review view --include-comment-node-id`.
>
Create and use brand.yml files for consistent branding across Shiny apps and Quarto documents. Covers: (1) Creating new _brand.yml files, (2) Applying to Shiny (R and Python), (3) Using in Quarto, (4) Modifying existing files, and (5) Troubleshooting. Includes complete specifications and integration guides.
Write ggsql queries — a grammar of graphics for SQL. Use when the user wants to create, modify, or understand a ggsql visualization query.
Creates a pull request from current changes, monitors GitHub CI, and debugs any failures until CI passes. Activate when the user says "create pr", "make a pr", "open pull request", "submit pr", "pr for these changes", or wants to get their current work into a reviewable PR. Assumes the project uses git, is hosted on GitHub, and has GitHub Actions CI with automated checks (lint, build, tests, etc.). Does NOT merge - stops when CI passes and provides the PR link.
Bulk resolve unresolved PR review threads on the current branch’s PR — typically after threads have been addressed manually or via /pr-threads-address
>
Guide for drafting issue closure and decline responses as an open-source package maintainer. Use when helping compose a reply that says \"no\" to a feature request, closes an issue as won't-fix, redirects a user to a different package, explains why a design choice is intentional, or otherwise declines or closes a community contribution. Also use when the maintainer needs to explain a deprecation, point out a user misunderstanding, or communicate an effort/scope tradeoff to a contributor.
>