pr-impact-review

name	pr-impact-review
description	PR・ブランチ差分を「ユーザー価値とプロダクト品質」の観点で、PdMとしてレビューするスキル。「PRをレビューして」「この変更でユーザーに何が起きる？」「ユーザーへの価値はどう変わる？」「イシューの意図に沿ってる？」「これマージして大丈夫？」「PdM目線で見て」「合否を判断して」といったリクエストで使う。codex review や code-review が行レベルのコード品質を見るのに対し、本スキルは「このPRをユーザーに出して良いか」を、価値の増減（プラス/マイナス）・イシューの意図との整合・想定外の変化の3点で評価し、PdMがパッと見で合否判断できる粒度にまとめる。

PR レビュー（PdM視点）

PR / ブランチ差分を、PdM＝ユーザー価値を届けプロダクト品質に責任を持つ立場としてレビューするスキル。

何のためのスキルか（位置づけ）

行レベルのコード品質を見るレビュー（codex review, code-review 等）は「このコードは正しいか」を見る。だがそれだけでは、**「このPRをユーザーに出して良いか」**という判断ができない。

本スキルはそこを担う。コードの正しさは見ない。この変更がマージされたとき、ユーザーが受け取る価値がどう変わるか（良くも悪くも）、それがイシューの狙い通りか、想定外のことが起きていないかを見て、PdM が合否を切れる材料を出す。

codex review / code-review   →  「この行/関数は正しいか」（エンジニア・行レベル品質）
pr-impact-review（本スキル）  →  「これをユーザーに出して良いか」（PdM・価値と品質）

両者は補完関係。コードの正しさも要るなら別途 codex review を回すこと。本スキルはその代替ではない。

いつ使うか

• PR をレビューするとき（自分の / 他人の PR）。特に「マージして良いか」を判断したいとき
• この変更でユーザー価値がどう変わるか（プラス・マイナス）を知りたいとき
• 実装がイシュー / PR に書かれた狙いから外れていないか確かめたいとき
• ユーザーに見える挙動・UI・データが変わる変更のとき

使わなくてよい場面: 内部リファクタのみ・typo・コメントのみなど、ユーザーが受け取る価値が一切変わらない変更（その場合は「ユーザー価値の変化なし」と一言で結論づける）。

手順

Step 0: 差分と「狙い（基準線）」を集める

判定の基準線はイシュー / PR に書かれた狙い。これと実差分を突き合わせるので、両方を必ず手に入れる。

# PR 番号が指定された場合（説明文＝狙いを必ず読む）
gh pr view <PR番号> --json title,body,files,baseRefName,headRefName
gh pr diff <PR番号>

# ローカルブランチ / 未コミット
git fetch origin main
git diff origin/main...HEAD --stat   # まず俯瞰
git diff origin/main...HEAD

# patch ファイル / 差分テキストで渡された場合はそのまま読む

# 関連イシューが参照されていたら本文も取りに行く（基準線の信頼度が上がる）
gh issue view <イシュー番号> --json title,body

押さえること:

• 狙い（基準線）: イシュー / PR 説明 / 関連ドキュメントから「誰の・どんな課題を・どう解決しようとしているか」を1〜2文で。基準線の出どころと信頼度を区別して書く:
  • イシュー本文 / PR 説明で確認できた → そのまま基準線にする
  • コミットメッセージや PR の自己申告しか無い（イシュー本文が非公開等） → 「自己申告の狙い」と明記。後の整合判定は「狙い通りに作れているか」までで、「そもそも解くべき課題と合っているか」は未検証と断る
  • 記載が一切無い → 「狙いの記載なし」と明記し、差分から推測した狙いを括弧書きで添える
• 実差分: ユーザーに見える部分（UI・挙動・レスポンス・出力データ・エラー文言）がどう変わるか。内部実装だけの差分はここでは脇に置く

Step 1: ユーザー価値の変化を読む（中心）

このPRがマージされた後、ユーザーの体験が before → after でどう変わるか。プラスとマイナスの両方を出す。

