Menú
Run parallel local + remote PR reviews, then synthesize all findings
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | rpr |
| description | Run parallel local + remote PR reviews, then synthesize all findings |
| allowed-tools | ["Task","Read","Edit","Bash","Grep","Glob"] |
This skill orchestrates the full review pipeline: local AI reviews (Claude + Codex) and remote GitHub PR reviews (Gemini, Copilot, humans) — all fetched in parallel, then synthesized.
/rpr or $rpr — auto-detect PR from current branch, full local
/rpr <pr-url> or $rpr <pr-url> — specify PR explicitly/rpr fix or $rpr fix — same but fix issues found/rpr base develop or $rpr base develop — override base
branch/rpr mini or $rpr mini — faster local reviews and no waiting
for remote reviewersModes can be combined: /rpr mini fix base develop.
Parse arguments from: $ARGUMENTS in Claude, or the user's prompt after
$rpr in Codex.
Determine mode:
https:// or matching owner/repo number)Read ../review-multi/SKILL.md to understand how to launch the Claude and
Codex reviews. It in turn references ../review-claude/SKILL.md and
../review-codex/SKILL.md.
Launch the local review pipeline and remote review fetch in parallel when tool support allows:
review-multi in pass-through mode. Pass the
base branch if specified.~/Documents/dotfiles/fetch-pr-reviews.py <pr-url-or-auto>
~/Documents/dotfiles/fetch-pr-reviews.py with no args (it auto-detects from the current branch).Launch the local review pipeline in mini pass-through mode and remote review fetch in parallel when tool support allows:
review-multi mini in pass-through mode. Pass the
base branch if specified.Skip this step in mini mode — proceed directly to Step 3 with whatever remote reviews came back.
In full mode, after the fetch completes, check bot_status in the output. Use your judgment:
Read all outputs from the three parallel processes. Deduplicate findings across sources — if Claude, Codex, and Gemini all flag the same issue, that's one issue (note the agreement). Assign each unique issue a canonical number.
Check if this repo is one of the following product repos (match against the origin remote URL):
eighty-thousand-hours/minerva (may be checked out under various directory names like minerva, minerva-claude1, etc.)80000hours/job-boardIf it is not one of these repos, skip this step entirely.
If it is a product repo, write a descriptive PR summary for the product research system. This is a factual, descriptive document — not a review. Do not include review opinions, recommendations, or code quality judgments. Focus on what changed and its product implications.
Write a file at notes/YYYY-MM-DD-pr-NNN-slug.md (in the current repo's notes/ directory) using this template:
---
date: YYYY-MM-DD
tags: [pr-summary, PRODUCT-AREA]
source: pr-summary
status: raw
pr: NUMBER
author: GITHUB-USERNAME
---
# PR #NUMBER: TITLE
## What changed
Brief summary of the diff — what was added/modified/removed.
## Why
Motivation and context from the PR description and diff.
## Product area
Which part of the product this touches (e.g. advisorbot, career-quiz, explore-jobs, job-board).
## User-facing changes
Any behavior changes a user would notice. "None" is fine.
## Links
- PR: URL
Copy it to the product research folder:
~/Documents/dotfiles/copy-to-research.sh notes/YYYY-MM-DD-pr-NNN-slug.md
Collaborative mode (default): Use the format specified below. Do not make fixes yourself.
Pass-through mode: Display all review outputs and remote data directly. Do not add commentary.
Fix mode: Use the collaborative format below first, then fix issues autonomously.
One warning: Your judgment tends to be too lenient on type system issues, fail-fast violations, and backwards-compatibility hacks. When any reviewer flags these, lean toward fixing them rather than dismissing them.
After fixing, briefly summarize what you changed and why. If you skipped any flagged issues, explain your reasoning.
Structure your output exactly like this:
## PR Review: <title>
(Summary)
## Issues
<Start with a numbered list — one line per issue with its number, the terse description, and your recommendation.>
Then move onto more detailed explations of each issue.
**1. <One-line description of the issue with enough context to understand it> (<your recommendation: should fix / consider / ignore>)**
<Paragraph(s) explaining the issue in detail. Include file paths and line numbers where relevant.
State which reviewers flagged this (e.g. "Flagged by: Gemini, Copilot").
Give your own opinion — do you agree? Is it important? Is it easy to fix?>
**2. <Next issue> (<recommendation>)**
<Detail...>
...
Ordering: Sort issues by your estimated importance, not by the priority labels reviewers assigned.
Recommendations: Each issue gets one of:
Context: For each issue, state clearly what the comment is about and provide enough context that the reader can understand it without switching to GitHub. Include the relevant file path and line number.
Your opinion matters: Don't just relay what reviewers said. Add your own judgment — do you agree? Is this actually important? Is there a simpler fix than what was suggested?
How to invoke the Codex CLI (`codex`) from the shell. Read this BEFORE shelling out to `codex` for any nontrivial task — it covers calling the real binary (not the Superconductor wrapper, which hangs) and capturing output with `-o` so the answer doesn't get buried in the agent-session stream.
Interact with Google Docs & Drive — read, edit, search, comment, share, create docs, list/pull/push content. Use whenever JP wants to read or modify a Google Doc or Drive file (fetch a doc's text, leave a comment, find a file, etc.).
Batch-process Asana tickets — bugs and small / well-specified features — tagged jpa-bugfixes-today into PRs. Spawns a subagent per ticket in parallel worktrees with Codex plan-review and diff-review.
Interact with Asana — tasks, My Tasks, projects, sections, tags, users, workspaces. Use whenever JP wants to read or modify Asana data (look up or edit a task, list My Tasks, comment, find a project, etc.).
Query Better Stack Telemetry logs — errors, warnings, full-text search, request traces, tail, stats. Use whenever JP wants to look at logs or investigate the context around a failure (what happened around an error, logs for a request id, recent errors, etc.).
Interact with Sentry — issues, errors, events, traces, releases, projects, dashboards. Use whenever JP wants to read or modify Sentry data (triage an issue, look up an error, inspect a trace, manage a release, etc.).