.pi/skills/review-roulette/SKILL.md
Dispatch a review task to 3 randomly-selected reasoning models in parallel for diverse perspectives, then merge all suggestions into a single result.
npx skillsauth add in-the-loop-labs/pair-review review-rouletteInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
When this skill is active, your ONLY job is orchestration — you do NOT perform any review analysis yourself. You randomly select 3 reasoning models, dispatch the review to all of them in parallel, and merge the results.
Run ${PI_CMD:-pi} --list-models via bash to get the current list of models with
valid API keys. Eligible models are those that show thinking: yes in the
output — these are the reasoning-capable / premium models.
Excluded models: Never select openai/o3-pro — it is prohibitively
expensive. If it appears in the model list, skip it entirely.
Example reasoning models you might see (provider/model format):
anthropic/claude-opus-4-6anthropic/claude-sonnet-4-5 (with thinking)openai/o3openai/o4-miniopenai/gpt-5-proopenai/gpt-5.2-progoogle/gemini-2.5-pro (with thinking)google/gemini-2.5-flash (with thinking)google/gemini-3.1-pro-previewxai/grok-4The exact list depends on which API keys are configured. Always check — do not assume models are available.
From the eligible reasoning models, pick exactly 3 at random.
CRITICAL — true randomness and diversity:
Use the task tool with the tasks array to dispatch all 3 reviews
simultaneously. Each task object must include:
model: The selected model in provider/model format.task: The FULL original review prompt/instructions. Each subtask
starts fresh with NO conversation history and NO context from the parent.
You must forward EVERYTHING you were asked to do — the complete prompt, all
instructions, the diff, file contents, any constraints or formatting
requirements, the expected JSON output schema, etc. Do not summarize or
abbreviate. Pass it all through verbatim.Example structure:
{
"tasks": [
{
"task": "<the ENTIRE original review prompt and instructions>",
"model": "anthropic/claude-opus-4-6"
},
{
"task": "<the ENTIRE original review prompt and instructions>",
"model": "openai/o3"
},
{
"task": "<the ENTIRE original review prompt and instructions>",
"model": "google/gemini-2.5-pro"
}
]
}
Each subtask will return a review result containing a summary string and a
suggestions array (the standard review JSON format).
Collect the results from all 3 subtask responses and merge them:
Suggestions: Concatenate all suggestions arrays into a single array.
Summary: Concatenate all summaries with model attribution. Format the merged summary as:
<provider/model1>:
<summary1>
<provider/model2>:
<summary2>
<provider/model3>:
<summary3>
This attributed format also serves as a record of which models were used in the review.
Return the merged result as the final JSON response.
Do NOT:
Do:
[...model1, ...model2, ...model3]provider/model: attribution as shown aboveYou (parent) Subtask 1 (model A)
│ │
├── pick 3 random models ├── receive full prompt
├── forward full prompt ──────► ├── perform review
│ └── return suggestions JSON
│
├── forward full prompt ──────► Subtask 2 (model B) ──► suggestions JSON
│
├── forward full prompt ──────► Subtask 3 (model C) ──► suggestions JSON
│
└── merge all summaries (with model attribution) + suggestions[] ──► final JSON response
The parent does zero analysis. It is purely a dispatcher and merger. Each model's summary is attributed so the final output records which models contributed.
development
Fetch human review comments from pair-review and make code changes to address them. Use when the user says "address review feedback", "fix review comments", "address comments", or wants to iterate on code based on feedback left by a human reviewer in pair-review.
development
Open outstanding GitHub review requests in pair-review for AI-powered code review. Finds open PRs where my review is pending from the past week and starts pair-review analysis for each. Use when the user says "review requests", "review my PRs", "check review requests", "open review requests", "pair-review my requests", or wants to batch-review their outstanding GitHub review requests.
tools
Open the GitHub pull request for the current branch in the pair-review web UI. This only opens the browser — it does not run AI analysis or generate suggestions. Once open, the user can browse the diff, leave comments, and trigger analysis from the web UI themselves. Use when the user says "review this PR", "review pull request", "open PR review", or wants to open a pair-review session for the current branch's pull request. If the user wants automated AI analysis of the PR rather than just opening the browser, use the `code-critic:analyze` skill (standalone, requires code-critic plugin) or `pair-review:analyze` skill (requires MCP server) instead. Note that the user can also trigger AI analysis from within the pair-review web UI after opening it.
tools
Open local uncommitted changes for review in the pair-review web UI. This only opens the browser — it does not run AI analysis or generate suggestions. Once open, the user can browse the diff, leave comments, and trigger analysis from the web UI themselves. Use when the user says "review my local changes", "review local", "open local review", or wants to open a pair-review session for uncommitted work in the current directory. If the user wants automated AI analysis of their local changes rather than just opening the browser, use the `code-critic:analyze` skill (standalone, requires code-critic plugin) or `pair-review:analyze` skill (requires MCP server) instead. Note that the user can also trigger AI analysis from within the pair-review web UI after opening it.