PR説明＋理解度クイズは何をしますか？

AI支援コーディングにより、理解せずにコードを承認してしまいがちです。このスキルは、レビューアが必要とするレベルで変更を説明し、いくつかの焦点を絞った質問で理解度を確認します。これにより、「LGTM」が意味のあるものになります。

1. 変更内容を収集する

以下のいずれかを実行します。

github PRビュー <番号> --json title,body,baseRefName,headRefName,files   # GitHub PR
github PR diff <番号>
git diff <ベース>...<ヘッド>                                            # ブランチ
git show <SHA>                                                         # 単一コミット

PRの説明と関連するIssue（あれば）を読んでください。次に、変更された関数の周辺コード（呼び出し元、呼び出し先、テスト）を読んでください — diffだけでは重要なコンテキストが隠れています。

2. 次の順序で説明する

1段落のサマリー: ユーザーまたは呼び出し元にとっての振る舞いの変化を説明します。ファイルのリストではありません。
理由: 説明、Issue、コミットメッセージから解決しようとしている問題。理由がどこにも記載されていない場合は、その旨を伝えてください — それはレビューの発見事項です。
図: 新しいフローを示すMermaid sequenceDiagram または flowchart で、新規/変更部分をハイライトします（ノートまたは:::changedクラスを使用）。ノード数は約15以下に抑え、コアパスだけを図示します。
概念別のウォークスルー（ファイル別ではない）: 関連するハンクをグループ化します（「リトライロジック」「新しい設定フラグ」）。各グループについて：何をするか、そして非自明な点（並行処理、エラーハンドリング、エッジケース、パフォーマンス）。
リスクノート: レビューアが特に注意すべき点 — 変更されたパブリックインターフェース、マイグレーション、削除されたテスト、飲み込まれたエラーパス、セキュリティ関連コード、新しいブランチに対する不足テスト。ファイル:行で具体的に指定します。

3. クイズ

3～5問の質問を1つずつ出題し、次の質問の前に回答を待ちます。良い質問は理解を必要とし、暗記ではありません。

「<依存関係>が<操作>中にタイムアウトした場合、今はどうなりますか？」
「シグネチャ変更の影響を受ける既存の呼び出し元はどれで、どのように影響を受けますか？」
「なぜ<行>は<行>の前に来る必要がありますか？」
「マイグレーション実行後にこれをロールバックすると、何が壊れますか？」

トリビアは避けてください（「新しい関数の名前は？」）。少なくとも1つは失敗/エッジ動作、1つは設計上の選択が行われた理由に関する質問を混ぜてください。

各回答の後：正しいかどうかを伝え、コード参照付きで1～3文で正しい説明をします。重要な点で間違っている場合は、diffのどの部分を再読すべきか提案します。

4. まとめ

スコア（例：4/5）と短い判定：「レビュー準備完了」または「承認前にXを再読してください」。見つかったリスクに対するレビューコメントのドラフト作成を提案します。

リクエストに応じて範囲を調整する

完全なフロー（サマリー→理由→図→ウォークスルー→リスク→クイズ）は、「これを案内して」や「レビューを手伝って」のデフォルトです。ユーザーが範囲を絞った場合は、それに従います。

「クイズなし」/「クイックをスキップ」: ステップ3なしのステップ1～2。
「サマリーとリスクだけ」: 1段落のサマリーとリスクノートのみ、図とウォークスルーはなし。残りは最後の1行で提供します。
「図だけ」: 図と2文のキャプション。

最初にリストするリスクは、ユーザーや金銭に影響を与える振る舞いの変更（例えば、無言の誤請求）に関するものであるべきで、技術的に最も興味深いものではありません。

PR説明＋理解度クイズ