• ➕ 良くなること: 何ができるようになる / 速くなる / 分かりやすくなる / 手間が減るか。誰にとってかまで
• ➖ 引き換えに失う・負担になること: できなくなる / 戸惑う / 手順が増える / 表示が変わって混乱する、などのトレードオフ。「マイナスなし」なら本当にそうか疑ってから書く
• 👁 ユーザーに染み出す外部仕様: UI・操作フロー・レスポンス時間・出力データ・文言・エラーなど、ユーザーが実際に触れて気づく変化。API/DBスキーマ/CLI 等の対外仕様も、ユーザー体験に染み出す範囲だけを拾う（内部実装の都合は対象外）

詳しい問いかけは references/review-perspectives.md を読む。

Step 2: イシューの意図と照合する

Step 0 の狙い（基準線）と、Step 1 で読んだ実際の価値変化を突き合わせる。

• 狙い通りに価値を届けているか（一致 / 一部ズレ / 別物になっている）
• やりすぎ・やり足りない・狙いと違う方向に進んでいないか
• 狙いに書かれていない価値変化（良い方向にも悪い方向にも）が起きていないか

Step 2.5: 狙いが達成されている時こそ、施策の前提を疑う

「狙い通りに作れている」と判定したら、必ず一度立ち止まって問う: その狙い自体が、ユーザー / プロダクトにとって妥当か。忠実な実装ほどこの問いを飛ばしやすい（＝ラバースタンプ）。「狙い通りに動くか」と「その施策がユーザーに良いか」は別物。

• 狙いを達成する手段が、別のユーザー価値を毀損していないか（例: 転換率↑のため無料ユーザー全員に毎回モーダル割り込み＝体験毀損・ダークパターン寄り）
• 狙い由来のマイナスを「仕様だから」「狙い由来だから」と免責していないか。狙い由来でも、ユーザー不利益が大きければ重大度（references §6）で測り直し、Major 以上なら判定に効かせる
• 事業側のプラス（転換・収益）と特定セグメントのマイナス（無料ユーザーの体験劣化等）が別の主体に分かれるとき、両者を同じ天秤に乗せ「誰の何を犠牲に、誰の何を得ているか」を明示する（詳細: references §7）
• 前提に筋の悪さを感じたら、代替案（頻度上限・条件発火など）を1つ提示し、判定理由と「見ておくべき点」に書く

実装が動くなら強い否ではないが、前提への問いを立てずに手放しの合にするのは誤り。施策の妥当性に疑問があるなら最低でも条件付き合とし、前提への問いを残す。

ただし出口を必ず通る — 疑った結果が妥当なら、短く合にする:

• 前提を疑った結果が業界標準・proportionate（得る価値に対し副作用が釣り合う）なら、それは妥当な前提。難癖をつけて判定を重くしない。標準的なセキュリティ / UX 施策（レート制限・アカウントロック・確認ダイアログ等）に伴う既知のトレードオフ（巻き添え・DoS 余地など）は原則 Minor 扱いとし、軽微論点として「見ておくべき点」に1〜2行添えるに留め、判定は合のままにする（重大度の線引きは references §6 の反例ガード参照）。
• **Step 2.5 は思考プロセスであり、独立セクションとして出力しない。**前提に実害ある問題があった場合のみ「判定」と「見ておくべき点」に反映する。前提が妥当だった場合は出力に痕跡を残さない（＝短い合になる）。代替案の列挙は、判定が条件付き合 / 否のときだけ「見ておくべき点」に1つ添える。

Step 3: 「良い・微妙・想定外」に仕分ける

Step 1〜2 で見えたことを、PdM が判断に使える3区分に整理する。

• 😊 良い: 狙い通り、またはそれ以上のユーザー価値
• 🤔 微妙: トレードオフ・引っかかり・PdM として「ん？」となる点（判断は割れるが直ちに否ではない）。**判定に効くものだけ入れる。**狙いを達成している PR で nice-to-have（あれば良い改善）を並べて膨らませない。軽微な改善余地は「見ておくべき点」に1〜2行で十分。良いPRのレビューは短くなるのが正常。
• ⚠️ 想定外: 意図していないのに起きる、ユーザーが体感できて不利益のある変化・副作用・サイレント仕様変化（ユーザーが気づく挙動が、誰も宣言せず変わった場合）。
  • ⚠️に入れる前に必ず問う: その変化はユーザーが体感するか／不利益があるか。NO なら ⚠️ ではない。
  • 良性の初期化・防御的コード追加・等価な書き換えなど「狙いに無いがユーザー体験を実質変えない／むしろ自然な変更」は、😊良い か「該当なし」に置く。狙いに無い＝想定外、と機械的にラベルしない。

