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.
>
>
>
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.
>-
Research a codebase and create architectural documentation describing how features or systems work. Use when the user asks to: (1) Document how a feature works, (2) Create an architecture overview, (3) Explain code structure for onboarding or knowledge transfer, (4) Research and describe a system's design. Produces markdown documents with Mermaid diagrams and stable code references suitable for humans and AI agents.