Get a code review from the model configured in pi by running a fresh pi session. The user wants that model's take, not yours — relay it, don't redo it.
Assume pi is installed, its default provider and model are set in ~/.pi/agent/settings.json, and the review-code skill is available to it. Don't probe for any of these — if pi fails, surface the error and stop.
Rules
-
Resolve the target in
review-code's vocabulary. Don't compute the diff yourself.- PR number →
pr <N> - "PR" with no number →
pr <N>for the current branch (gh pr view --json number -q .number) - Ref range (e.g.,
main...HEAD) → verbatim - Otherwise →
diff
- PR number →
-
Pass the user's model verbatim to
--model, or omit--modelif they named none — pi falls back to its configured default. -
Run this from the repo root, substituting target and model:
pi -p \
--model <provider/model> \
--exclude-tools edit,write \
--name "review: <target>" \
"Use the review-code skill to review <target> in this repo. Do not modify any files."
-pprints only the final answer, so the output is safe to read in the main session.--exclude-tools edit,writekeeps the reviewer from "fixing" findings.bashstays on forgitandgh.- Reviews can take several minutes — use the longest allowed timeout or run it in the background.
-
Never resume a session. No
-c,-r,--session,--session-id, or--fork— prior context pollutes the review. -
Never inline the diff in the prompt.
review-coderesolves the target itself, and a large diff breaks shell quoting. -
Relay the review verbatim. Don't summarize, re-rate, or add your own findings.
-
On non-zero exit, print the error and stop. Never fall back to a Claude-side review.
Verification procedure
- The command had no session-reuse flag.
- Every reported finding has a
path:linecitation. If findings lack them, pi likely never loadedreview-code— re-run once, then report. A clean review with no findings needs no citations. - If pi rejects the model, check
pi --list-models <name>and retry with a listed name.