Step 4: 合否サマリにまとめる（PdM がパッと見で判断できる粒度）

**まず1〜2文で「全体像」を置く。**レビュアーは背景を知らない（別チーム・入社直後・このPRが大きな取り組みの一部だと知らない）前提で、「この変更は何で、どの文脈／取り組みのどの部分か」を最初に渡す。これが無いと、読み手は判定も差分も「何を判断させられているのか」が掴めないまま読むことになる。全体像は1〜2文に収める（細部は下のセクションへ。良いPRでここを膨らませない）。

その直後に判定（合 / 条件付き合 / 否）と一言理由を置き、続けてユーザー価値の増減を数行で。PdM がこのサマリだけ見て go/no-go を切れる密度にする。細部は下に。

判定の付け方（狙いの達成度 × 残懸念の重大度） — 懸念の重大度は references の重大度表（Critical/Major/Minor）で測る:

状況	判定
狙いを達成し、残るのは Minor 懸念のみ	合（懸念は「見ておくべき点」に添えるだけ。条件にしない）
狙いは達成だが Major 級の懸念 / スコープ違反 / サイレント仕様変化がある	条件付き合（何を直せば合かを明記）
狙い未達 / Critical / 申告と中身の乖離（リファクタを装った仕様変更など）	否

Minor 懸念を「条件付き」の根拠にしない。nice-to-have を「合否を左右する」と書くのは過剰指摘。狙いを満たし重大懸念がなければ、堂々と合にして短く出す。懸念の数で精度を演出しない。

出力フォーマット

**同じ懸念を複数セクションで繰り返さない。**核心懸念は「判定」または「見ておくべき点」のどちらか1箇所で言い切り、他セクション（整合・仕分け）では再説明せず短く触れるだけにする。同じ趣旨の文がレポート内に2回以上現れたら冗長 — 削る。レポートは PdM が読んでも開発者が読んでも10秒で要点が取れる長さに収める。

## PR レビュー（PdM視点）: [タイトル]

> **全体像**: [この変更は何か / どの文脈・取り組みのどの部分か を1〜2文。背景を知らないレビュアーが「何を見せられているか」を掴める粒度]

### 判定: 【合 / 条件付き合 / 否】
[なぜその判定か。1〜2文。条件付きなら「何を満たせば合か」]

### ユーザー価値の変化（before → after）
- ➕ 良くなる: [誰が・何が]
- ➖ 失う/負担: [誰が・何が]（なければ「目立つマイナスなし」と根拠つきで）
- 👁 ユーザーに見える変化: [UI/挙動/レスポンス/データ/文言...]

### イシューの意図との整合
- 狙い（記載 or 推測）: [...]
- 実際: 【狙い通り / 一部ズレ / 別物】 — [一言]

### 仕分け
| 区分 | 内容 |
|------|------|
| 😊 良い | [...] |
| 🤔 微妙 | [...] |
| ⚠️ 想定外 | [...] |

### PdM が見ておくべき点（あれば）
- [ラベル] 懸念内容

「見ておくべき点」は重大度順に並べ、合否を覆しうるものを先頭に。各項目に [Major]/[要確認]/[計測] 等のラベルを付け、確認事項・計測指標は重要懸念の後ろに回し、最重要が箇条書きに埋もれないようにする。

レビュー結果の出し方（必須）

