القائمة
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