pi-pr-review 1.4.0 → 1.5.0

package/README.md

@@ -216,6 +216,7 @@ pi-pr-review/
 - The `review_subagents` batch tool and `review_subagent` fallback spawn isolated `pi` subprocesses (`--mode json -p --no-session`) on your configured tier models. Reviewer prompts prohibit modifications, but a configured allowlist containing `bash` is not technically read-only; use a narrower allowlist if stronger enforcement is required.
 - Project-local `pr-review.json` is only read when the project is trusted. Because project `autoPostReviews: true` causes writes under your authenticated `gh` identity, the effective setting and source are surfaced when publication occurs.
 - GitHub publication uses `gh` only, verifies the current identity and PR head, checks paginated formal reviews and legacy comments for same-head markers, and hardcodes `event: COMMENT`. Ambiguous transport failures are reconciled once and never blindly retried.
+- **`gh api -f` caution:** `gh api ... -f body=@/tmp/file.md` posts the literal text `@/tmp/file.md`; unlike `gh pr comment --body-file`, `-f` does not expand `@file`. Use a JSON payload via `gh api ... --input -` for API requests. The built-in publisher already does this.
 - Tiered review calls multiple models per PR, concurrently for independent passes. Point `light` at a cheap model for overview/risk scan; reserve `heavy` for deep passes, and configure per-tier `fallbacks` only for acceptable backup models because retries can increase cost.
 
 ## Design notes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-pr-review",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "Model-agnostic GitHub PR code review prompt for pi. Pass a PR number; it derives the base and head branches from the PR in the current repo, reviews the diff, and returns structured JSON findings.",
   "keywords": [
     "pi-package",

package/prompts/pr-review.md

@@ -49,6 +49,7 @@ Arguments for this run: `$@`
 
 - All tools are functional. Do not test tools or make exploratory/throwaway calls. Every tool call must have a clear purpose.
 - Use the `gh` CLI (already authenticated) for all GitHub access. Do **not** use web fetch. `gh` auto-detects the repo from the current directory's git remote, so run commands from the cwd.
+- **`gh api -f` file-body trap:** `gh api ... -f body=@/tmp/file.md` does **not** read that file; it sends the literal string `@/tmp/file.md`. Never use `-f body=@file` for review/comment content. For an API request, construct JSON with the file contents and pipe it through `gh api ... --input -`; for a standalone PR issue comment, use `gh pr comment --body-file /tmp/file.md`. The extension-owned review publisher already uses JSON on stdin—do not replace it with `-f body=@file`.
 - Read what you need to review thoroughly: the diff is the primary artifact, but open surrounding files, callers, and convention files whenever it improves the review or lets you confirm a finding.
 - **Never disturb the user's working tree.** Do not `git checkout`/`gh pr checkout`, do not modify tracked files, do not commit or push. Any verification happens in an isolated worktree (Step 6).
 - Create a short todo list before you start, then work the steps in order.