• **全体像から書く。**いきなり差分の詳細・判定理由・スコープ外リストに入らない。最初の1〜2文で「何の変更か・どの文脈／取り組みのどの部分か」を渡し、背景を知らない人でも以降を追える状態にしてから細部へ降りる
• プラスとマイナスを両方出す。「良いことしかない」「問題なし」で終わらせない。価値の増減は必ずトレードオフの目で見る
• 技術用語で止めない。「キャッシュキーが変わる」ではなく「→ デプロイ直後、一覧を開いた人に古い件数が見える」とユーザーの体験に翻訳する
• **判定（合否）を必ず出す。**観点を埋めただけ・所感だけで終わらせない
• 各区分が空なら「該当なし（理由）」と書く
• **[要確認] に実装の内部挙動（キャッシュ操作の呼び分け・emit 形式・トランザクション境界等）を書くときは、コードの語彙を残さず「ユーザーに何が起きうるか」だけに丸める。**例:「incr/expire/set が別呼び出しで…」→「障害時にロックが効かない / 解けない場合がある（要確認）」。実装の妥当性そのものは codex review に委ね、本スキルでは1行のユーザー影響に翻訳する
• **PdM にも開発者にも伝わる二層に。**技術的事実（開発者が根拠を追える）と、それがユーザーに何を起こすか（PdM が影響を掴める）の両方を、短く併記する

やりがちな失敗

失敗	どうするか
行レベルのコード指摘に終始する	それは codex review の仕事。本スキルはユーザー価値とプロダクト品質を見る
マイナス / トレードオフを書かない	価値が変わる以上、引き換えは必ず疑う。本当に無いなら根拠を書く
イシューの狙いを読まずに差分だけ見る	基準線がないと「ズレ」も「想定外」も判定できない。狙いを必ず1〜2文で押さえる
外部仕様を網羅的に列挙する	ユーザーに染み出す部分だけでよい。内部実装の都合は対象外
判定を出さず所感で終える	PdM が合否を切れる粒度のサマリを最上段に置く
想定外を見落とす	宣言された狙いに無いユーザー可視の挙動変化＝サイレント仕様変化を能動的に探す
健全なPRに無理やり懸念を盛る	狙い達成・重大懸念なしなら堂々と合にして短く出す。懸念の数で精度を演出しない
良性の小変更を「想定外」と誇張する	ユーザーが体感し不利益があるかでフィルタ。等価な書き換え・防御的追加は想定外ではない
狙い通りだからと施策の前提を疑わない（ラバースタンプ）	忠実実装でも「その施策自体がユーザーに良いか」を Step 2.5 で必ず問う。狙い由来のマイナスを「是非を問わない」と免責しない。ただし前提が妥当なら出力に書かなくてよい（問うプロセスが必須で、痕跡を出すことは必須ではない）

Red Flags（自分がサボっているサイン）

• 判定（合/否）を書いていない → レビューになっていない
• ➕ ばかりで ➖ が空 → トレードオフを見ていない
• 狙い通りの最小PRなのにサマリが重い（他ケースと同じ分量・微妙が大量） → 過剰指摘を疑え
• Minor 懸念しかないのに「条件付き合」「否」にしている → 判定ルーブリックに照らし直す
• 条件付き合 / 否の主因が「実装が差分に無い・動くか不明」になっている → それは確認事項（要確認）であって判定の核心ではないことが多い。codex review の領分に判定を寄せ、PdM視点の核心懸念（価値毀損・施策の前提の筋）を見落としていないか問い直す
• 「狙い通り」と判定して安心している → Step 2.5（施策の前提を疑う）を飛ばしていないか
• Step 2.5 の思考ログをそのまま出力に出している → 判定・見ておくべき点への反映に留め、プロセス自体は出力しない
• イシュー / PR 説明を読んでいない → 意図との整合を判定できていない
• 価値の話が技術用語のまま → ユーザー体験に翻訳していない
• サマリが長くて PdM が一目で判断できない → 最上段に判定＋価値増減を圧縮する
• レビュー本文に制作の過程が混ざっている（「codex はこう言ったが検証で覆った」「敵対的検証側は別評価だが」「当初こう考えたが訂正した」「○○ワークフローで生成した」） → 確定した結論だけ残す

関連ルール

レビュー本文を書くときは @.claude/rules/conclusion-only-output.md も適用する: 結論だけを書き、そこに至る過程・対比・自己言及（どう検証したか／別ツールはこう言ったが覆った／使った手法）を本文に残さない。 結論の裏付け（コード位置・再現条件・数字）は過程ではないので残す。