| 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 に書かれた狙い。これと実差分を突き合わせるので、両方を必ず手に入れる。
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
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 も適用する: 結論だけを書き、そこに至る過程・対比・自己言及（どう検証したか／別ツールはこう言ったが覆った／使った手法）を本文に残さない。 結論の裏付け（コード位置・再現条件・数字）は過程ではないので残す。
