dev-pr-review

Reviews open GitHub pull requests in a worktree and merges, fixes, labels, or closes them.

Updated Jun 28, 2026
One-click install
npx skills add https://github.com/Cohey0727/CodingAgentTools --skill dev-pr-review-cohey0727
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-pr-review
Source: https://github.com/Cohey0727/CodingAgentTools/tree/main/skills/dev-pr-review
Command: npx skills add https://github.com/Cohey0727/CodingAgentTools --skill dev-pr-review-cohey0727

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing open pull requests manually is slow and error-prone: reviewers skip CI checks, judge from diffs alone, forget to update labels, and leave linked issues orphaned when closing PRs. This Skill automates the full review loop with consistent rules. ## Core Features & Use Cases - Queue-based PR selection: Picks the oldest open PR without in-review or reviewed labels, and immediately applies in-review to prevent duplicate reviews across sessions. - Worktree-based review: Checks out the PR into a git worktree, verifies CI results via gh pr checks, runs tests, and greps call sites of changed symbols for consistency. - Four-way verdict: Merges clean PRs, fixes trivial issues and merges, requests changes with file-and-line feedback plus a reviewed label, or closes off-target PRs while resetting the linked issue's WIP label. - Use Case: Say "レビュー待ちPRを処理して" and the Skill picks the oldest pending PR, reviews it against its linked issue, and merges it or leaves actionable feedback. ## Quick Start Ask the agent to process the pending review queue by saying "レビュー待ちのPRを処理して" or pass a specific PR number to review it directly.

Frequently Asked Questions about dev-pr-review

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

FAQPage Schema
How do I automatically review open GitHub pull requests?▼

Invoke the Skill with no arguments to select the oldest open PR lacking in-review and reviewed labels. It checks out the PR in a git worktree, verifies CI, runs tests, and then merges, fixes, requests changes, or closes it.

How does the Skill prevent duplicate PR reviews?▼

It applies an in-review label as the very first action, before fetching PR data or creating a worktree. PRs already carrying in-review are skipped, even when explicitly specified by argument, since another process is reviewing them.

Does the review use the actual PR code or just the diff?▼

It always checks out the PR branch into a git worktree and reviews the real code, never the diff alone. It also greps call sites of changed symbols and runs the test suite inside the worktree before merging.

What happens to linked issues when a PR is closed?▼

The Skill inspects closingIssuesReferences and either closes the issue with evidence if main already resolves it, or removes the issue's WIP label to return it to the implementation queue. Issues are never left orphaned.

When does the Skill fix a PR instead of requesting changes?▼

Only for trivial issues like typos, naming, small edge cases, or missing tests that do not affect design. It commits the fix in conventional commit format, re-runs tests, pushes, and merges; anything larger becomes a request-changes review.

What happens if a review is interrupted or fails midway?▼

The Skill always removes the in-review label before reporting the failure. This guarantees the PR returns to the reviewable queue instead of being permanently skipped by future review runs.