pr-threads-address

$npx mdskill add posit-dev/skills/pr-threads-address

Address unresolved PR review threads by analyzing and committing changes

  • Identify all unresolved PR review threads on the current branch.
  • Use the gh CLI to fetch and display these threads for analysis.
  • Decide which changes are needed based on feedback in each thread.
  • Commit the necessary code changes with tests where applicable.

SKILL.md

.github/skills/pr-threads-addressView on GitHub ↗
---
name: pr-threads-address
description: "Address PR review feedback by systematically working through every unresolved PR review thread on the current branch's PR - analyze each comment, make the requested code changes (with tests where useful), commit, and optionally reply and resolve."
compatibility: Designed for Claude Code; requires gh CLI and gh-pr-review extension
metadata:
  author: Barret Schloerke (@schloerke)
  version: "1.0"
license: MIT
---

## 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`.

More from posit-dev/skills

SkillDescription
alt-text>
brand-ymlCreate 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.
cli>
cran-extrachecks>
create-release-checklist>
critical-code-reviewerConduct rigorous, adversarial code reviews with zero tolerance for mediocrity. Use when users ask to "critically review" my code or a PR, "critique my code", "find issues in my code", or "what's wrong with this code". Identifies security holes, lazy patterns, edge case failures, and bad practices across Python, R, JavaScript/TypeScript, SQL, and front-end code. Scrutinizes error handling, type safety, performance, accessibility, and code quality. Provides structured feedback with severity tiers (Blocking, Required, Suggestions) and specific, actionable recommendations.
describe-designResearch 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.
ggsqlWrite ggsql queries — a grammar of graphics for SQL. Use when the user wants to create, modify, or understand a ggsql visualization query.
implementOrchestrates implementation of a plan file by delegating work to subagents in parallel. Verifies git branch state, tracks progress, and ensures high-quality implementation. Invoke with a plan file path and optional model override: /implement plans/my-plan.md [--model sonnet]
lifecycleGuidance for managing R package lifecycle according to tidyverse principles using the lifecycle package. Use when: (1) Setting up lifecycle infrastructure in a package, (2) Deprecating functions or arguments, (3) Renaming functions or arguments, (4) Superseding functions, (5) Marking functions as experimental, (6) Understanding lifecycle stages (stable, experimental, deprecated, superseded), or (7) Writing deprecation helpers for complex scenarios.