메뉴
Review a GitHub PR locally using metadata and diff as context. Use when asked to review a pull request, check a PR, or analyze a PR. Outputs findings to terminal only — never posts GitHub comments.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | pr-review |
| description | Review a GitHub PR locally using metadata and diff as context. Use when asked to review a pull request, check a PR, or analyze a PR. Outputs findings to terminal only — never posts GitHub comments. |
| argument-hint | <PR_NUMBER> [--repo owner/repo] [--prompt "custom instructions"] |
| allowed-tools | Bash(gh pr view:*), Bash(gh pr diff:*) |
Review a GitHub pull request locally using both its metadata and diff as context. Output all findings to the terminal only. Do not post any comments to GitHub.
Identify the PR and options:
$ARGUMENTS:
--repo <owner/repo> if provided (pass as --repo flag to gh commands)--prompt <text> if provided (use as custom review focus)Fetch PR metadata using:
gh pr view <PR_NUMBER> [--repo <owner/repo>] --json title,body,labels,comments,author,additions,deletions,changedFiles
Fetch PR diff using:
gh pr diff <PR_NUMBER> [--repo <owner/repo>]
Review the PR using both the metadata and the diff:
Output findings to terminal covering:
If a custom --prompt was provided, focus the review on that instruction instead.
Do not post any GitHub comments, use gh pr comment, or call any GitHub write APIs.
## PR #<NUMBER> Review: <title>
**Author**: ... **Changes**: +X / -Y across N files
### Summary
<brief overall assessment>
### Findings
1. [SEVERITY] <finding> — <file>:<line if known>
<explanation>
...
No issues found. ✓ (if nothing to report)
Severity levels: [BUG] [SECURITY] [INTENT MISMATCH] [QUALITY]
Design or refine an Apache Pulsar PIP (Pulsar Improvement Proposal) from a draft into a votable, minimal, 5-year-durable proposal. Runs multi-model multi-viewpoint reviews, an iterative minimalism-refinement loop to a fixpoint, and (when the PIP has a reference implementation) the full design-doc + code + CI pipeline. Use when asked to design a PIP, review/harden a PIP draft, or drive a proposal to "nothing left to take away."
Cherry-pick (backport) one or more apache/pulsar commits onto a release/maintenance branch, resolving conflicts and adapting for branch differences. Use this whenever the user asks to cherry-pick, backport, port, or "apply commit X to branch Y" — especially when porting commits from master to an older release branch (branch-4.0/4.1/4.2/3.x etc.), where the logging framework (slog vs slf4j) and build system (Gradle vs Maven) differ and naive cherry-picks fail to compile.
Investigate test failures for a project using the Develocity REST API. Queries failed builds, extracts test and build failures with stacktraces.
Fix flaky tests in apache/pulsar. Investigates Develocity failures, analyzes root causes using git blame, fixes tests, verifies with invocationCount, and creates PRs.
Investigate failing GitHub Actions CI tests for a PR, a specific workflow run (by URL), or recent workflow runs. Auto-detects Maven vs Gradle for the target branch and parses failures in the right format. Downloads logs and optionally test report artifacts for deep analysis.
Create a pull request to apache/pulsar