range-review

範囲レビュー: git 範囲「$ARGUMENTS」に含まれる全 PR の diff を 1 つの単位として、3 視点の読み取り専用 agent で並列レビューし、finding をオーガナイザーが一次ソースで再現してから disposition 案を出す。

このスキルは複数 PR のウェーブ（1 リリース分、または 1 セッション分）が main にマージされた直後に呼び出すことを想定している。per-PR レビューは「その PR 単独で正しいか」しか見ず、同じ範囲の複数 PR が同じ関数・同じ概念を触った結果の相互作用や、複数 PR を跨いで初めて実態と食い違う公開契約の文言は素通りする。本コマンドは issue も PR も作らない。案を出すところで止め、実行はオーガナイザーがユーザー確認のうえ行う。

引数

• <from>..<to> の git 範囲（例: c4453812..3ac089e1）
• 省略時の既定は「1 つ前の release commit → HEAD」。次で求める:

git log --grep='chore(main): release' -2 --format='%h %s'

出力の 2 行目（1 つ前の release）を <from>、HEAD を <to> にする。HEAD 自体が release commit なら、そのリリースに含まれた PR 群をレビューすることになる（1 行目が HEAD と一致する場合も 2 行目を <from> にすればよい）。release commit が 1 件しか無い場合はユーザーに範囲を明示するよう求めて終了する。

手順

Step 1. 範囲の確定と要約

git log --oneline <from>..<to>
git diff --stat <from>..<to>
git log --format='%s' <from>..<to> | grep -oE '\(#[0-9]+\)$' | tr -d '(#)' | sort -n | uniq

• 1 つ目が空なら「範囲が空」と報告して終了する
• 3 つ目で PR 番号を列挙する。squash merge の subject 末尾 (#N) から取るため、それ以外の形式の commit は git log の目視で補う
• 列挙した PR ごとに gh pr view <N> --json title,body --jq '.title' で題名を控える。Step 2 のプロンプトに PR 番号と題名の一覧、git diff --stat の出力、範囲文字列をそのまま貼る

Step 2. 3 視点の並列レビュー

Agent ツールで 3 本を 1 メッセージで同時に起動する。subagent_type: general-purpose、全て読み取り専用の指示で走らせる。各 agent に渡すプロンプトは、下の「共通規律」ブロックの後ろに視点別ブロックを 1 つ足したものである。共通規律は 3 本とも省略せず全文入れる。

共通規律（3 本すべてのプロンプト冒頭に貼る）

あなたは読み取り専用のレビュー agent です。対象リポジトリ: <repo path>（作業ツリーを書き換えない）。
レビュー対象: git 範囲 <from>..<to>。含まれる PR: <PR 番号と題名の一覧>。
差分の概要:
<git diff --stat の出力>

## 規律（厳守）
1. 主張は実測で裏付ける。指摘には必ず `file:line`（<to> 時点の内容）を書き、コマンドを実行したなら exit code を転記する。
   パイプ越しの `$?` は末尾コマンド（`tail` 等）の値なので、exit code を測るときはパイプを外す。
2. CLI（`node src/cli.mjs` / `river`）を実行するときは、必ず `mktemp -d` で作った使い捨て git repo の中で行う。
   `skills import` / `feedback add` / `suppression add` は作業ツリーへファイルを書くため、対象リポジトリ内で実行してはならない。
   使い捨て repo の作り方: `d=$(mktemp -d) && cd "$d" && git init -q && git commit -q --allow-empty -m init`
3. 変異注入（既存テストの検出力を測るために実装を一時的に壊す）を行う場合は、
   `git worktree add --detach <mktemp -d の path> <to>` で自分専用の worktree を作り、その中だけで行う。
   終了前に `git worktree remove --force <path>` で必ず消す。対象リポジトリ本体の作業ツリーには一切触れない。
   その worktree で `npm test` や `npm run build:action` を走らせるなら、`node_modules` は
   **その worktree の中で `npm ci` して用意する**。対象リポジトリの `node_modules` を symlink してはならない。
   親の `node_modules` はレビュー対象の版の lockfile と一致している保証が無く、`npm run build:action` の
   出力が committed dist とズレて「dist が再現しない」という偽の finding になる（2026-09-07、v1.104.0 の
   範囲レビューで視点 B が major として報告し、隔離 worktree の `npm ci` 後は
   `git diff --exit-code runners/github-action/dist/` が exit 0 で再現したため反証した）。
4. 破棄系 git コマンド（`reset --hard` / `checkout -- <file>` / `clean` / `stash drop` / `push --force`）と `rm -rf` を対象リポジトリで実行しない。
5. 修正は提案に留める。ファイル編集・commit・push・issue / PR コメントの投稿を行わない。
6. 差分に無いコードへの推測、一般論だけの指摘、範囲の目的と無関係な指摘は書かない。
7. 出力は 1500 tokens 以内。次の 3 節で構成する:
   - 判定: PASS / FINDINGS（blocker・major・minor の件数）
   - finding: 1 件ごとに「重大度 / file:line / 再現手順（実行したコマンドと出力の要点、exit code）/ 提案」
   - no-finding の根拠: 調べたが問題なしと判断した箇所を、確認方法つきで箇条書き
8. 途中で副作用（意図しない書き込み、前提の誤り）を起こしたら、隠さず出力末尾の「規律違反の自己申告」に書く。