re-review-pr

Re-run focused PR reviews after fixes using GitHub CLI and GraphQL API.

3|Updated Jul 13, 2020
One-click install
npx skills add https://github.com/nieomylnieja/dotfiles --skill re-review-pr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: re-review-pr
Source: https://github.com/nieomylnieja/dotfiles/tree/main/config/agents/skills/re-review-pr
Command: npx skills add https://github.com/nieomylnieja/dotfiles --skill re-review-pr

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires gh, jq, git, and includes scripts (resource) components.

What problem does it solve?

PR reviews often become noisy after fixes; this skill loads prior findings, fetches GitHub thread states, and performs a fresh, unbiased re-review to distinguish new issues from resolved ones.

Core Features & Use Cases

  • Load previous review findings and identified issues
  • Fetch and classify GitHub review threads (open vs resolved)
  • Run a fresh, unbiased re-review and surface actionable findings

Quick Start

Trigger on a PR and let the skill orchestrate loading prior reviews, fetching threads, and performing a fresh unbiased re-review.

Frequently Asked Questions about re-review-pr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate a second-pass PR review after fixes are pushed?

Automate a second-pass PR review by loading previous findings, fetching GitHub thread states, and running a fresh unbiased re-review to distinguish new issues from resolved ones.

Why does my GitHub code review become noisy after updated commits?

GitHub code review threads become noisy after updated commits because prior findings mix with new changes. This skill resolves this by classifying open versus resolved threads and surfacing only actionable findings.

Do I need the GitHub CLI to re-run a focused PR review?

Yes, you need the GitHub CLI and GraphQL API via gh, the local repository context, jq, git, and the included scripts to query GitHub threads and perform a fresh unbiased re-review.

What is the best way to track resolved versus open code review threads on GitHub?

Track resolved versus open code review threads by fetching and classifying GitHub thread states using the gh CLI. This approach queries current thread statuses and compares them against loaded prior review findings.

Can I load previous PR review findings and compare them with a fresh re-review?

Yes, you can load previous PR review findings using the find-review-file.sh script, fetch live thread states with get-all-review-threads.sh, and run a fresh unbiased re-review to identify newly introduced issues.