PRレビュー は何をしますか？
プルリクエスト（PR）をレビューするための手順です。レビューのルール（トーン、コメントカテゴリ、判断フロー、禁止事項）はPlaybookの「PRレビュー」セクションに記載されています。このスキルは方法を定義するものであり、ルールをここに再記述せず、適用してください。Playbookの「共有標準」（簡潔に、AIのスロップは不可、検証してから主張、決して捏造しない）は全体に適用されます。
レビュー前
- まずチケットを要求する。 Playbookで必須の最初のステップとして、チケットが提示されるまでdiffを取得したり分析したりしてはいけません。チケットは作業タイプ（機能追加 vs フォローアップ vs 調査）と受入基準を定め、レビューの進め方を変えます。
- PRを特定する：PR番号またはURLが与えられていない場合は要求する。
コンテキストを収集する
- GitHub CLIを使用してdiffとメタデータを取得する：
gh pr view <pr>およびgh pr diff <pr>。 - 調査PRの場合は、
docs/investigations/も確認し、期待される形式を把握する。 - 動作が周辺コードに依存する場合は、diffの変更箇所だけでなく、変更されたファイル全体を読む。
レビュー
diffをファイルごとに確認する。Playbookの「PRレビュー」セクションを適用する：
- Playbookのチェックリストを実行する（受入基準、コンパイル/テスト失敗、呼び出し元の更新、テストカバレッジ、調査のエビデンス）。
- 各発見事項をPlaybookに従ってBlocking、Nit、Questionに分類する。
- Playbookの判断フローを使用して、各観察結果にコメントする価値があるか判断する。
- スコープルールはチケットタイプによって異なる（フォローアップ：ここですべて解決；機能追加：リファクタリングは有効）。チケットからタイプを確認する。
- Playbookの「検証してから主張、決して捏造しない」に従う：主張を繰り返す前に自分で確認する。
gh pr checks <pr>でCIを確認し、リポジトリ内で削除されたシンボルをgrepする。PRの説明は作者の主張であり、エビデンスではない。 - Playbookの「既存の動作を黙って削除しない」に従う：確認されていない動作のリグレッションは、たとえ作者が説明で言及していても、Blockingな発見事項である。
出力
Playbookの「PRレビュー > 形式」に従う。レビューは直接チャットに出力する（ユーザーが要求しない限りファイルには書き出さない）。形式は1行の判定結果、続けて発見事項。これは散文エッセイ、会話ログ、または「収集したコンテキスト」「初期レビュー」のようなセクションではない。各発見事項は正確に：位置+コード参照行、コメント（コピー＆ペースト可能なフェンス内）、そして理由。具体的には、発見事項は次のようになります：
### Blocking
`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
コメント（PRに貼り付ける）：
この変更により、これらの書き込みが依存している結果整合性のリトライが削除されています。Core->Users間の遅延は`NotFound`として現れますが、新しい一時的エラーのみのポリシーではリトライされないため、書き込みは即座に失敗します。
理由：受入基準#3は、アプリケーションレベルのエラーをリトライするパスがないことを確認するよう求めています。このパスは以前リトライに依存しており、diffはそのウィンドウが存在しないことを確認せずに削除しています。
発見事項ごとに1つのブロックを繰り返し、`### Blocking` / `### Nits` / `### Questions` のグループにまとめる（空のグループは省略する）。「コメント」の後に続くフェンスブロックのみがユーザーがGitHubにコピーするものです。それ以外のすべてはナビゲーション用です。すべて問題なければ、判定行のみを出力する。
## 投稿（要求された場合のみ）
ユーザーがチャットでの下書きではなくコメントの投稿を希望する場合は、まず確認し、その後 `gh pr review` / `gh pr comment` を使用する。デフォルトはチャットでの下書きとする。